Ghostty vs WezTerm

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round drawn
   Ghostty—none0/10

   Ghostty is a terminal emulator, not a service with agent-facing docs; a direct probe confirms llms.txt and docs.md endpoints both return 404, meaning no agent-oriented docs are published for it to point at.

   • [probe] “PROBE llms.txt: HTTP 404 at https://ghostty.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://ghostty.org/docs.md”

   proof ↗⚑ flag

   WezTerm—none0/10

   WezTerm is a terminal emulator with no llms.txt or agent-oriented documentation endpoint; probes explicitly confirm 404s for llms.txt and markdown doc variants, and there is no mention of agent-facing docs anywhere in the docs or community evidence.

   • [probe] “PROBE llms.txt: HTTP 404 at https://wezterm.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://wezterm.org/features.html.md”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to WezTerm
   Ghostty—none0/10

   Ghostty is a GUI terminal emulator with GTK/macOS windowing dependencies (ghostty-comm-3, ghostty-comm-4), and a runtime probe found no remote-control/IPC interface, meaning scripts or agents cannot drive a running instance or invoke it headlessly for CI automation (ghostty-probe-rt-1). libghostty is for embedding terminal emulation in other apps, not for running Ghostty itself headlessly in CI.

   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [community] “Building from source needs specific deps: 'sudo apt install libgtk-4-dev libadwaita-1-dev git', otherwise you get 'unable to spawn glib-comp…”
   • [community] “It also seems to need a fairly new gtk4. At least the version in Ubuntu 22.04 is too old.”

   proof ↗⚑ flag

   WezTerm✓fullprobed8/10

   The CLI subcommand explicitly documents spawning/manipulating panes on a running instance, and a hands-on runtime probe confirms a fully headless control loop (mux-server --daemonize, cli spawn, send-text, get-text, list) with no GUI session required — directly matching the CI/automation story. Missing for 10: explicit first-party CI documentation/examples and independent community reports of using WezTerm in CI pipelines.

   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round drawn
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to WezTerm
   Ghostty—none0/10

   Ghostty only exposes a launch-time CLI (config flags, +list-actions/+help for bindable actions) but a runtime probe explicitly found no remote-control/IPC interface, meaning an external script or AI agent cannot send commands to or read output from a running Ghostty instance — the CLI is not built for agentic automation.

   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”

   proof ↗⚑ flag

   WezTerm✓fullprobed8/10

   WezTerm ships an official `wezterm cli` subcommand documented for spawning programs, sending text, reading pane content, and manipulating tabs/panes/windows, and a runtime probe confirms it works fully headless (mux-server daemonized, spawn/send-text/get-text/list all functioning without a GUI) — exactly the kind of scriptable, agent-drivable CLI an AI-native user would need. Missing for 10: no explicit first-party framing or examples for AI/agent orchestration use-cases, and no independent (non-vendor) confirmation beyond the single runtime probe.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to WezTerm
   Ghostty~partialprobed4/10

   Ghostty documents a macOS-only AppleScript dictionary for scripting windows/tabs/terminals/layouts and input events, and a libghostty C/Zig library for embedding terminal functionality, but these are aimed at embedding or macOS-specific automation, not a general documented public API for driving a running instance. A hands-on runtime probe found no remote-control/IPC interface — only a config-actions CLI — so an external agent/script cannot send commands to or read output from a live Ghostty session on the tested platform. Missing for 10: cross-platform scripting API, evidence AppleScript automation actually works end-to-end for external control, ability to read terminal output/state programmatically, and independent corroboration beyond vendor docs.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [github] “libghostty is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality”
   • [github] “`libghostty-vt` is already available and usable today for Zig and C and is compatible for macOS, Linux, Windows, and WebAssembly.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://ghostty.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://ghostty.org/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://ghostty.org/openapi.json, https://ghostty.org/swagger.json, https://ghostty.org/api/openapi.…”

   proof ↗⚑ flag

   WezTerm~partialprobed6/10

   WezTerm exposes a documented CLI (wezterm cli spawn/send-text/get-text/list) and a Lua config API, and a runtime probe confirms headless scripted control works end-to-end without a GUI, which is strong evidence for programmatic/agentic driving. However this is a CLI/Lua surface rather than a formal public API spec, and explicit machine-readable API docs (llms.txt, OpenAPI) both 404. missing for 10: an official structured API spec (OpenAPI/schema) or llms.txt for machine consumption, first-party documentation framing this as an 'AI-native' or agent-facing API, and independent third-party corroboration of scripted/agentic use beyond the single runtime probe.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://wezterm.org/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://wezterm.org/openapi.json, https://wezterm.org/swagger.json, https://wezterm.org/api/openapi.…”

   proof ↗⚑ flag

6. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round drawn
   Ghostty—none0/10

   Ghostty is a terminal emulator, not an automation/orchestration platform; evidence shows only config, theming, and AppleScript scripting for launching windows/tabs, with a runtime probe explicitly confirming no remote-control/IPC interface exists for scripts or agents to run background automations. No evidence of scheduled tasks, background job runners, or agent-triggerable automation capabilities.

   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”

   proof ↗⚑ flag

   WezTerm—none0/10

   WezTerm provides CLI/mux scripting and headless control (spawn, send-text, get-text) that could be used as building blocks, but there is no evidence of a scheduler, trigger system, or persistent background automation framework that runs autonomously without an external orchestrator invoking it. missing for 10: any documented scheduling/trigger mechanism, autonomous background job execution, or agent-loop capability distinct from manual/CLI-invoked scripting.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”

   proof ↗⚑ flag

Api quality

1. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm—none0/10

   WezTerm exposes a CLI and mux protocol but no machine-readable API spec is documented; probes for llms.txt, docs-md, and OpenAPI/swagger endpoints all return 404.

   • [probe] “PROBE llms.txt: HTTP 404 at https://wezterm.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://wezterm.org/features.html.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://wezterm.org/openapi.json, https://wezterm.org/swagger.json, https://wezterm.org/api/openapi.…”

   proof ↗⚑ flag

2. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Ghostty—none0/10

   Ghostty exposes libghostty as an embeddable C/Zig API surface, which makes 'versioned API with deprecation policy' a fair question, but the evidence pack shows no mention of API versioning scheme or deprecation policy, and probes confirm no openapi/llms.txt docs describing such governance.

   • [github] “libghostty is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality”
   • [github] “`libghostty-vt` is already available and usable today for Zig and C and is compatible for macOS, Linux, Windows, and WebAssembly.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://ghostty.org/openapi.json, https://ghostty.org/swagger.json, https://ghostty.org/api/openapi.…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://ghostty.org/llms.txt”

   proof ↗⚑ flag

   WezTerm—none0/10

   No evidence of a versioned API or documented deprecation policy; probes for llms.txt, docs-md, and OpenAPI specs all returned 404, and no docs mention API versioning or deprecation practices. WezTerm's Lua config API and CLI have no documented stability/versioning guarantees in the evidence pack.

   • [probe] “PROBE llms.txt: HTTP 404 at https://wezterm.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://wezterm.org/features.html.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://wezterm.org/openapi.json, https://wezterm.org/swagger.json, https://wezterm.org/api/openapi.…”

   proof ↗⚑ flag

