WezTerm vs kitty

Agent access

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

   weight 2 · round drawn
   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

   kitty—none0/10

   Probes explicitly show no llms.txt (404), no markdown-flavored docs endpoint, and no OpenAPI/agent-discovery spec; all documentation is standard human-oriented HTML with no agent-oriented onboarding artifact for pointing an AI agent at.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sw.kovidgoyal.net/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://sw.kovidgoyal.net/kitty/overview/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sw.kovidgoyal.net/openapi.json, https://sw.kovidgoyal.net/swagger.json, https://sw.kovidgoya…”

   proof ↗⚑ flag

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

   weight 2 · round to WezTerm
   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

   kitty~partialprobed7/10

   Kitty documents and hands-on-verifies a scripts/remote-control interface (kitten @ commands) and supports launching in `--detach` mode with a listening socket, which enables automation-style control loops (open, send-text, read-text, close) as verified in the runtime probe. However, kitty is fundamentally a GUI terminal emulator; there is no documentation of a true headless/no-display mode for CI pipelines (e.g., Xvfb-free operation) or CI-specific guidance. Missing for 10: explicit CI/headless-without-display documentation, and independent confirmation of running in a CI pipeline environment.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   kitty—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 userConnect an agent via an official MCP server

   weight 3 · round drawn
   WezTerm—none0/10

   This product is not itself an agent, so publishing an official MCP server is plausible and the axis applies; no first-party MCP server appears in the evidence. (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

   kitty—none0/10

   This product is not itself an agent, so publishing an official MCP server is plausible and the axis applies; no first-party MCP server appears in the evidence. (na/none harmonized at arena bring-up — see pipeline/scripts/terminals-na-harmonize.ts.)

   ⚑ flag

5. ai-native userUse an official CLI

   weight 2 · round to kitty
   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

   kitty✓fullprobed9/10

   kitty ships an official `kitty @` remote-control CLI (kitten) documented and hands-on verified to list windows, send text, read output, and close windows via JSON — a full scriptable automation loop suitable for AI-native agent control. missing for 10: independent third-party corroboration beyond the single hands-on probe and official docs.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   proof ↗⚑ flag

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

   weight 3 · round to kitty
   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

   kitty✓fullprobed9/10

   kitty ships a well-documented remote-control API (`kitty @` / `kitten @`) allowing scripts/agents to open windows, send text, read output, and manage layout, and this was independently verified hands-on with a full agent-control loop (list, send-text, get-text, close-window). Missing for 10: no formal OpenAPI/machine-readable schema (probe shows 404s for openapi.json/llms.txt), so discovery is documentation-only rather than a structured API spec.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sw.kovidgoyal.net/openapi.json, https://sw.kovidgoyal.net/swagger.json, https://sw.kovidgoya…”

   proof ↗⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   kitty—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
   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

   kitty—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

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   WezTerm—none0/10

   WezTerm is a terminal emulator with static configuration docs and a Lua API reference, but there's no evidence of an interactive, runnable-examples API reference; probes confirm no llms.txt, no docs-md, and no OpenAPI/interactive API surface exists.

   • [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

   kitty—none0/10

   No evidence of an interactive API reference with runnable examples; probes explicitly show no OpenAPI/llms.txt and only static docs pages for remote-control, which is documentation, not an interactive/runnable API explorer.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sw.kovidgoyal.net/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sw.kovidgoyal.net/openapi.json, https://sw.kovidgoyal.net/swagger.json, https://sw.kovidgoya…”
   • [claimed-docs] “Control kitty from scripts”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   kitty—none0/10

   Probes explicitly checked for a machine-readable API spec (OpenAPI/swagger/llms.txt) and all returned 404s; kitty's remote-control API is documented only in prose docs, not as a downloadable machine-readable spec.

   • [probe] “PROBE llms.txt: HTTP 404 at https://sw.kovidgoyal.net/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://sw.kovidgoyal.net/kitty/overview/.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://sw.kovidgoyal.net/openapi.json, https://sw.kovidgoyal.net/swagger.json, https://sw.kovidgoya…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   kitty—none0/10

   Kitty documents a remote-control API and graphics protocol, but there is no evidence of API versioning or a documented deprecation policy for these interfaces; probes for machine-readable API specs (openapi.json, llms.txt) returned 404s. Missing for 10: any versioning scheme, changelog-based deprecation policy, or stability guarantees for the remote-control/graphics protocols.

   • [probe] “PROBE openapi: all candidate paths 404 (https://sw.kovidgoyal.net/openapi.json, https://sw.kovidgoyal.net/swagger.json, https://sw.kovidgoya…”
   • [probe] “PROBE llms.txt: HTTP 404 at https://sw.kovidgoyal.net/llms.txt”
   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “Terminal graphics protocol”

   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
   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

   kitty—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
   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

   kitty—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 userPerform bulk operations across many items at once

   weight 2 · round to kitty
   WezTerm~partialprobed4/10

   WezTerm's CLI (`wezterm cli list/spawn/send-text/get-text`) exposes scriptable primitives that let a user enumerate and act on multiple panes/tabs/windows programmatically, and the runtime probe confirms headless multiplexer control works end-to-end. However, there's no evidence of a native 'bulk operation' command that targets many items in a single call — any bulk behavior would require external shell scripting/looping over the CLI primitives, which isn't documented. Missing for 10: documented batch/multi-target commands, evidence of scaling to large numbers of panes/tabs, and any built-in bulk-action feature beyond single-target CLI calls.

   • [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

   kitty~partialprobed5/10

   Kitty's remote-control API (`kitty @`) lets scripts list all windows/tabs (`ls`) and act on them (`send-text`, `close-window`, etc.), and the runtime probe confirms this loop works end-to-end, which enables scripting bulk actions across many windows/tabs. However, there's no first-party example or evidence of a built-in bulk/batch command (e.g., 'send to all windows' or looped multi-item operation) — it would require the user to write the looping logic themselves. Missing for 10: documented bulk/batch primitives operating on many items in one call, and independent evidence of someone actually scripting bulk operations at scale.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   proof ↗⚑ flag

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

   weight 3 · round to WezTerm
   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

   kitty—none0/10

   Evidence covers remote-control scripting, kittens, shell integration, and SSH kitten, but none describe a rule/event-trigger system that automatically fires actions on defined events (e.g., window open, output pattern, OS event) without manual invocation. Missing for 10: any documented 'on-event' hook/watcher/trigger mechanism and evidence of automatic action execution tied to specific events.

   ⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   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

   kitty—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 userVersion, review, and roll back my automations

   weight 1 · round drawn
   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

   kitty—none0/10

   Kitty's config (kitty.conf) and remote-control scripts are plain text files that a user could manually version with an external tool like git, but there is no evidence of any built-in versioning, review, or rollback mechanism for automations within kitty itself.

   ⚑ 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 drawn
   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

   kitty✓fullcommunity9/10

   kitty.conf is a plain-text config file format (kitty-docs-5, kitty-docs-15) that is well-documented and designed to be human-edited and portable, and community users confirm editing/config workflows (kitty-comm-1, kitty-comm-11, kitty-comm-18), consistent with typical dotfiles syncing across machines. missing for 10: no explicit first-party or community mention of dotfiles-repo syncing workflows or 'include' directives for multi-machine config management.

   • [claimed-docs] “kitty.conf - kitty”
   • [claimed-docs] “kitty.conf”
   • [community] “Not affiliated, but recently switched to Kitty from iTerm 2 on OS X on my main at-work MacBook Pro and I've been very impressed. It's snappy…”
   • [community] “Kitty is indeed great and I can corroborate the high performance by joining at the macOS activity monitor. Almost zero even with high speed …”
   • [community] “I'm also a macOS Kitty user. The config did take a minute to get used to... My favorite feature though is the auto layout... One thing I nev…”

   proof ↗⚑ flag

Fonts

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

   weight 2 · round to kitty
   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

   kitty✓fullcommunity8/10

   kitty documents dedicated font configuration (Changing kitty fonts, kitty.conf font options for family/bold/italic/fallback fonts and font_features tuning) and community reports strongly corroborate best-in-class ligature support (e.g., FiraCode ligatures cited as reason to switch from iTerm/Alacritty). Missing for 10: no first-party doc excerpt detailing per-font fallback selection algorithm or advanced font_features syntax beyond title listing, and no independent benchmark of fallback font correctness.

   • [claimed-docs] “Changing kitty fonts”
   • [claimed-docs] “kitty.conf - kitty”
   • [community] “I've switched to kitty a few months ago and it works REALLY well. It's very fast and has the best support for ligatures I've seen in a termi…”
   • [community] “I've been using Kitty for a month now. I really like it... I prefer it to iTerm because it's so. Damn. Fast... I know iTerm recently added a…”
   • [community] “I liked Alacritty well enough, but it doesn't support ligatures. Kitty does, so that's what I use.”

   proof ↗⚑ flag

Theming

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

   weight 2 · round to kitty
   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

   kitty✓fullclaimed8/10

   Docs explicitly cover changing kitty colors/themes (kitty-docs-9) and automatic OS light/dark theme switching (kitty-docs-21), plus general kitty.conf theming support (kitty-docs-5, 15, 18). Missing for 10: independent hands-on corroboration of the auto light/dark switching feature specifically, and details on theme ecosystem/community theme packs.

   • [claimed-docs] “Changing kitty colors”
   • [claimed-docs] “Change color themes automatically when the OS switches between light and dark”
   • [claimed-docs] “kitty.conf - kitty”
   • [claimed-docs] “Wide gamut color formats”

   proof ↗⚑ flag

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

   weight 2 · round to kitty
   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

   kitty~partialprobed7/10

   kitty's remote-control API (kitten @) exposes a broad surface — opening windows, sending text, reading text, changing layouts/tabs/titles, closing windows — verified hands-on via a runtime probe showing a full external agent-control loop working. However, this is a CLI/socket protocol rather than a formal documented 1:1 mapping guaranteeing full UI parity (e.g., no OpenAPI spec, and some UI-only interactive features like mouse-driven config or certain kitten interactions aren't confirmed as scriptable). Missing for 10: an explicit enumerated parity list or spec proving every UI action has an API equivalent, and independent third-party confirmation beyond the single runtime probe.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   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

   kitty~partialprobed5/10

   kitty's configuration lives in plain-text kitty.conf files that users own directly and the project itself is open-source, so there's no vendor lock-in and settings can be copied/ported freely, and remote-control scripting exposes window/session state as JSON. However there's no dedicated 'export my data' feature (e.g., session history, scrollback, or theme export as a documented bulk-export tool) beyond the inherent plain-text config files. missing for 10: explicit documented export/import of scrollback or session data, migration tooling, and independent confirmation that users treat config portability as a full data-export solution.

   • [claimed-docs] “kitty.conf - kitty”
   • [claimed-docs] “kitty.conf”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   kitty—none0/10

   No evidence in the pack references kitty's source code repository, license, or open-source status; all citations are docs, community sentiment, or remote-control probes, none addressing openness of the source.

   ⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to WezTerm
   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

   kitty—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

Multiplexing

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

   weight 3 · round drawn
   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

   kitty✓fullcommunity9/10

   Kitty natively supports windows, tabs, and multiple layouts with programmable splits, documented in first-party docs and confirmed by community users praising its window organization/auto layout — no external multiplexer needed. missing for 10: independent hands-on comparison specifically benchmarking pane/tab workflows against tmux/screen.

   • [claimed-docs] “Arrange windows”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [community] “Kitty is indeed great and I can corroborate the high performance by joining at the macOS activity monitor. Almost zero even with high speed …”
   • [community] “I'm also a macOS Kitty user. The config did take a minute to get used to... My favorite feature though is the auto layout... One thing I nev…”

   proof ↗⚑ flag

Quick access

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

   weight 1 · round drawn
   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

   kitty—none0/10

   kitty's docs cover window/tab layouts, remote control, and shell integration, but there is no evidence of a global-hotkey/quake-style dropdown summon feature (kitty is a normal windowed terminal, not an OS-level overlay); no docs or community reports mention such a capability, and some OS integration issues are noted (e.g. xterm-kitty TERM problems) but nothing about instant-summon hotkeys.

   ⚑ flag

Sessions

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

   weight 2 · round drawn
   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

   kitty~partialclaimed3/10

   Kitty documents 'startup sessions' to specify working environments (windows/tabs/layouts), which can be used to relaunch kitty into a saved arrangement, but the evidence pack gives only a one-line mention with no detail on automatic state capture or crash/restart recovery — sessions appear to be manually authored config files, not an automatic snapshot/restore mechanism. missing for 10: evidence of automatic session save on exit/crash, working-directory persistence specifics, and any hands-on/community confirmation that restore-after-crash actually works.

   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”

   proof ↗⚑ flag

Benchmarks

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

   weight 2 · round to kitty
   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

   kitty~partialcommunity3/10

   Kitty ships no vendor-published benchmark page, but community threads reference hardware-based latency comparisons showing kitty on par with Terminal.app and users corroborating low CPU/high speed while scrolling, giving power-users some measured performance signal outside official docs. This is thin: it's anecdotal community commentary, not a first-party benchmarks page or reproducible published methodology, and other community reports (e.g., slow cat throughput, slow startup) show the perception is inconsistent. missing for 10: an official kitty benchmarks/methodology page, first-party throughput/latency numbers, and independent reproducible benchmark data beyond single forum comments.

   • [community] “kitty is much better than the rest on latency, see hardware based measurements... showing kitty has the same latency as terminal.app on maco…”
   • [community] “Kitty is indeed great and I can corroborate the high performance by joining at the macOS activity monitor. Almost zero even with high speed …”
   • [community] “Gpu powered terminal emulator? This performs almost 100x worse than Mac OS Terminal.app. Cat-ting a long file takes 100x longer to draw on t…”
   • [community] “For me the difference was large enough to switch to st. Kitty's startup takes 5-10 times as long and it's very noticable for me. As I use te…”

   proof ↗⚑ flag

Rendering

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

   weight 3 · round to kitty
   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

   kitty!disputedcontradicted5/10

   Kitty's docs claim GPU-accelerated rendering (kitty-docs-24, kitty-docs-27) and many community reports corroborate snappy, low-latency performance even under heavy scrolling (kitty-comm-3, kitty-comm-11, kitty-comm-20), but other hands-on community reports concretely contradict this, citing catting a long file being '100x' slower than a non-GPU terminal, redraw/rendering glitches, GPU driver issues on many Nvidia laptops, and much slower startup vs other terminals (kitty-comm-4, kitty-comm-6, kitty-comm-9, kitty-comm-15). missing for 10: independent benchmark data reconciling these conflicting hands-on reports, official docs addressing known GPU/driver compatibility issues, and evidence of fixes for the reported rendering glitches.

   • [claimed-docs] “Terminal graphics protocol: allows the program running in the terminal, hereafter called the client, to render arbitrary pixel (raster) grap…”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [community] “I've switched to kitty a few months ago and it works REALLY well. It's very fast and has the best support for ligatures I've seen in a termi…”
   • [community] “Kitty is indeed great and I can corroborate the high performance by joining at the macOS activity monitor. Almost zero even with high speed …”
   • [community] “kitty is much better than the rest on latency, see hardware based measurements... showing kitty has the same latency as terminal.app on maco…”
   • [community] “Gpu powered terminal emulator? This performs almost 100x worse than Mac OS Terminal.app. Cat-ting a long file takes 100x longer to draw on t…”
   • [community] “This doesn't work on half of Nvidia-powered laptops: github.com/kovidgoyal/kitty/issues/456”
   • [community] “I tried it on MacOS (MBP retina) and damn, it renders text awfully.”
   • [community] “For me the difference was large enough to switch to st. Kitty's startup takes 5-10 times as long and it's very noticable for me. As I use te…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   kitty—none0/10

   No documentation or setting for telemetry collection or an opt-out mechanism appears anywhere in the evidence pack; kitty's docs cover remote control, graphics, shell integration, SSH, and config but never mention data collection or telemetry toggles. A vague community remark about unspecified 'privacy and security' concerns (kitty-comm-14) is not concrete evidence of telemetry, so it cannot establish disputed status either.

   • [community] “Usually I agree but the maintainer of kitty is bonkers rude. There have been several issues concerning privacy and security regarding kitty.…”

   proof ↗⚑ flag

Graphics

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

   weight 2 · round to kitty
   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

   kitty✓fullcommunity9/10

   Kitty documents and ships a dedicated Terminal Graphics Protocol allowing clients to render arbitrary pixel graphics inline, plus the icat kitten for displaying images, corroborated by community praise ('The diff and icat tools are must-haves'). This is a well-documented, first-party protocol spec, not just a claim. Missing for 10: independent hands-on verification specifically of the graphics protocol (probe evidence only covers remote-control, not icat/graphics rendering).

   • [claimed-docs] “Terminal graphics protocol”
   • [claimed-docs] “Terminal graphics protocol: allows the program running in the terminal, hereafter called the client, to render arbitrary pixel (raster) grap…”
   • [claimed-docs] “icat”
   • [community] “Just tried kitty on MacOS -- Loved it. The diff and icat tools are must-haves. Won't use iTerm anymore”

   proof ↗⚑ flag

Platforms

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

   weight 2 · round drawn
   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

   kitty✓fullcommunity8/10

   kitty is a cross-platform terminal emulator with official binary installers for macOS, Linux, and BSD, and documented support for Windows via WSL/other builds, using a single shared kitty.conf config file across platforms; community evidence confirms usage on macOS, Linux, and WSL2 with consistent behavior. missing for 10: no direct evidence of native Windows (non-WSL) support quality or explicit cross-platform config-parity testing, and no independent benchmark of identical config working unmodified across all three OSes.

   • [claimed-docs] “Install kitty - kitty”
   • [claimed-docs] “Install kitty”
   • [claimed-docs] “kitty.conf - kitty”
   • [claimed-docs] “kitty.conf”
   • [community] “Not affiliated, but recently switched to Kitty from iTerm 2 on OS X on my main at-work MacBook Pro and I've been very impressed. It's snappy…”
   • [community] “Kitty is the only thing I miss from Linux since I'm using WSL 2.”
   • [community] “I'm also a macOS Kitty user. The config did take a minute to get used to... My favorite feature though is the auto layout... One thing I nev…”

   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 kitty
   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

   kitty✓fullcommunity8/10

   The ssh kitten is explicitly documented to automatically set up shell integration, forward terminfo, transfer config, and reuse connections when SSHing to remote hosts, directly matching the story. Community reports mostly note a related manual workaround (TERM=xterm-kitty issues) rather than contradicting the kitten's own automatic integration feature. missing for 10: independent hands-on verification specifically of the ssh kitten (not just remote-control) and broader real-world confirmation across shells/OSes.

   • [claimed-docs] “Truly convenient SSH”
   • [claimed-docs] “The ssh kitten allows you to login easily to remote hosts, and automatically setup the environment there to be as comfortable as your local …”
   • [claimed-docs] “Shell integration”
   • [community] “Wow! Really like it. The windows organisation is well done... had to add TERM=xterm-256color to my Raspberry Pi's .bashrc to get it to play …”
   • [community] “I'm also a macOS Kitty user. The config did take a minute to get used to... My favorite feature though is the auto layout... One thing I nev…”
   • [community] “It's usable but i had a lot of issues. Copy pasty looses newlines, redraw issues in mutt, etc. It is absolutely 'forbidden' and unsupported …”

   proof ↗⚑ flag

Tmux

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

   weight 2 · round drawn
   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

   kitty~partialcommunity6/10

   Kitty doesn't ship a native tmux-like multiplexer/control-mode substitute for tmux itself, but it supports running tmux inside it (community confirms zsh/tmux setups work with tweaks) and offers its own overlapping native features (windows/tabs/layouts, remote control, sessions) as an alternative to tmux, plus SSH kitten integration for remote sessions. missing for 10: documented native tmux control-mode protocol/compatibility layer, first-party guidance on using tmux inside kitty, and confirmation that kitty's own multiplexing fully replaces tmux workflows for SSH users.

   • [claimed-docs] “Arrange windows”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [claimed-docs] “Truly convenient SSH”
   • [claimed-docs] “The ssh kitten allows you to login easily to remote hosts, and automatically setup the environment there to be as comfortable as your local …”
   • [community] “Not affiliated, but recently switched to Kitty from iTerm 2 on OS X on my main at-work MacBook Pro and I've been very impressed. It's snappy…”
   • [community] “Wow! Really like it. The windows organisation is well done... had to add TERM=xterm-256color to my Raspberry Pi's .bashrc to get it to play …”

   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 kitty
   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

   kitty✓fullprobed10/10

   kitty ships a documented remote-control protocol (kitty @ commands) letting scripts/agents open windows, send text, read output, and manage layouts, and this was independently verified hands-on end-to-end (ls, send-text, get-text, close-window) confirming a real programmatic control loop.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   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 kitty
   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

   kitty✓fullprobed9/10

   Kitty ships a documented kittens system extensible in Python, plus remote-control scripting APIs (verified hands-on in kitty-probe-rt-1) and config/mapping extensibility, directly matching the story of extending the terminal with real-language scripts/plugins beyond built-ins. Missing for 10: independent third-party evidence of custom kitten development (community citations focus on performance/UX rather than plugin authoring).

   • [claimed-docs] “Extend with kittens”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”
   • [claimed-docs] “Completely customizing the matching and actions of the kitten”

   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 kitty
   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

   kitty✓fullprobed9/10

   Kitty's official docs explicitly advertise startup sessions to specify working environments plus programmable tabs/splits/layouts, configurable via kitty.conf and session files, and remote-control scripting lets a single command open/arrange a full workspace. Runtime probe further corroborates the control/scripting loop working hands-on. Missing for 10: no independent community example specifically demonstrating a startup-session file opening a full project workspace in one command.

   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [claimed-docs] “Arrange windows”
   • [claimed-docs] “kitty.conf - kitty”
   • [claimed-docs] “Control kitty from scripts”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   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 kitty
   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

   kitty✓fullprobed10/10

   kitty's remote-control system is extensively documented (opening windows, sending text, querying state, changing titles) and independently verified hands-on: a probe launched kitty with remote control enabled, listed windows/state as JSON, sent text, read output back, and closed the window — confirming the full documented CLI/IPC control loop works as claimed.

   • [claimed-docs] “Control kitty from scripts”
   • [claimed-docs] “kitty can be controlled from scripts or the shell prompt. You can open new windows, send arbitrary text input to any window, change the titl…”
   • [claimed-docs] “Control it from scripts or the shell; Extend with kittens using the Python language; Use startup sessions to specify working environments; P…”
   • [probe] “official CLI documented at https://sw.kovidgoyal.net/kitty/remote-control/”
   • [probe] “PROBE runtime (recorded 2026-09-04, kitty 0.48.2 via official installer): launched `kitty --detach -o allow_remote_control=socket-only --lis…”

   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 to kitty
   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

   kitty~partialclaimed4/10

   kitty's shell-integration docs confirm prompt-aware features (jumping between prompts, viewing last command's output, cursor movement while editing) but the evidence pack never documents exit-status marking, command duration tracking, or notifications when long commands finish — the specific command-aware signals the story asks about. Missing for 10: exit status display evidence, duration/timing tracking evidence, and completion notification evidence for long-running commands.

   • [claimed-docs] “Shell integration”
   • [claimed-docs] “Shell integration with zsh, fish and bash enables features such as jumping to previous prompts in the scrollback, viewing the output of the …”

   proof ↗⚑ flag

Marks

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

   weight 2 · round to kitty
   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

   kitty✓fullclaimed8/10

   Kitty's official shell integration docs explicitly state it enables jumping to previous prompts in scrollback, viewing last command output, and command-mark-based navigation for zsh/fish/bash. This is a first-party documented core feature directly matching the story. Missing for 10: independent hands-on community confirmation specifically of prompt-jumping/scrollback navigation (community evidence covers other features like speed/ligatures but not this one).

   • [claimed-docs] “Shell integration”
   • [claimed-docs] “Shell integration with zsh, fish and bash enables features such as jumping to previous prompts in the scrollback, viewing the output of the …”

   proof ↗⚑ flag

Discoverability

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

   weight 1 · round drawn
   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

   kitty—none0/10

   Kitty's evidence covers remote control, kittens, shell integration, and hints/selection features, but nothing describes a searchable command palette UI for discovering and running actions—kitty's action system is configured via keybindings in kitty.conf, not an interactive palette.

   ⚑ flag

Hyperlinks

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

   weight 2 · round drawn
   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

   kitty~partialclaimed4/10

   kitty ships a dedicated 'Hints' kitten (kitty-docs-17) that is documented to let users select URLs/paths/etc. from terminal output via keyboard, and kitty's kittens system (kitty-docs-8) enables extensibility like this, supporting the story's core capability. However, the evidence pack only lists a title reference with no detail on mouse-click behavior, configuration, or independent confirmation from users. Missing for 10: detailed docs excerpt on hints/URL-click behavior, mouse-click-to-open-url specifics, and community/hands-on corroboration of this exact feature.

   • [claimed-docs] “Hints”
   • [claimed-docs] “Extend with kittens”

   proof ↗⚑ flag

Scrollback

1. developerSearch my scrollback quickly and jump between matches

   weight 2 · round to WezTerm
   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

   kitty~partialclaimed5/10

   Kitty's shell-integration docs mention jumping to previous prompts in the scrollback and viewing the last command's output via a pager (which supports searching), giving partial support for quick scrollback navigation, but there's no explicit documentation of a dedicated 'search scrollback and cycle through matches' feature (e.g., a search kitten or highlighted match navigation) in the evidence pack. Missing for 10: explicit docs on search-in-scrollback UI/keybindings, match highlighting/cycling, and independent user confirmation of this specific workflow.

   • [claimed-docs] “Shell integration with zsh, fish and bash enables features such as jumping to previous prompts in the scrollback, viewing the output of the …”

   proof ↗⚑ flag