Ghostty vs kitty

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

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

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

   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 userUse an official CLI

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

   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

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

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

   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

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

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

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

   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

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

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

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

   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 userDefine rules that trigger actions automatically on events

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

   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

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

   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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   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