Ai agent

1. ai-native userDelegate terminal tasks to a built-in AI agent that plans and executes commands with my approval

   weight 3 · round drawn
   Ghostty—none0/10

   Ghostty is a terminal emulator with no built-in AI agent, planning, or command-approval workflow anywhere in its documented feature set; evidence covers configuration, themes, rendering, and scripting via AppleScript/CLI actions only. A runtime probe explicitly found no remote-control/IPC interface that would let an external agent send or approve commands, confirming absence of this capability.

   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”

   proof ↗⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

Ai privacy

1. ai-native userUse or fully disable AI features with clear control over what session data leaves my machine, without a forced login

   weight 2 · round drawn
   Ghostty—none0/10

   The evidence pack contains no mention of any AI features, AI settings, session-data controls, or login requirements for Ghostty — it is documented purely as a native terminal emulator with configuration, theming, and libghostty embedding capabilities. Since terminal emulators (e.g., AI-augmented ones) can plausibly ship such features, the axis is applicable, but no evidence shows Ghostty offers or disables AI functionality or addresses data-egress/login controls.

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

1. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round to WezTerm
   Ghostty—none0/10

   Ghostty offers fixed automatic behaviors (auto-detect password prompts, dark/light theme switching) and on-demand AppleScript scripting, but there is no evidence of a general user-definable rule/trigger system that fires actions on arbitrary terminal events, and a runtime probe explicitly found no remote-control/IPC surface for such automation.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Secure Keyboard Entry: Automatically detect password prompts or manually enable secure keyboard entry to protect passwords from other proces…”
   • [claimed-docs] “Themes can be switched automatically based on system dark/light mode.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”

   proof ↗⚑ flag

   WezTerm~partialprobed3/10

   WezTerm's docs show scripted automation hooks (CLI to spawn/manipulate panes headlessly, shell-integration user vars, and automatic config-reload on file change) that could be used to script reactive behavior, but there is no explicit documentation of a rule/event system (e.g., named event triggers or pattern-based action bindings) that fires automatically on terminal events. Missing for 10: explicit event-trigger/rule API documentation, examples of event-based automation, and independent confirmation that users define event-driven rules.

   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [claimed-docs] “The shell integration provides a shell function named __wezterm_set_user_var which can be used to set your own user vars.”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”

   proof ↗⚑ flag

2. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

3. ai-native userVersion, review, and roll back my automations

   weight 1 · round drawn
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

Dotfiles

1. power-userKeep the terminal's full configuration as plain-text files in my dotfiles and sync it across machines

   weight 3 · round to WezTerm
   Ghostty✓fullclaimed8/10

   Ghostty's config is a plain-text file (config-file key), supports splitting into multiple files for modular dotfiles, every key works as a CLI flag, and it can be reloaded live without restart, all of which make it straightforward to keep in a dotfiles repo and sync across machines. missing for 10: no explicit documentation or community confirmation of cross-platform (macOS/Linux/Windows) path consistency for the config file, and no first-party dotfiles-sync tooling or guide is mentioned.

   • [claimed-docs] “You can split your configuration into multiple files by using the `config-file` key in your configuration file.”
   • [claimed-docs] “The configuration can be reloaded at runtime by pressing `ctrl+shift+,` (Linux) or `cmd+shift+,` (macOS).”
   • [claimed-docs] “The configuration can be reloaded at runtime by pressing ctrl+shift+, (Linux) or cmd+shift+, (macOS).”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [claimed-docs] “Ghostty supports hundreds of configuration options to make it look and behave exactly how you want.”

   proof ↗⚑ flag

   WezTerm✓fullcommunity9/10

   WezTerm's config is plain Lua text (wezterm.lua) that lives in dotfiles, auto-reloads on change, and supports CLI overrides — and community evidence directly confirms this makes cross-machine syncing trivial ('it's just Lua code, easy to diff and easy to apply' vs. iTerm2 where syncing was 'next to impossible'). Missing for 10: no first-party doc explicitly discussing dotfiles/multi-machine sync workflows, only community corroboration.

   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm allows overriding configuration values via the command line”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [community] “What killed iTerm2 for me was the fact that syncing settings between machines with chezmoi was next to impossible. With Wezterm it's just Lu…”

   proof ↗⚑ flag

Fonts

