Warp vs kitty

Agent access

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

   weight 2 · round to Warp
   Warp✓fullprobed9/10

   Warp publishes a dedicated llms.txt (confirmed live via HTTP 200 probe at docs.warp.dev/llms.txt) describing its agentic docs, plus a whole family of agent-oriented doc pages under the _llms-txt/ path (code, warp-agent-cli, automation-platform, api-reference, knowledge-and-collaboration, factories), giving AI agents a structured, machine-readable entry point into Warp's documentation. Missing for 10: no independent/community confirmation that an external agent has actually consumed this llms.txt successfully.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.warp.dev/llms.txt # Warp > Documentation for Warp, the agentic development environment. Covers the…”
   • [claimed-docs] “Warp comes with a native code editor designed for quick, in-flow edits alongside your Agent conversations... with essentials like syntax hig…”
   • [claimed-docs] “Because it’s a regular command-line program, it works in any terminal emulator, including over SSH.”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [claimed-docs] “open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review.”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “The Admin Panel gives team administrators centralized control over organization-wide Warp settings, including agent autonomy, privacy contro…”
   • [claimed-docs] “A software factory takes in requests (bug reports, feature specs, support escalations), and a coordinated fleet of agents works them into a …”

   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 Warp
   Warp✓fullclaimed8/10

   Warp ships the Oz CLI explicitly documented for running/managing cloud agents 'from any terminal, script, or CI pipeline,' with API keys for headless/non-interactive auth 'ideal for CI pipelines, headless servers, and containers,' plus the standalone Warp Agent CLI that works over SSH/any terminal without the desktop app. Schedules and webhook/event triggers further support automation use cases outside interactive sessions. Missing for 10: independent/hands-on verification of actual CI pipeline runs and more detail on exit codes/output parsing for scripting.

   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “Because it’s a regular command-line program, it works in any terminal emulator, including over SSH.”
   • [claimed-docs] “The Warp Agent CLI lets you switch directories while in an agent session, and even run agents on remote machines without installing remote b…”
   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Schedules: Run recurring tasks like dependency updates or dead code removal”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”

   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 to Warp
   Warp✓fullclaimed9/10

   Warp has documented, first-party support for connecting MCP servers to extend its agents ('MCP servers extend Warp's local agents... acting as plugins for Warp'), plus explicit CLI support (Oz CLI) to 'connect MCP servers like GitHub and Linear' and agent profiles to control MCP server usage. This is corroborated across multiple doc pages describing MCP as a first-class integration point for tool use. Missing for 10: independent/hands-on community confirmation of MCP server usage specifically (community evidence covers other topics, not MCP directly).

   • [claimed-docs] “Connect Warp AI to any tool via the Model Context Protocol. Pull context from databases, APIs, docs, and internal services so the AI underst…”
   • [claimed-docs] “MCP servers extend Warp’s local agents in a modular, flexible way by exposing custom tools or data sources through a standardized interface …”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “Agent Profiles - Use agent profiles to control what the agent can access, how it behaves, and where it can act, including file access, comma…”

   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

4. ai-native userUse an official CLI

   weight 2 · round to kitty
   Warp✓fullclaimed8/10

   Warp ships multiple official CLIs — the standalone Warp Agent CLI usable in any terminal/SSH (warp-docs-23, warp-docs-41, warp-docs-59, warp-docs-69) and the Oz CLI for managing cloud agents in scripts/CI (warp-docs-22, warp-docs-37, warp-docs-52) — both extensively documented as first-party, agent-native tooling with API key auth for headless use (warp-docs-63). Missing for 10: independent/hands-on community corroboration specifically validating the CLI's real-world reliability (community evidence covers the desktop app, not the CLI).

   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Warp Agent CLI lets you switch directories while in an agent session, and even run agents on remote machines without installing remote b…”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “The Warp Agent is now available as a standalone CLI that you can use anywhere – Ghostty, iTerm 2, VS Code, built-in Windows and Mac Terminal…”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “Because it’s a regular command-line program, it works in any terminal emulator, including over SSH.”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “It creates and maintains its own pseudoterminal (PTY), which lets you and the agent execute commands and interact with running processes thr…”

   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
   Warp✓fullprobed8/10

   Warp explicitly advertises an 'API, CLI, SDK and MCP' platform (warp-docs-42), and a live probe confirms a real OpenAPI spec is served at docs.warp.dev/openapi.json (warp-probe-2), backed by a documented CLI reference (warp-probe-3) and API-key based headless auth for the Oz CLI (warp-docs-63) plus scriptable agent control (warp-docs-22, warp-docs-37, warp-docs-52). Missing for 10: independent/third-party corroboration of API usage and more detailed public API reference content beyond the openapi.json existence check.

   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.warp.dev/reference/cli”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”

   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 userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Warp
   Warp~partialclaimed6/10

   Warp's docs describe API Keys for authenticating the Oz CLI headlessly (warp-docs-63) and Agent Profiles that constrain what an agent can access (file access, command execution, MCP server usage) plus admin-level controls over agent autonomy (warp-docs-64, warp-docs-66), which together approximate least-privilege scoping for agent credentials/access. However, there's no explicit documentation of per-credential scopes/permissions tied to individual API keys (e.g., read-only vs write, resource-level restrictions) or independent confirmation this works as a formal least-privilege credential system. Missing for 10: explicit scoped-permission API key documentation, examples of granular credential scoping, and independent/hands-on verification.

   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “Agent Profiles - Use agent profiles to control what the agent can access, how it behaves, and where it can act, including file access, comma…”
   • [claimed-docs] “The Admin Panel gives team administrators centralized control over organization-wide Warp settings, including agent autonomy, privacy contro…”

   proof ↗⚑ flag

   kitty—none0/10

   kitty's remote-control feature allows scripts to control the terminal, but there is no evidence of scoped or least-privilege credential issuance — the remote control model uses a single unix socket/password with allow/deny options, not per-agent scoped API keys or tokens. No documentation or probe evidence shows credential scoping, permission tiers, or revocable least-privilege tokens for agents.

   ⚑ flag

7. ai-native userSubscribe to events via webhooks

   weight 2 · round to Warp
   Warp~partialclaimed4/10

   Warp's automation platform docs mention 'Triggers: React to events from Slack, Linear, GitHub, or custom webhooks' and cloud agents 'triggered by... integrations like Slack and GitHub,' indicating webhook-based triggering exists, but this describes Warp consuming/reacting to inbound webhooks to kick off agents rather than a documented outbound webhook subscription mechanism for external systems to receive Warp's own events. Missing for 10: explicit documentation of an outbound webhook/event-subscription API, payload schema, or delivery guarantees, and independent confirmation of this feature working.

   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”

   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

Agentic features

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

   weight 2 · round to Warp
   Warp✓fullclaimed8/10

   Warp's Automation Platform explicitly supports cloud agents that run autonomously in the background, triggered by schedules, webhooks, or integrations like Slack/GitHub/Linear (warp-docs-4, warp-docs-5, warp-docs-60), with observability/audit trails (warp-docs-53, warp-docs-61) and CLI/API control via Oz CLI for headless/CI use (warp-docs-22, warp-docs-37, warp-docs-63). missing for 10: independent/hands-on verification of autonomous background runs actually completing unattended, and more detail on failure handling/reliability at scale.

   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Schedules: Run recurring tasks like dependency updates or dead code removal”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [claimed-docs] “open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review.”
   • [claimed-docs] “Observability: Every run is tracked, auditable, and shareable with your team”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”

   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
   Warp—none0/10

   Warp does expose an OpenAPI spec (warp-probe-2) and API/CLI reference docs (warp-docs-63, warp-probe-3), so the axis of an API reference applies given Warp's platform ambitions (warp-docs-42). However, there is no evidence of an interactive reference UI with runnable/'try it out' examples — the pack only shows a raw openapi.json file and static CLI reference pages, not an interactive explorer.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.warp.dev/reference/cli”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”

   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 to Warp
   Warp✓fullprobed8/10

   A probe directly confirms an OpenAPI JSON spec is served at docs.warp.dev/openapi.json returning a valid 'openapi' key, and docs reference an API/CLI/SDK/MCP platform with API key management, corroborating a machine-readable spec exists. Missing for 10: no independent/third-party confirmation of spec completeness or versioning, and no docs page walking through consuming the spec.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”

   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
   Warp—none0/10

   Warp exposes an API, CLI, SDK, and MCP platform (warp-docs-42, warp-probe-2 openapi.json), so API versioning is a fair axis, but no evidence pack item documents API version numbers, a changelog, or any formal deprecation policy for these interfaces.

   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.warp.dev/reference/cli”

   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 to Warp
   Warp✓fullcommunity9/10

   Warp's built-in Agent Mode is extensively documented to plan and execute multi-step terminal tasks (writing code, running commands, controlling interactive/full-screen apps, iterating) while keeping the user in the loop via conversation view, follow-ups, and approval/steering ('watch, steer, and hand off runs'). This is corroborated across many first-party docs and independent community mentions of using it as a daily driver for AI-assisted terminal work, though some hands-on complaints exist about unrelated reliability/telemetry issues rather than the core delegate-and-approve workflow itself. Missing for 10: independent hands-on verification specifically of the approval/plan-then-execute step (vs. general agent usage), and confirmation the community complaints don't touch this exact workflow.

   • [claimed-docs] “Describe what you want to build and let Warp's built‑in agent handle the rest — writing code, running commands, and iterating until the task…”
   • [claimed-docs] “Write and refactor code across your codebase * Debug issues and fix errors * Run commands and interpret results * Plan and execute mul…”
   • [claimed-docs] “the Warp Agent can now run and control long-running or full-screen terminal applications. The agent can provide input when prompted, navigat…”
   • [claimed-docs] “By default, if you ask an AI query immediately after interacting in Agent Mode, your query is sent as a **follow-up** to the current convers…”
   • [claimed-docs] “Conversations are tied to sessions and you can run multiple Agent Mode conversations simultaneously in different windows, tabs, or panes.”
   • [claimed-docs] “any surface — watch, steer, and hand off runs from web, mobile, terminal, or IDE.”
   • [community] “Warp is great - I use it as my daily terminal. The best features are being able to edit commands, chunking the output into blocks and AI gen…”
   • [community] “My daily driver for a few months now, even after trying Rio/Ghostty/Wezterm... Favorite feature is the notification when a long running comm…”

   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 to Warp
   Warp!disputedcontradicted4/10

   Warp docs promise granular control (secret redaction, no training use, telemetry opt-out on paid plans, ZDR for Business/Enterprise) and note telemetry can be monitored/disabled, but this is undercut by concrete community reports: one HN thread describes Warp silently sending terminal session data to LLMs via 'Prompt Suggestions'/'Next Command' without explicit consent (warp-comm-1), and multiple independent users report being confronted with a mandatory login prompt and uninstalling immediately (warp-comm-5, warp-comm-6, warp-comm-16), even though a Warp co-founder claims the login requirement was removed (warp-comm-7). Docs also admit telemetry must stay on to use AI on the Free plan (warp-docs-33), meaning full AI use without any data leaving isn't unconditional. missing for 10: a documented explicit toggle to fully disable AI without any account/login step on the free tier, and resolution of the community claim of undisclosed data transmission.

   • [claimed-docs] “Warp does not allow OpenAI or Anthropic to use your data for model training. Our "hands off" approach also means your terminal input and out…”
   • [claimed-docs] “Monitor telemetry in real-time with Warp’s native Network Log. Opt out of telemetry at any time”
   • [claimed-docs] “Telemetry must be enabled to use AI features on the Free plan, while paid plans can opt out at any time and continue using Warp, including A…”
   • [claimed-docs] “Business and Enterprise plans are covered by our Zero Data Retention (ZDR) agreement. No AI interaction or console data is ever collected.”
   • [claimed-docs] “Read a complete list of all the telemetry events that get sent for app analytics ... Opt out of telemetry at any time”
   • [claimed-docs] “Warp unconditionally applies Secret Redaction in all AI interactions to ensure that any sensitive data is _never_ collected or sent to third…”
   • [community] “Warp silently sends terminal session data to LLMs via 'Prompt Suggestions' and 'Next Command' features without explicit consent, discovered …”
   • [community] “I tried Warp once... it showed me a login prompt. Perhaps I mistakenly downloaded a login prompt app instead of a terminal app? I promptly u…”
   • [community] “I remember seeing this terminal emulator, deciding to give it a shot, and being asked to sign in. I have never uninstalled a program faster …”
   • [community] “Warp co-founder: fair criticism, and this is the reason we removed the login requirement... the point of the login is that we have features …”
   • [community] “They have also innovated by requiring login (into a console!!)... Today they have heaps of telemetry, so a privacy nightmare. This is a term…”

   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

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Warp
   Warp~partialclaimed6/10

   Warp supports running many agents concurrently across repos/tasks (warp-docs-28), cloud agents triggered by schedules/webhooks at scale (warp-docs-4, warp-docs-5, warp-docs-60), and a 'software factory' pattern coordinating a fleet of agents into mergeable PRs (warp-docs-68), which together support bulk/parallel operations across many items. However, there is no explicit documentation of a UI or command for batch-selecting many items (files, repos, tasks) and applying one operation across all of them in a single bulk action, nor independent/hands-on evidence confirming this scales well in practice. missing for 10: concrete bulk-selection/batch-apply UI or command, first-party docs quantifying scale limits, independent verification that parallel/bulk agent runs work reliably at scale.

   • [claimed-docs] “Parallelism: Run many agents concurrently across repos or tasks”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [claimed-docs] “A software factory takes in requests (bug reports, feature specs, support escalations), and a coordinated fleet of agents works them into a …”
   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Schedules: Run recurring tasks like dependency updates or dead code removal”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”

   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 Warp
   Warp✓fullclaimed8/10

   Warp's Automation Platform explicitly supports Triggers reacting to events from Slack, Linear, GitHub, or custom webhooks, plus Schedules for recurring tasks, and cloud agents described as 'triggered by system events, schedules, or integrations like Slack and GitHub' with full observability/audit trails. This directly matches the story of defining rules that trigger automatic actions on events. Missing for 10: independent/hands-on verification of the trigger system in practice (community evidence focuses on core terminal/agent issues, not the automation/trigger feature specifically).

   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Schedules: Run recurring tasks like dependency updates or dead code removal”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [claimed-docs] “open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review.”
   • [claimed-docs] “Observability: Every run is tracked, auditable, and shareable with your team”

   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 to Warp
   Warp✓fullclaimed8/10

   Warp documents explicit 'Schedules' functionality for cloud agents ('Run recurring tasks like dependency updates or dead code removal') alongside 'Triggers' for event-based automation, plus cloud agents described as 'triggered by system events, schedules, or integrations' and managed via the Oz CLI for scripting/CI. This directly matches the story of scheduling recurring jobs/workflows. Missing for 10: independent/hands-on confirmation of the scheduling feature working reliably, and more detail on scheduling configuration (cron-like syntax, frequency options).

   • [claimed-docs] “Triggers: React to events from Slack, Linear, GitHub, or custom webhooks”
   • [claimed-docs] “Schedules: Run recurring tasks like dependency updates or dead code removal”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”

   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

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

   weight 1 · round to Warp
   Warp~partialclaimed4/10

   Warp provides strong review/observability for automations (run transcripts showing prompt, plan, commands, logs, shareable for team review) and lets you save/share workflows via Warp Drive, but there is no documented versioning or rollback mechanism for automations (e.g., no version history, diffing, or revert capability for schedules/triggers/workflows). missing for 10: explicit version history for saved automations, ability to roll back to a prior automation version, changelog/diff view for automation edits.

   • [claimed-docs] “Warp lets you save your most important workflows in Warp Drive so you can run them on‑demand or share with your team.”
   • [claimed-docs] “Observability: Every run is tracked, auditable, and shareable with your team”
   • [claimed-docs] “open the run transcript; inspect the prompt, plan, commands, logs, and output; and share the session link with teammates for review.”
   • [claimed-docs] “Warp lets you save your most important workflows in Warp Drive so you can run them on‑demand or share with your team. Let Warp AI handle the…”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”

   proof ↗⚑ 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
   Warp~partialclaimed4/10

   Warp's open-source announcement mentions shipping a new settings file explicitly for 'programmatic control over settings and easy portability between devices' (warp-docs-40), which speaks directly to the dotfiles/sync use case, but this is a single passing mention with no documentation of its format, scope, or actual dotfiles-style workflow. Other config-adjacent features (theme OS-sync, session restoration) are separate app-state features, not plain-text portable config. Missing for 10: dedicated docs on the settings file format/location, confirmation it covers full app config (keybindings, workflows, themes), and independent/community corroboration of dotfiles-style syncing across machines.

   • [claimed-docs] “we are shipping a (long-overdue) settings file so that users and agents get programmatic control over settings and easy portability between …”
   • [claimed-docs] “Warp supports synchronizing your theme with the OS’s light and dark themes.”
   • [claimed-docs] “Restore your windows, tabs, panes, and recent Blocks automatically when you relaunch Warp.”

   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
   Warp—none0/10

   No evidence in the pack mentions font configuration, ligatures, fallback fonts, or font tuning of any kind; documentation focuses on themes, appearance sync, and agent features, not typography settings.

   ⚑ 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 drawn
   Warp✓fullclaimed8/10

   Warp's docs explicitly support custom themes, auto-generating themes from a background image, and syncing theme with OS light/dark mode (warp-docs-19, warp-docs-20), directly matching the story. Missing for 10: independent/community corroboration of theming reliability and more detail on breadth of built-in theme palette.

   • [claimed-docs] “Automatically create new themes based on a background image.”
   • [claimed-docs] “Warp supports synchronizing your theme with the OS’s light and dark themes.”

   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
   Warp~partialprobed6/10

   Warp explicitly positions itself as 'API, CLI, SDK and MCP built as a platform,' with the Oz CLI enabling agent creation, monitoring, MCP connections, and authentication without the desktop app, and a live OpenAPI spec — showing substantial API/CLI parity for agent workflows. But the story demands full UI-equivalent capability, and evidence doesn't confirm parity for many UI-only features (theming, session restoration, conversation UI, code editor) nor is there independent verification that the API surface is fully complete. missing for 10: independent confirmation of full feature parity, evidence that UI-specific features (themes, editor, session restore) are also API-accessible

   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”
   • [claimed-docs] “any surface — watch, steer, and hand off runs from web, mobile, terminal, or IDE.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “Agent Profiles - Use agent profiles to control what the agent can access, how it behaves, and where it can act, including file access, comma…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.warp.dev/reference/cli”

   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
   Warp~partialclaimed3/10

   Warp documents a settings file for 'programmatic control over settings and easy portability between devices' and open-sources its client code, but there's no documented feature for exporting conversation history, Warp Drive workflows, or agent run data in open formats for full user data portability. missing for 10: explicit full data export tooling, open-format export of conversation/session history, Warp Drive workflow export, independent confirmation users can fully migrate away with their data.

   • [claimed-docs] “we are shipping a (long-overdue) settings file so that users and agents get programmatic control over settings and easy portability between …”
   • [claimed-docs] “Read and audit Warp’s client source code at warpdotdev/warp, open source under AGPL v3”
   • [claimed-docs] “Warp’s source code is now available at github.com/warpdotdev/warp with an AGPL license.”

   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 Warp
   Warp✓fullclaimed8/10

   Warp explicitly published its client source code on GitHub under the AGPL v3 open-source license, documented in both its privacy docs and a dedicated blog post announcing the move to open source. missing for 10: independent/third-party confirmation of the full scope of open-sourced code (e.g., whether cloud/server-side agent components are also included) and any hands-on community audit of the repository beyond the vendor's own announcement.

   • [claimed-docs] “Read and audit Warp’s client source code at warpdotdev/warp, open source under AGPL v3”
   • [claimed-docs] “Warp’s source code is now available at github.com/warpdotdev/warp with an AGPL license.”
   • [claimed-docs] “Read and audit Warp’s client source code at `warpdotdev/warp`, open source under AGPL v3”

   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 to Warp
   Warp~partialcommunity4/10

   Warp's client is open-sourced under AGPL v3 (warpdotdev/warp) so the terminal client itself can be inspected and self-hosted/built from source, and cloud agents are described as able to run 'on Warp's cloud infrastructure or your own,' suggesting some self-hosting of agent execution. However, there's no documented path to self-host the full core product—AI model routing, backend services, and account/login (required per warp-comm-6/7) remain tied to Warp's proprietary cloud, and no deployment/on-prem guide is evidenced. Missing for 10: a documented self-hosted backend/server deployment, evidence that AI/model-routing works without Warp's cloud, and independent confirmation of a working self-hosted setup.

   • [claimed-docs] “Read and audit Warp’s client source code at warpdotdev/warp, open source under AGPL v3”
   • [claimed-docs] “Warp’s source code is now available at github.com/warpdotdev/warp with an AGPL license.”
   • [claimed-docs] “Cloud agents are autonomous, background agents that run on Warp’s cloud infrastructure or your own, triggered by system events, schedules, o…”
   • [community] “Warp co-founder: fair criticism, and this is the reason we removed the login requirement... the point of the login is that we have features …”

   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 to kitty
   Warp~partialclaimed6/10

   Docs confirm panes exist alongside tabs and windows as first-class session units (agent conversations run in "windows, tabs, or panes" and session restoration recreates "windows, tabs, and panes"), showing built-in multiplexing without needing tmux. However the pack lacks any detail on pane-splitting mechanics, keyboard shortcuts, or layout management, and no independent/hands-on account discusses pane usage specifically. Missing for 10: dedicated documentation on split/pane creation and navigation, independent user confirmation of pane workflow.

   • [claimed-docs] “Conversations are tied to sessions and you can run multiple Agent Mode conversations simultaneously in different windows, tabs, or panes.”
   • [claimed-docs] “Restore your windows, tabs, panes, and recent Blocks automatically when you relaunch Warp.”
   • [claimed-docs] “Continue previous threads with follow-ups, manage conversation history, attach context from blocks and files, and run multiple conversations…”

   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
   Warp—none0/10

   No evidence in the pack mentions a global hotkey or quake-style dropdown/instant-summon window feature; Warp's docs focus on session restoration, panes/tabs, and AI agent features, not a system-wide invocation shortcut.

   ⚑ 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 Warp
   Warp✓fullclaimed8/10

   Warp's docs explicitly describe session restoration that restores windows, tabs, panes, and recent Blocks automatically on relaunch, directly matching the story. Missing for 10: independent/hands-on corroboration of restore reliability after crashes (only vendor docs cited), and no detail on working-directory restoration specifics.

   • [claimed-docs] “Restore your windows, tabs, panes, and recent Blocks automatically when you relaunch Warp.”
   • [claimed-docs] “Session restoration allows you to quickly pick up where you left off in your previous terminal session.”
   • [claimed-docs] “Sometimes, you may want to prevent a sensitive Block from being saved on your computer, or you may want to clear blocks from a machine entir…”

   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
   Warp—none0/10

   No published benchmarks, latency, or throughput figures appear anywhere in the evidence pack; documentation focuses on features and privacy, while community posts mention performance complaints but no measured numbers. missing for 10: published benchmark data, latency/throughput measurements, any comparative performance testing.

   ⚑ 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
   Warp—none0/10

   The evidence pack contains no first-party documentation claiming GPU-accelerated rendering or describing rendering performance under heavy output; instead, community reports describe UI glitches, broken behavior, and instability during heavy use (e.g., 'horribly broken... UI glitches', 'random failures, stopping of agents'), and one commenter notes the terminal is 'just Alacritty' with no Warp-specific performance claims. Since no vendor documentation asserts this capability, there's nothing concrete to substantiate 'full' or 'partial', and the negative community signals reinforce a 'none' verdict rather than a dispute of an explicit claim.

   • [community] “Warp is so horribly broken right now and has been for weeks. Multiple github issues on consistent issue writing file. On top of that UI glit…”
   • [community] “I've been a Pro user for several months (use < 1000 credits a month) - but I've noticed a real reduction in quality over the past month or s…”
   • [community] “Warp is a terrible product, and I have nothing nice to say about them. But look at modern terminals like Kitty or Ghostty... mouse support t…”
   • [community] “Their terminal is just Alacritty... The terminal emulator was never their selling point, the AI wrapper was.”

   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 to Warp
   Warp~partialcommunity7/10

   Warp's docs explicitly describe a telemetry opt-out and a Network Log to monitor telemetry in real time, and state paid plans can opt out at any time while still using AI. However, the Free plan requires telemetry to be enabled to use AI features, meaning opt-out isn't universal, and community commentary (warp-comm-1, warp-comm-16) raises concerns about undisclosed data sharing and 'heaps of telemetry,' which tempers full confidence though it doesn't concretely disprove the opt-out mechanism itself. missing for 10: independent verification that opt-out fully works with no residual telemetry, and free-tier parity for full opt-out.

   • [claimed-docs] “Monitor telemetry in real-time with Warp’s native Network Log. Opt out of telemetry at any time”
   • [claimed-docs] “Telemetry must be enabled to use AI features on the Free plan, while paid plans can opt out at any time and continue using Warp, including A…”
   • [claimed-docs] “Read a complete list of all the telemetry events that get sent for app analytics ... Opt out of telemetry at any time”
   • [claimed-docs] “Opt out of telemetry at any time”
   • [claimed-docs] “Monitor telemetry in real-time with Warp’s native Network Log * Opt out of telemetry at any time”
   • [community] “They have also innovated by requiring login (into a console!!)... Today they have heaps of telemetry, so a privacy nightmare. This is a term…”

   proof ↗⚑ 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
   Warp—none0/10

   No evidence in the pack mentions a terminal graphics protocol (e.g., Sixel, Kitty graphics protocol, iTerm2 inline images) or inline image/rich graphics rendering in Warp's terminal. Evidence only covers AI agents, MCP, telemetry, themes, and session restoration.

   ⚑ 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
   Warp~partialcommunity5/10

   Evidence shows Warp exposes platform-specific keybindings for macOS, Windows, and Linux (docs-49), a settings file enabling config portability across devices (docs-40), and CLI/agent components that work over SSH in any terminal (docs-59), implying cross-platform availability. However, there is no explicit doc confirming identical native app experience on all three OSes, and community reports describe Warp being broken specifically under WSL/Windows-via-SSH scenarios (warp-comm-10), undercutting a seamless 'same terminal, same config' experience. missing for 10: explicit first-party confirmation of feature parity across macOS/Linux/Windows, documented config-sync mechanism beyond a settings file, and independent corroboration that the same setup truly works identically on all three platforms.

   • [claimed-docs] “Open the **Conversations menu** (`⌘+Y` on macOS, `Ctrl+Shift+Y` on Windows/Linux), select a conversation, and then enter your query.”
   • [claimed-docs] “we are shipping a (long-overdue) settings file so that users and agents get programmatic control over settings and easy portability between …”
   • [claimed-docs] “Because it’s a regular command-line program, it works in any terminal emulator, including over SSH.”
   • [community] “Warp is so horribly broken right now and has been for weeks. Multiple github issues on consistent issue writing file. On top of that UI glit…”

   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
   Warp—none0/10

   Warp's docs mention running the `warp` agent CLI over SSH (warp-docs-3) but that's about launching an agent conversation, not the terminal itself carrying terminfo, shell integration, and config when SSHing into remote hosts. No evidence describes Warp's terminal propagating its shell integration/terminfo to remote hosts, and community reports (warp-comm-10, warp-comm-14) note broken functionality (file/diff explorer, code indexing) specifically over SSH connections, further indicating the core integration doesn't extend cleanly to remote sessions.

   • [claimed-docs] “Run the `warp` command to start a conversation in whichever terminal you already use, over SSH, or on a machine where Warp isn’t installed.”
   • [community] “Warp is so horribly broken right now and has been for weeks. Multiple github issues on consistent issue writing file. On top of that UI glit…”
   • [community] “Nearly everything about the experience of a terminal is better than iTerm though? Very nice having the terminal treated like a text file. It…”

   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
   Warp—none0/10

   The evidence pack contains no mention of tmux support, tmux control mode, or any documented native tmux integration in Warp's docs or community discussion — Warp's session/pane features (blocks, session restoration) are its own proprietary system, not tmux. Since terminal emulators are a fair category for this axis, absence of evidence yields 'none'.

   ⚑ 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
   Warp~partialprobed6/10

   Warp exposes a genuine programmatic surface — an OpenAPI spec (confirmed live at docs.warp.dev/openapi.json), an Oz CLI with API keys for headless/CI control, MCP as a plugin interface, and a documented Warp Agent CLI that spins up its own PTY so an agent can run commands, provide input, and control full-screen apps (warp-docs-69, warp-docs-24, warp-docs-32). This supports agent-driven terminal automation, but the evidence never documents a protocol/API specifically for creating or managing Warp's terminal panes/windows or reading raw pane output — the API/CLI focus is on running and orchestrating agents rather than exposing the terminal UI itself as a controllable surface. Missing for 10: documented pane-creation/window-management API, explicit read-output API distinct from agent conversation transcripts, and independent/hands-on confirmation of external programmatic terminal control.

   • [claimed-docs] “API, CLI, SDK and MCP built as a platform, not a vertical product or AI teammate.”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “It creates and maintains its own pseudoterminal (PTY), which lets you and the agent execute commands and interact with running processes thr…”
   • [claimed-docs] “You can run full-screen and interactive terminal apps like sqlite and python through the agent session. Warp Agent can also control those ap…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.warp.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”

   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
   Warp—none0/10

   Warp's extensibility is centered on MCP servers (for extending AI agent tool access) and a settings file, not a general-purpose scripting/plugin language like Lua or Python for customizing terminal behavior (e.g., kitty-style 'kittens'). No evidence pack item documents a scripting API, plugin SDK, or embedded language runtime for extending the terminal itself.

   • [claimed-docs] “MCP servers extend Warp’s local agents in a modular, flexible way by exposing custom tools or data sources through a standardized interface …”
   • [claimed-docs] “we are shipping a (long-overdue) settings file so that users and agents get programmatic control over settings and easy portability between …”

   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
   Warp—none0/10

   Warp documents automatic session restoration (windows/tabs/panes reopened on relaunch) but this is a global auto-restore behavior, not a user-authored config/script that defines named per-project startup layouts launchable via one command. No evidence of a project-workspace/layout definition file or CLI flag to open a specific named session.

   • [claimed-docs] “Restore your windows, tabs, panes, and recent Blocks automatically when you relaunch Warp.”
   • [claimed-docs] “Session restoration allows you to quickly pick up where you left off in your previous terminal session.”

   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
   Warp~partialclaimed5/10

   Warp ships documented CLI/IPC surfaces — the standalone Warp Agent CLI (works in any terminal, over SSH, creates its own PTY, can run/control full-screen apps) and the Oz CLI for running/managing cloud agents from scripts or CI with API-key auth — giving real command-line scriptability of agent sessions. However, the evidence is agent-centric (starting conversations, running commands, controlling processes) rather than direct terminal-window primitives like opening/arranging windows or querying pane/window state as the story literally describes (tmux/iTerm2-style control). Missing for 10: explicit documented commands to open/manage Warp windows or panes, send raw text to a specific pane, or query terminal UI state independent of an agent session; independent hands-on confirmation of such scripting.

   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline.”
   • [claimed-docs] “The Oz CLI is the command-line tool for running and managing Warp’s cloud agents from any terminal, script, or CI pipeline. Use it to start …”
   • [claimed-docs] “With the Oz CLI, you can: Run agents locally for development and debugging, Run agents on remote machines, Connect agents to MCP servers lik…”
   • [claimed-docs] “API Keys - Create and manage API keys to authenticate the Oz CLI without human interaction, ideal for CI pipelines, headless servers, and co…”
   • [claimed-docs] “Because it’s a regular command-line program, it works in any terminal emulator, including over SSH.”
   • [claimed-docs] “It creates and maintains its own pseudoterminal (PTY), which lets you and the agent execute commands and interact with running processes thr…”
   • [claimed-docs] “The Warp Agent CLI lets you switch directories while in an agent session, and even run agents on remote machines without installing remote b…”
   • [claimed-docs] “The Warp Agent is now available as a standalone CLI that you can use anywhere – Ghostty, iTerm 2, VS Code, built-in Windows and Mac Terminal…”

   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 drawn
   Warp~partialcommunity4/10

   Only evidence is a community anecdote naming notifications on long-running command completion as a favorite feature; there is no first-party documentation confirming exit status display, command duration tracking, or notification configuration as shell-integration features (the docs pack is dominated by AI/agent capabilities instead). missing for 10: official docs on exit status indicators, duration display, and notification settings; independent corroboration beyond a single forum comment.

   • [community] “My daily driver for a few months now, even after trying Rio/Ghostty/Wezterm... Favorite feature is the notification when a long running comm…”

   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
   Warp—none0/10

   The evidence pack references Warp's 'Blocks' concept (grouping commands and output) and session restoration of blocks, but never documents a shell-integration feature for jumping/navigating between prompt marks or command blocks in scrollback via keyboard shortcuts. Missing for 10: explicit documentation of prompt/command mark navigation shortcuts, scrollback jump-to-previous/next-prompt functionality, and any shell-integration-specific navigation UI.

   • [claimed-docs] “Restore your windows, tabs, panes, and recent Blocks automatically when you relaunch Warp.”
   • [claimed-docs] “Session restoration allows you to quickly pick up where you left off in your previous terminal session.”
   • [claimed-docs] “Sometimes, you may want to prevent a sensitive Block from being saved on your computer, or you may want to clear blocks from a machine entir…”

   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 to Warp
   Warp~partialclaimed5/10

   Warp Drive lets users save workflows and run them 'on-demand' (warp-docs-11, warp-docs-30), and AI Command Suggestions via '#' provide natural-language command discovery (warp-docs-8), which together approximate a command-palette-style workflow, but no evidence explicitly describes a searchable palette UI for discovering and running arbitrary terminal actions. Missing for 10: explicit documentation of a dedicated command palette (e.g., Cmd+P style fuzzy search across commands/workflows), independent/community confirmation of this specific feature, and clarity on scope (built-in commands vs only saved workflows).

   • [claimed-docs] “Warp lets you save your most important workflows in Warp Drive so you can run them on‑demand or share with your team.”
   • [claimed-docs] “Warp lets you save your most important workflows in Warp Drive so you can run them on‑demand or share with your team. Let Warp AI handle the…”
   • [claimed-docs] “Type '#' on your command line and start describing the command you want to run using natural language. Warp will load AI Command Suggestions…”

   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
   Warp—none0/10

   The evidence pack contains no documentation or community mention of clickable URLs/file paths, keyboard-selectable links, or similar output-navigation features in Warp's terminal Blocks. This is a fair ergonomics question for a terminal product but nothing in the pack confirms it ships.

   ⚑ 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
   Warp—none0/10

   The evidence pack covers Warp's AI/agent features, session restoration, theming, and telemetry, but contains no mention of scrollback search or match navigation functionality, despite this being a reasonable and expected axis for any terminal emulator.

   ⚑ 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