1. developerUse programming fonts with ligatures, fallback fonts, and fine-grained font tuning

   weight 2 · round to Ghostty
   Ghostty✓fullcommunity9/10

   Ghostty's docs explicitly cover ligature rendering (ghostty-docs-22/33), toggling programming ligatures via -calt (ghostty-docs-7), specifying font-features applied across all fonts (ghostty-docs-26), and configurable fallback fonts for missing codepoints (ghostty-docs-38), plus built-in nerd fonts and a default JetBrains Mono font (ghostty-docs-28). Community feedback corroborates deep, granular config tuning (minimum-contrast, selection colors) as a strength (ghostty-comm-5, ghostty-comm-6). Missing for 10: independent hands-on verification specifically of ligature rendering quality/fallback behavior beyond docs claims.

   • [claimed-docs] “You can use fonts that have ligatures and Ghostty will render them correctly.”
   • [claimed-docs] “You can use fonts that have ligatures and Ghostty will render them correctly. You can also specify specific font features to enable or disab…”
   • [claimed-docs] “To disable programming ligatures, use `-calt` since this is the typical feature name for programming ligatures.”
   • [claimed-docs] “The font feature will apply to all fonts rendered by Ghostty.”
   • [claimed-docs] “This configuration can be repeated multiple times to specify preferred fallback fonts when the requested codepoint is not available in the p…”
   • [claimed-docs] “Ghostty is designed to work out of the box with no configuration for most users. Ghostty has sensible defaults, embeds a default font (JetBr…”
   • [community] “Thanks for the minimum-contrast option (ghostty.org/docs/config/reference#minimum-contrast) - sick of tools with unreadable dark-on-black te…”
   • [community] “selection-foreground and selection-background config to set highlight colors makes a massive difference, versus the translucent selection on…”

   proof ↗⚑ flag

   WezTerm!disputedcontradicted6/10

   WezTerm's docs explicitly advertise ligatures, color emoji, and font fallback with true color, and config docs mention font-size/color-scheme tuning and live-reload of config changes, supporting fine-grained font control. However, hands-on community reports concretely contradict the polish of this: one user found WezTerm 'severely lacking in font configuration department contrary to popular opinion,' and another reports it 'renders Pragmata Pro Mono Liga much worse on Linux than Tilix does,' plus a Windows user found ligature rendering came with worse input latency than alternatives. Missing for 10: first-party deep-dive docs on fallback font ordering/fine-tuning knobs beyond font_size, and independent corroboration resolving the rendering-quality complaints.

   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes”
   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes.”
   • [claimed-docs] “changing the font size and color scheme.”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [community] “I live inside tmux inside alacritty running wsl. I tried wezterm after reading all the great reviews... and i found it severely lacking in f…”
   • [community] “It renders Pragmata Pro Mono Liga much worse on Linux than Tilix does. Otherwise, I'd give it a shot.”
   • [community] “I tried WezTerm on Windows because I was looking for a terminal with ligature support and lower input latency than Windows Terminal. Unfortu…”

   proof ↗⚑ flag

Theming

1. power-userApply color schemes and themes, including automatic light/dark mode switching

   weight 2 · round to Ghostty
   Ghostty✓fullcommunity9/10

   Docs explicitly confirm hundreds of built-in themes selectable via config, custom theme authoring, and automatic switching based on system light/dark mode, plus related fine-grained color config (minimum-contrast, selection colors) corroborated by community users praising these theming features. missing for 10: no independent hands-on demo/screenshot verifying auto light/dark switching in practice beyond docs claims.

   • [claimed-docs] “Themes: Ghostty ships with hundreds of themes that can be selected with a single line of configuration. Themes can be switched automatically…”
   • [claimed-docs] “Themes can be switched automatically based on system dark/light mode.”
   • [claimed-docs] “Ghostty ships with hundreds of built-in themes, supports different themes for light and dark mode, and more.”
   • [claimed-docs] “Users can author their own themes.”
   • [community] “Thanks for the minimum-contrast option (ghostty.org/docs/config/reference#minimum-contrast) - sick of tools with unreadable dark-on-black te…”
   • [community] “selection-foreground and selection-background config to set highlight colors makes a massive difference, versus the translucent selection on…”

   proof ↗⚑ flag

   WezTerm~partialclaimed4/10

   Evidence confirms WezTerm supports configurable color schemes and dynamic color scheme changes via config/live-reload, but nothing in the pack explicitly documents automatic OS light/dark mode detection or a scheme-switching mechanism tied to system appearance. Missing for 10: explicit documentation of automatic light/dark mode switching (e.g., appearance-based scheme selection), and independent confirmation it works in practice.

   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes”
   • [claimed-docs] “changing the font size and color scheme.”
   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes.”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to WezTerm
   Ghostty!disputedcontradicted3/10

   Ghostty documents AppleScript automation for scripting windows/tabs/terminals (macOS only) and exposes config keys as CLI flags, but a hands-on runtime probe found no remote-control/IPC interface: the CLI only supports config/action listing, and there is no way for an external script or agent to send commands to or read output from a running Ghostty instance. This directly contradicts the idea of full UI/API parity for an AI-native user. missing for 10: a documented remote-control/scripting API beyond macOS AppleScript, ability to read terminal state/output programmatically, cross-platform (Linux/Windows) automation parity.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”

   proof ↗⚑ flag

   WezTerm~partialprobed6/10

   WezTerm ships a genuine CLI/mux API (`wezterm cli spawn/send-text/get-text/list`) that a hands-on probe confirms works fully headless without a GUI session, covering pane/tab/window manipulation and text I/O — a strong basis for AI-native control. However, there's no evidence of full UI/API parity (e.g. scripting quick-select, font/color-scheme changes, image protocol, or search-mode equivalents via CLI), and no OpenAPI/machine-readable API surface (probes for openapi.json and llms.txt returned 404s), so many UI-only interactions remain unaddressed by the API. Missing for 10: documented CLI/Lua equivalents for all interactive UI features (quick select, scrollback search, image display, appearance changes), and any formal API spec.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://wezterm.org/openapi.json, https://wezterm.org/swagger.json, https://wezterm.org/api/openapi.…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://wezterm.org/llms.txt”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round to WezTerm
   Ghostty~partialprobed4/10

   Ghostty's configuration lives in plain, human-readable text files that can be split, version-controlled, and passed as CLI flags, which gives a basic form of open, portable settings data — but there is no explicit 'export my data' feature, session/history export, or documented data-portability guarantee (and probes for llms.txt/docs export endpoints return 404). missing for 10: an explicit export/backup mechanism for data beyond config (e.g., scrollback, session state), documentation framing this as a data-ownership/exit story, and independent confirmation that users rely on this for full data portability.

   • [claimed-docs] “Ghostty supports hundreds of configuration options to make it look and behave exactly how you want.”
   • [claimed-docs] “You can split your configuration into multiple files by using the `config-file` key in your configuration file.”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [probe] “PROBE llms.txt: HTTP 404 at https://ghostty.org/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://ghostty.org/docs.md”

   proof ↗⚑ flag

   WezTerm~partialcommunity5/10

   WezTerm's configuration is plain-text Lua stored locally (not locked in a proprietary format or cloud service), and community evidence shows scrollback/session content can be dumped via `wezterm cli get-text`, giving a de facto path to extract your data and leave. However, there is no explicit documented 'export all data' feature, no bundled data-portability tool, and no discussion of migrating multiplexer session state elsewhere. Missing for 10: an explicit export/backup feature or documentation addressing full data portability beyond config files and scrollback dumps, and independent confirmation of leaving with all state intact.

   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm allows overriding configuration values via the command line”
   • [community] “One thing I was looking for just yesterday was a way to dump my terminal's scrollback - escape sequences and all - to stdout... wezterm does…”
   • [community] “What killed iTerm2 for me was the fact that syncing settings between machines with chezmoi was next to impossible. With Wezterm it's just Lu…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Ghostty
   Ghostty~partialclaimed6/10

   Ghostty's source is hosted publicly on GitHub and the evidence confirms a public repo plus the libghostty/libghostty-vt libraries usable by developers, implying an open-source, readable codebase. However, no evidence item explicitly names or links the license text (e.g., MIT/Apache) confirming the terms under which the source can be read/used. Missing for 10: explicit license identification/citation, confirmation of license permissiveness, and any independent commentary on licensing terms.

   • [github] “Anyone can use `libghostty` to build a terminal emulator or embed a terminal into their own applications.”
   • [github] “libghostty is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality”
   • [github] “`libghostty` is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality (suc…”
   • [github] “`libghostty-vt` is already available and usable today for Zig and C and is compatible for macOS, Linux, Windows, and WebAssembly.”

   proof ↗⚑ flag

   WezTerm—none0/10

   No evidence in the pack references WezTerm's source license, GitHub repository, or open-source licensing terms; all citations concern terminal features, CLI usage, and user reviews, not code openness. Missing for 10: mention of the repository/license, license type (e.g. MIT), or any statement about source availability.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to WezTerm
   Ghostty—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   WezTerm✓fullprobed8/10

   WezTerm ships an embedded mux server that users can run themselves (self-hosted) and connect to via SSH domains, with docs on multiplexing and SSH domains plus a runtime probe confirming a fully headless `wezterm-mux-server --daemonize` control loop with `wezterm cli` spawn/send-text/get-text/list working without a GUI session. missing for 10: independent/community confirmation of self-hosted mux server usage specifically (most community quotes discuss desktop terminal use, not self-hosted server operation), and explicit licensing/deployment guidance for running it as a persistent self-hosted service.

   • [claimed-docs] “A connection to a remote wezterm multiplexer made via an ssh connection is referred to as an _SSH domain_.”
   • [claimed-docs] “wezterm uses an embedded ssh library to provide an integrated SSH client. The client can be used to make ad-hoc SSH connections to remote ho…”
   • [claimed-docs] “Take a look at the multiplexing section for an alternative configuration that connects to a remote wezterm instance and preserves your tabs.”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”

   proof ↗⚑ flag

Multiplexing

1. developerSplit windows into panes and organize work across tabs without an external multiplexer

   weight 3 · round to WezTerm
   Ghostty✓fullclaimed8/10

   Ghostty's official docs explicitly describe native support for multiple windows, each with its own tabs and splits, directly addressing the story of organizing work without an external multiplexer (ghostty-docs-32, ghostty-docs-40). Community discussion corroborates general daily-use satisfaction but does not specifically validate the pane/tab experience in depth. Missing for 10: independent hands-on validation specifically of the splits/tabs workflow (community comments focus on other features like search or scrollback), and no mention of pane resizing/navigation keybindings specifics.

   • [claimed-docs] “Ghostty supports multiple windows, each with its own tabs and splits. These are all rendered using native UI components.”
   • [claimed-docs] “Windows, tabs, and splits: Ghostty supports multiple windows, each with its own tabs and splits.”
   • [claimed-docs] “Ghostty supports flexible, custom keybindings through the keybind configuration option.”

   proof ↗⚑ flag

   WezTerm✓fullprobed9/10

   WezTerm natively multiplexes panes, tabs, and windows locally and remotely with CLI control and persistent mux server, and multiple hands-on community reports confirm fast, responsive pane splitting used as a tmux replacement. missing for 10: no independent third-party benchmark comparing full multiplexer feature parity (session detach/reattach robustness) across platforms.

   • [claimed-docs] “Multiplex terminal panes, tabs and windows on local and remote hosts, with native mouse and scrollback”
   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [community] “The main feature for me is splitting panes... The Lua configuration is very intuitive as well. I do get some indirect crashes when Xwayland …”
   • [community] “I finally went back and gave wezterm a serious try... The mouse issues I was seeing go away. Splitting panes and resizing lots of panes is f…”
   • [community] “I have been able to completely replace tmux with wezterm on Linux and Mac and love it. It even works on Windows.”

   proof ↗⚑ flag

Quick access

1. power-userSummon the terminal instantly with a global hotkey or quake-style dropdown window

   weight 1 · round to Ghostty
   Ghostty✓fullcommunity8/10

   Ghostty documents a dedicated Quick Terminal feature that animates down for instant access without interrupting work, matching the quake-style dropdown request, and this is independently corroborated by a community member calling it 'ghostty's killer feature.' Custom global keybindings are also configurable via the keybind option. Missing for 10: explicit documentation confirming the Quick Terminal is bound to a global hotkey configurable across all platforms (evidence emphasizes macOS) and no independent hands-on walkthrough of summoning it via a custom global shortcut.

   • [claimed-docs] “Quick Terminal: Lightweight terminal that animates down below the menu bar for instant access without interrupting work.”
   • [claimed-docs] “Lightweight terminal that animates down below the menu bar for instant access without interrupting work.”
   • [community] “The quick terminal feature is ghostty's killer feature for me.”
   • [claimed-docs] “Ghostty supports flexible, custom keybindings through the keybind configuration option.”

   proof ↗⚑ flag

   WezTerm—none0/10

   No evidence in the pack of a global-hotkey summon or quake-style dropdown window feature; documentation covers panes/tabs/multiplexing, SSH, CLI control, and scrollback but never mentions an instant-summon/dropdown mode, and no community citation confirms this capability exists.

   ⚑ flag

Sessions

1. developerRestore my windows, tabs, and working directories after a restart or crash

   weight 2 · round to WezTerm
   Ghostty—none0/10

   No evidence in the pack of any session/window/tab restoration feature after restart or crash; docs only describe windows/tabs/splits creation and configuration, not persistence of state. This is a plausible axis for a terminal emulator (comparable tools offer session restore), but nothing here confirms Ghostty supports it.

   ⚑ flag

   WezTerm~partialclaimed3/10

   WezTerm's mux-server/SSH-domain feature lets tabs and panes survive a GUI crash or restart by reconnecting to a persistent multiplexer instance, and OSC7-based cwd tracking lets new tabs inherit a working directory — but these require manually setting up a separate mux-server domain rather than being an automatic 'restore my session' feature, and there's no evidence of full window-layout or automatic state persistence on plain restart. Missing for 10: documented automatic session/workspace save-and-restore across app restarts, evidence of working-directory restoration (not just inheritance) after crash, and independent confirmation the mux-domain workflow reliably recovers full window/tab state.

   • [claimed-docs] “A connection to a remote wezterm multiplexer made via an ssh connection is referred to as an _SSH domain_.”
   • [claimed-docs] “Take a look at the multiplexing section for an alternative configuration that connects to a remote wezterm instance and preserves your tabs.”
   • [claimed-docs] “When the current working directory has been set via OSC 7, spawning a new tab will use the current working directory of the current tab, so …”
   • [claimed-docs] “wezterm uses an embedded ssh library to provide an integrated SSH client. The client can be used to make ad-hoc SSH connections to remote ho…”

   proof ↗⚑ flag

Benchmarks

1. power-userSee published benchmarks or measured latency/throughput numbers backing the terminal's performance claims

   weight 2 · round to Ghostty
   Ghostty~partialcommunity4/10

   No first-party published benchmarks exist in Ghostty's docs, but independent community benchmarks provide measured latency and throughput numbers (input latency improved to ~13ms in a newer test, throughput comparable to Alacritty/Ptyxis), while an older benchmark and a hands-on user reported markedly worse input latency and memory footprint than competitors. missing for 10: official vendor-published benchmark suite, consistent/reproducible throughput-latency methodology, and resolution of the conflicting community measurements.

   • [community] “According to an 11-month-old benchmark, Ghostty had the worst input latency across all contenders; a newer benchmark from ~4 months ago show…”
   • [community] “On throughput (catting a large file), Ghostty performs very well, among the same league as Alacritty and Ptyxis.”
   • [community] “After testing Ghostty for a while: input lag is higher than xfce4-terminal, font rendering is blurrier, UI is less consistent with my deskto…”

   proof ↗⚑ flag

   WezTerm—none0/10

   No evidence pack item shows WezTerm publishing formal benchmarks, latency/throughput measurements, or comparative performance data; docs only list features, and community comments are anecdotal impressions (some praising speed, others reporting higher latency than cmd.exe/kitty/alacritty) rather than measured numbers.

   ⚑ flag

Rendering

1. developerRely on GPU-accelerated rendering that stays fast and responsive under heavy output

   weight 3 · round to Ghostty
   Ghostty!disputedcontradicted5/10

   Ghostty's docs/github tier claim libghostty provides core rendering performance (rendering capabilities, cross-platform GPU-based terminal library), but hands-on community reports concretely contradict smooth, fast performance under load: one user found higher input lag, blurrier fonts and 3-4x memory footprint versus a lightweight terminal, and an older independent latency benchmark showed Ghostty had the worst input latency among terminals tested — though a newer benchmark reported improved ~13ms latency and strong throughput comparable to Alacritty/Ptyxis. missing for 10: first-party performance benchmarks or documentation of GPU-rendering architecture, resolution of the reported high-memory/input-lag complaints, and consistent independent benchmark corroboration across time.

   • [claimed-docs] “libghostty provides the core terminal emulation, font handling, and rendering capabilities.”
   • [github] “libghostty is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality”
   • [github] “`libghostty` is a cross-platform, zero-dependency C and Zig library for building terminal emulators or utilizing terminal functionality (suc…”
   • [community] “After testing Ghostty for a while: input lag is higher than xfce4-terminal, font rendering is blurrier, UI is less consistent with my deskto…”
   • [community] “According to an 11-month-old benchmark, Ghostty had the worst input latency across all contenders; a newer benchmark from ~4 months ago show…”
   • [community] “On throughput (catting a large file), Ghostty performs very well, among the same league as Alacritty and Ptyxis.”
   • [community] “It feels amazing on linux. I find it very noticably better than konsole. Foot/Alacritty also feel amazing but they don't have some features …”

   proof ↗⚑ flag

   WezTerm!disputedcontradicted4/10

   WezTerm's docs tout GPU-based rendering features (ligatures, true color, dynamic schemes) and community reports frequently praise it as fast/responsive (e.g., wezterm-comm-3, wezterm-comm-4, wezterm-comm-5), but multiple hands-on reports directly contradict sustained performance under heavy output — lag when scrolling long lists (wezterm-comm-11), higher input latency than Kitty/cmd.exe and blank-line rendering glitches in vim (wezterm-comm-6, wezterm-comm-12), and poor font rendering vs other GPU terminals (wezterm-comm-18). Missing for 10: explicit first-party GPU-rendering documentation/benchmarks and resolution of the latency/rendering-glitch reports.

   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes”
   • [claimed-docs] “Ligatures, Color Emoji and font fallback, with true color and dynamic color schemes.”
   • [community] “Recently switched to WezTerm and I'm very happy... WezTerm is leaps and bounds better in terms of what comes out-of-the-box. My terminal con…”
   • [community] “I finally went back and gave wezterm a serious try... The mouse issues I was seeing go away. Splitting panes and resizing lots of panes is f…”
   • [community] “WezTerm is just so much faster than iTerm2, wish I had switched sooner!”
   • [community] “I tried WezTerm on Windows because I was looking for a terminal with ligature support and lower input latency than Windows Terminal. Unfortu…”
   • [community] “Downloaded the latest stable for macOS and still has the same problem as before - if you have long list of items you want to scroll through …”
   • [community] “I really wanted WezTerm to be the best terminal on macOS. However...WezTerm's latency was noticeably higher than Kitty and WezTerm often pai…”
   • [community] “It renders Pragmata Pro Mono Liga much worse on Linux than Tilix does. Otherwise, I'd give it a shot.”

   proof ↗⚑ flag

1. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Ghostty—none0/10

   No evidence in the pack mentions telemetry, usage tracking, or an opt-out setting for Ghostty; the docs cover configuration, features, and performance but say nothing about data collection practices. Since this is a locally-installed terminal emulator, the axis is plausible (any app could collect usage data) but unaddressed, so it defaults to none rather than na.

   ⚑ flag

   WezTerm—none0/10

   The axis applies to terminal emulators as a kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

Graphics

1. developerDisplay inline images and rich graphics via a documented terminal graphics protocol

   weight 2 · round to Ghostty
   Ghostty✓fullclaimed8/10

   Ghostty's official docs explicitly document support for the Kitty graphics protocol, enabling inline image rendering directly in the terminal, and this is listed as a core feature alongside a broader reference on supported control sequences. Missing for 10: independent hands-on confirmation/testing of the graphics protocol specifically (community evidence covers other features but not image rendering) and detail on protocol coverage limits.

   • [claimed-docs] “Kitty graphics protocol: Ghostty supports the Kitty graphics protocol, which allows terminal applications to render images directly in the t…”
   • [claimed-docs] “Ghostty supports the Kitty graphics protocol, which allows terminal applications to render images directly in the terminal.”
   • [claimed-docs] “For terminal application developers, a reference on terminal concepts and supported control sequences.”

   proof ↗⚑ flag

   WezTerm!disputedcontradicted6/10

   WezTerm documents iTerm2-compatible inline image protocol support plus a built-in imgcat CLI for outputting images to the terminal, which is a genuine documented graphics protocol implementation. However, a hands-on community report states the image support 'didn't play well with tmux,' a concrete real-world failure that led a user to switch away, contradicting a fully seamless graphics experience. Missing for 10: independent hands-on confirmation that images render cleanly outside tmux edge cases, and evidence of broader protocol support (e.g., Sixel/Kitty graphics) beyond iTerm2 compatibility.

   • [claimed-docs] “Output an image to the terminal”
   • [claimed-docs] “iTerm2 compatible image protocol support, and built-in imgcat command”
   • [community] “The thing that made me switch to Ghostty was the image support in wez didn't play well with tmux. After testing wez, kitty, and Ghostty, I e…”

   proof ↗⚑ flag

Platforms

1. developerRun the same terminal with the same config on macOS, Linux, and Windows

   weight 2 · round to WezTerm
   Ghostty~partialclaimed4/10

   Ghostty documents strong config portability (single config file, config-file includes, hundreds of options, CLI-flag equivalence) and confirms macOS and Linux binaries, but the evidence pack never shows an actual Ghostty terminal app for Windows — only the underlying libghostty-vt library is said to target Windows/WebAssembly, and the docs explicitly note different default keybindings on macOS vs Linux, undercutting an identical experience even across the two platforms that are supported. missing for 10: confirmed Windows terminal application/binary release, identical default keybindings across platforms, and independent testimony of using the same config file on all three OSes.

   • [claimed-docs] “Ghostty supports hundreds of configuration options to make it look and behave exactly how you want.”
   • [claimed-docs] “You can split your configuration into multiple files by using the `config-file` key in your configuration file.”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [claimed-docs] “Ghostty uses different default bindings on macOS and Linux to match the conventions of each platform.”
   • [claimed-docs] “Another part is using standard keyboard and mouse shortcuts that you're already familiar with. Ghostty uses different default bindings on ma…”
   • [github] “`libghostty-vt` is already available and usable today for Zig and C and is compatible for macOS, Linux, Windows, and WebAssembly.”
   • [claimed-docs] “A [Homebrew cask](https://formulae.brew.sh/cask/ghostty) is available and maintained by the Ghostty community.”

   proof ↗⚑ flag

   WezTerm✓fullcommunity8/10

   WezTerm's Lua-based config is designed to be portable, with docs describing config file watching/reloading and command-line overrides, and community evidence confirms real cross-platform parity: "I have been able to completely replace tmux with wezterm on Linux and Mac... It even works on Windows" and a user reporting seamless config sync across machines via chezmoi/Lua. macOS install via brew is explicitly documented. Missing for 10: explicit first-party install docs/citations for Linux and Windows in this pack (only macOS install doc present), and no direct doc statement guaranteeing identical behavior across all three OSes.

   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm allows overriding configuration values via the command line”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [claimed-docs] “WezTerm is available for brew users”
   • [claimed-docs] “$ brew install --cask wezterm”
   • [community] “I have been able to completely replace tmux with wezterm on Linux and Mac and love it. It even works on Windows.”
   • [community] “What killed iTerm2 for me was the fact that syncing settings between machines with chezmoi was next to impossible. With Wezterm it's just Lu…”

   proof ↗⚑ flag

Ssh

1. developerSSH to remote hosts with the terminal's own integration carrying my terminfo, shell integration, and config along

   weight 2 · round to WezTerm
   Ghostty—none0/10

   There is no documentation in the evidence pack describing an SSH integration feature that carries terminfo, shell integration, and config to remote hosts; instead, community reports describe Ghostty's custom TERM value causing 'missing or unsuitable terminal' errors on SSH and users citing SSH breakage as a recurring blocker.

   • [community] “Using its own TERM is a deliberate design decision that can cause SSH 'missing or unsuitable terminal' errors on servers that hardcode xterm…”
   • [community] “I have tried every possible setting but SSH ends up breaking more often than not. As opposed to iTerm which just works. Sometimes I'm back t…”
   • [community] “Missing search and weird ssh control character issues are my blockers. It's great otherwise!”

   proof ↗⚑ flag

   WezTerm~partialclaimed6/10

   WezTerm ships a built-in SSH client and 'SSH domains' that let you multiplex tabs/panes over an SSH connection to a remote wezterm mux, and it exposes shell-integration features (OSC7 cwd tracking, user vars) for local sessions, but the evidence never explicitly confirms that terminfo, shell-integration scripts, or local config are automatically propagated/carried to the remote host on ad-hoc SSH connections (docs-9/14/18 note an 'alternative configuration' needed for full tab/pane preservation, implying the basic ad-hoc SSH mode doesn't fully carry everything). missing for 10: explicit documentation/evidence of terminfo propagation to remote host, confirmation that shell-integration scripts/config are auto-installed or carried over plain SSH (not just via the multiplexer/domain setup), and independent hands-on confirmation of this remote workflow working smoothly.

   • [claimed-docs] “wezterm uses an embedded ssh library to provide an integrated SSH client. The client can be used to make ad-hoc SSH connections to remote ho…”
   • [claimed-docs] “A connection to a remote wezterm multiplexer made via an ssh connection is referred to as an _SSH domain_.”
   • [claimed-docs] “Take a look at the multiplexing section for an alternative configuration that connects to a remote wezterm instance and preserves your tabs.”
   • [claimed-docs] “wezterm uses an embedded ssh library to provide an integrated SSH client.”
   • [claimed-docs] “When the current working directory has been set via OSC 7, spawning a new tab will use the current working directory of the current tab, so …”
   • [claimed-docs] “The shell integration provides a shell function named __wezterm_set_user_var which can be used to set your own user vars.”

   proof ↗⚑ flag

Tmux

1. developerUse tmux inside the terminal, or a documented native tmux integration/control mode

   weight 2 · round to WezTerm
   Ghostty—none0/10

   The evidence pack contains no mention of tmux compatibility, tmux control mode, or any native tmux integration in Ghostty's docs or community reports; only SSH-related terminfo/control-character friction is discussed, which is a different issue. Since terminal emulators like iTerm2 do document explicit tmux control-mode support, this is a fair axis to expect evidence for, and none exists here.

   • [community] “Using its own TERM is a deliberate design decision that can cause SSH 'missing or unsuitable terminal' errors on servers that hardcode xterm…”
   • [community] “I have tried every possible setting but SSH ends up breaking more often than not. As opposed to iTerm which just works. Sometimes I'm back t…”
   • [community] “Missing search and weird ssh control character issues are my blockers. It's great otherwise!”

   proof ↗⚑ flag

   WezTerm~partialprobed6/10

   WezTerm documents its own native multiplexing (panes/tabs/windows, SSH domains, mux server, cli spawn/send-text/get-text control mode verified in a headless probe) as a built-in alternative to tmux, and users can also run tmux inside it. However, this is WezTerm's own multiplexer, not a documented tmux control-mode/integration, and community evidence shows friction when combining WezTerm with actual tmux (image protocol issues causing a user to switch to Ghostty). missing for 10: explicit documentation of tmux control-mode (tmux -CC) support or a first-party statement about compatibility/integration with tmux itself, and resolution of the tmux+image-support conflict noted by a user.

   • [claimed-docs] “Multiplex terminal panes, tabs and windows on local and remote hosts, with native mouse and scrollback”
   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “A connection to a remote wezterm multiplexer made via an ssh connection is referred to as an _SSH domain_.”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [community] “I have been able to completely replace tmux with wezterm on Linux and Mac and love it. It even works on Windows.”
   • [community] “The thing that made me switch to Ghostty was the image support in wez didn't play well with tmux. After testing wez, kitty, and Ghostty, I e…”

   proof ↗⚑ flag

Agent control

1. ai-native userLet a coding agent programmatically drive the terminal itself — create panes, run commands, read output — through a documented control protocol or API

   weight 3 · round to WezTerm
   Ghostty~partialprobed4/10

   Ghostty documents a built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events, which could let an agent create panes and send commands on macOS, but this is a niche, platform-limited mechanism, not a documented cross-platform control API, and there's no evidence it supports reading terminal output. A hands-on runtime probe explicitly found no remote-control/IPC interface beyond local CLI keybinding actions, meaning an external agent cannot send commands to or read output from a running instance via any documented protocol. missing for 10: cross-platform control API, documented output-reading mechanism, and confirmation that AppleScript scripting actually supports agent-driven read/write loops.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”

   proof ↗⚑ flag

   WezTerm✓fullprobed9/10

   WezTerm documents a CLI subcommand (wezterm cli) that can spawn programs, manipulate tabs/panes, and read pane text (get-text), and a runtime probe confirms an agent-driven headless workflow: spawning panes, sending text/commands, and reading output via a mux server with no GUI required. This is a documented, hands-on-verified programmatic control protocol suitable for an AI agent to drive the terminal. Missing for 10: no formal OpenAPI/RPC schema (llms.txt and openapi probes 404) and no first-party example of an AI agent integration specifically.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [community] “One thing I was looking for just yesterday was a way to dump my terminal's scrollback - escape sequences and all - to stdout... wezterm does…”

   proof ↗⚑ flag

Extensibility

1. developerExtend the terminal with scripts or plugins in a real language (Lua, Python, kittens) beyond built-in options

   weight 2 · round to WezTerm
   Ghostty—none0/10

   Ghostty offers only configuration-file options, keybindings, and macOS-only AppleScript automation for driving the app externally; there is no evidence of a Lua/Python scripting API, plugin system, or kitten-style extension mechanism. The runtime probe explicitly confirms no remote-control/IPC surface exists beyond a fixed set of bindable actions, meaning scripts/plugins in a real language cannot extend the terminal.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [claimed-docs] “Ghostty supports flexible, custom keybindings through the keybind configuration option.”

   proof ↗⚑ flag

   WezTerm~partialcommunity6/10

   WezTerm's configuration and extensibility system is Lua-based, confirmed by community reports (e.g., 'with Wezterm it's just Lua code, easy to diff and easy to apply') and supported by docs showing config-file hooks, live-reload, CLI overrides, and user-variable functions that imply a scripting surface beyond simple config. However, the evidence pack lacks direct first-party documentation explicitly describing the Lua API/plugin system, and there is no support for Python or kitten-style extensions (those are a different terminal's feature) — missing for 10: explicit docs citation of the Lua scripting/plugin API, evidence of a plugin ecosystem, and any Python/kittens equivalent.

   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [claimed-docs] “The shell integration provides a shell function named __wezterm_set_user_var which can be used to set your own user vars.”
   • [community] “What killed iTerm2 for me was the fact that syncing settings between machines with chezmoi was next to impossible. With Wezterm it's just Lu…”

   proof ↗⚑ flag

Layouts

1. power-userDefine startup sessions and window layouts in config or scripts so a project workspace opens in one command

   weight 2 · round to WezTerm
   Ghostty~partialprobed3/10

   Ghostty offers rich config options, keybindings, and multi-window/tab/split support, plus a macOS-only AppleScript dictionary for 'scripting windows, tabs, terminals, layouts' which could approximate scripted startup layouts, but there is no documented session/layout file format or CLI flag to launch a predefined multi-window/tab/split workspace in one command (and probe evidence shows no external IPC/remote-control interface). missing for 10: cross-platform session/layout config file, documented 'launch project workspace' example, evidence of one-command startup replicating saved layouts, and confirmation the AppleScript route actually achieves this in practice.

   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Ghostty supports multiple windows, each with its own tabs and splits. These are all rendered using native UI components.”
   • [claimed-docs] “Windows, tabs, and splits: Ghostty supports multiple windows, each with its own tabs and splits.”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”

   proof ↗⚑ flag

   WezTerm✓fullprobed7/10

   WezTerm's Lua-based config supports scripting startup behavior, and the documented `cli` subcommand can spawn programs and manipulate tabs/panes; a hands-on probe confirms a fully headless control loop (spawn window, send commands, enumerate panes) without GUI interaction, which is exactly the kind of single-command scripted session/layout setup the story describes. Missing for 10: explicit vendor documentation of a named 'workspace' or multi-pane layout template feature (e.g. gui-startup event) and independent community confirmation specifically of launching complex multi-window/pane project layouts via one script.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded”
   • [claimed-docs] “wezterm will watch the config file that it loads; if/when it changes, the configuration will be automatically reloaded and the majority of o…”
   • [claimed-docs] “wezterm allows overriding configuration values via the command line”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”

   proof ↗⚑ flag

Remote control

1. developerScript and control the terminal from the command line — open windows, send text, query state — via a documented CLI or IPC interface

   weight 3 · round to WezTerm
   Ghostty~partialprobed4/10

   Ghostty documents an AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events (macOS only), and exposes CLI flags mapping to config keys, but hands-on probing found no cross-platform CLI/IPC mechanism to remote-control a running instance — the CLI's +action surface only lists/binds actions locally, it cannot send text or query state of a live terminal from another process. missing for 10: a documented cross-platform IPC/socket/CLI remote-control protocol, evidence of sending text/querying state from an external script, and Linux/Windows equivalent to AppleScript automation.

   • [claimed-docs] “AppleScript Automation: Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Built-in AppleScript dictionary for scripting windows, tabs, terminals, layouts, and input events.”
   • [claimed-docs] “Every configuration key is a valid CLI flag when launching Ghostty from the command-line.”
   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”

   proof ↗⚑ flag

   WezTerm✓fullprobed9/10

   WezTerm ships a documented `cli` subcommand (spawn, send-text, get-text, list, activate, etc.) that controls a running GUI or multiplexer instance, and this was independently verified headless (daemonized mux server + spawn/send-text/get-text/list roundtrip) plus corroborated by a community user dumping scrollback via get-text. Missing for 10: no first-party mention of a richer structured IPC/JSON-RPC protocol beyond the CLI wrapper, and no independent third-party write-up beyond the single HN mention.

   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “The cli subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and p…”
   • [probe] “official CLI documented at https://wezterm.org/cli/cli/index.html”
   • [probe] “PROBE runtime (recorded 2026-09-04, wezterm 20240203 via brew cask): fully headless control loop verified — `wezterm-mux-server --daemonize`…”
   • [community] “One thing I was looking for just yesterday was a way to dump my terminal's scrollback - escape sequences and all - to stdout... wezterm does…”

   proof ↗⚑ flag

Command tracking

1. developerI get command-aware features from shell integration, like exit status, duration, and notifications when long commands finish

   weight 2 · round drawn
   Ghostty—none0/10

   The evidence pack contains no mention of shell integration, exit status tracking, command duration, or completion notifications for Ghostty; only general feature docs (themes, keybindings, quick terminal, etc.) are present.

   ⚑ flag

   WezTerm—none0/10

   WezTerm's shell-integration docs describe OSC 7 cwd-tracking and custom user vars (wezterm-docs-10, wezterm-docs-20, wezterm-docs-25), but the evidence pack contains no mention of exit-status tracking, command duration, or notifications when long-running commands finish — features other terminals' shell integrations advertise. Missing for 10: documented exit-status capture, command-duration timing, and completion notifications.

   • [claimed-docs] “When the current working directory has been set via OSC 7, spawning a new tab will use the current working directory of the current tab, so …”
   • [claimed-docs] “spawning a new tab will use the current working directory of the current tab, so that you don't have to manually change the directory”
   • [claimed-docs] “The shell integration provides a shell function named __wezterm_set_user_var which can be used to set your own user vars.”

   proof ↗⚑ flag

Marks

1. developerJump between prompts and command marks in my scrollback thanks to shell integration

   weight 2 · round drawn
   Ghostty—none0/10

   No evidence in the pack mentions shell integration, prompt/command marks, or scrollback navigation features (e.g., jump-to-prompt) for Ghostty; community feedback even highlights basic scrollback/search gaps without mentioning mark navigation.

   ⚑ flag

   WezTerm—none0/10

   Evidence pack's shell-integration docs (wezterm-docs-10, wezterm-docs-20, wezterm-docs-25) only cover OSC 7 working-directory tracking and custom user vars — there is no mention of OSC 133 semantic prompt/command marks or any keybinding/feature to jump between prompts or command outputs in scrollback. Missing for 10: documentation or evidence of prompt-jump/command-mark navigation, keybindings for 'jump to previous/next prompt', and any independent confirmation of this specific capability.

   • [claimed-docs] “When the current working directory has been set via OSC 7, spawning a new tab will use the current working directory of the current tab, so …”
   • [claimed-docs] “spawning a new tab will use the current working directory of the current tab, so that you don't have to manually change the directory”
   • [claimed-docs] “The shell integration provides a shell function named __wezterm_set_user_var which can be used to set your own user vars.”

   proof ↗⚑ flag

Discoverability

1. power-userDiscover and run terminal actions from a searchable command palette

   weight 1 · round drawn
   Ghostty—none0/10

   Evidence shows Ghostty exposes keybindings, a config-driven action system, and a CLI `+list-actions`/`+help` surface, but nothing describes a searchable/discoverable command palette UI for running terminal actions interactively; the runtime probe explicitly notes there's no remote-control/interactive command surface beyond static CLI listing.

   • [probe] “PROBE runtime (recorded 2026-09-04, Ghostty 1.3.1 via brew cask): `ghostty +list-actions` enumerates 85 bindable actions (new_split, new_tab…”
   • [claimed-docs] “Ghostty supports flexible, custom keybindings through the keybind configuration option.”

   proof ↗⚑ flag

   WezTerm—none0/10

   The evidence pack documents CLI subcommands, quick-select, scrollback search, and SSH/multiplexing features, but nowhere mentions a searchable command palette for discovering/running actions. A community comment even notes that WezTerm's many features 'are not really discoverable,' reinforcing the absence of such a UI. Missing for 10: any documentation or user report of a command-palette UI, its keybinding, or its action list.

   • [community] “my only complaint is that its many features are not really discoverable. Sure, the documentation is really good, and the author is very enga…”
   • [claimed-docs] “The _cli_ subcommand interacts with a running wezterm GUI or multiplexer instance, and can be used to spawn programs and manipulate tabs and…”
   • [claimed-docs] “Quick Select mode allows you to quickly highlight text that matches commonly copied patterns, select a match by typing a one-or-two characte…”

   proof ↗⚑ flag

Hyperlinks

1. developerOpen URLs and file paths from output by clicking them or selecting them from the keyboard

   weight 2 · round to WezTerm
   Ghostty—none0/10

   The evidence pack contains no mention of clickable URL/path detection in terminal output; the closest feature (proxy icon drag) only concerns the current session's working directory in the title bar, not clicking links or paths within terminal output. Missing for 10: any documentation or community mention of URL/path hyperlink detection, click-to-open behavior, or keyboard-based link selection.

   ⚑ flag

   WezTerm~partialclaimed4/10

   WezTerm's Quick Select mode lets users highlight and copy commonly-matched text patterns via keyboard shortcuts, which could cover URLs/paths, but the evidence pack never explicitly documents clickable URL/file opening or an 'open with' action, nor mouse-click-to-open behavior. missing for 10: explicit doc on clicking URLs/paths to open them, evidence of file-path recognition, independent confirmation of click-to-open working in practice.

   • [claimed-docs] “Quick Select mode allows you to quickly highlight text that matches commonly copied patterns, select a match by typing a one-or-two characte…”
   • [claimed-docs] “Searchable Scrollback (use mouse wheel and `Shift-PageUp` and `Shift PageDown` to navigate, Ctrl-Shift-F to activate search mode)”

   proof ↗⚑ flag

Scrollback

1. developerSearch my scrollback quickly and jump between matches

   weight 2 · round to WezTerm
   Ghostty—none0/10

   No documentation feature for scrollback search exists, and multiple independent user reports confirm cmd-f/ctrl-f search does not work in Ghostty, calling it a blocker.

   • [community] “Ghostty is awesome and I almost dropped iTerm for it until I hit cmd-f and nothing happened.”
   • [community] “Missing search and weird ssh control character issues are my blockers. It's great otherwise!”
   • [community] “Missing scrollbars. That and ctrl-f are my two annoyances, apart from that I love ghostty and use it daily at work.”

   proof ↗⚑ flag

   WezTerm✓fullcommunity8/10

   WezTerm documents a Searchable Scrollback feature with Ctrl-Shift-F search mode and keyboard navigation (Shift-PageUp/PageDown, mouse wheel), directly matching the story of quickly searching and jumping between matches; Quick Select mode further complements this for jumping to specific text patterns. Community evidence corroborates related scrollback tooling (get-text dump) though no direct hands-on account of search-and-jump-between-matches UX specifically. Missing for 10: independent hands-on account of the search-mode match-navigation experience (e.g., keybindings for next/prev match) and any friction/limitations reported by users.

   • [claimed-docs] “Searchable Scrollback (use mouse wheel and `Shift-PageUp` and `Shift PageDown` to navigate, Ctrl-Shift-F to activate search mode)”
   • [claimed-docs] “Searchable Scrollback (use mouse wheel and Shift-PageUp and Shift PageDown to navigate, Ctrl-Shift-F to activate search mode)”
   • [claimed-docs] “Quick Select mode allows you to quickly highlight text that matches commonly copied patterns, select a match by typing a one-or-two characte…”
   • [community] “One thing I was looking for just yesterday was a way to dump my terminal's scrollback - escape sequences and all - to stdout... wezterm does…”

   proof ↗⚑ flag