Your call
Rate features.
Shape your ranking.
Raw coverage treats every feature the same. Weigh the 54 features by how much they matter to your workflow — three things change:
- Your leaderboard reshuffles. Tools that nail what you actually need rise to the top.
- You discover blind spots. You'll bump into capabilities you didn't know to look for.
- The community signal grows. Aggregated votes surface what the wider field values most.
- #1 Conductor v0.54 57.4%
- #2 Claude Code Desktop v1.8089.1 41.7%
- #3 T3 Code v0.0.24 39.8%
- #4 Vibe Kanban v0.1.44 38%
Main event
4 contenders · 54 rounds
Every feature, every tool, every verdict. Headers stay pinned — scroll vertically through the card, horizontally through the lineup.
- Supported
- Partial
- No
- Unknown
| Feature vs. | Claude Code Desktop 21 3 / 54 paid
closed source
v1.8089.1 · latest reviewed Released
| cmux 1 0 / 54 free
oss
v0.64.9 · preview Released
| Codex App 14 12 / 54 paid
closed source
v26.513.31313 · preview Released
| Conductor 29 4 / 54 free
v0.54 · latest reviewed Released
| Conductor 28 4 / 54 free
v0.52.3 Released
| Cursor 3 17 9 / 54 freemium
v3.4.17 · preview Released
| Docker Agent (cagent) 7 1 / 54 free
oss
v1.59.0 · preview Released
| Factory 5 0 / 54 paid
closed source
v0.128.0 · preview Released
| GenieBuilder 1 0 / 54 closed source
v0.7.2 · preview Released
| GitHub Copilot app 3 0 / 54 paid
vtechnical-preview-2026-05-14 · preview Released
| Google Antigravity 1 0 / 54 freemium
closed source
v2.0.2 · preview Released
| JetBrains Air 2 0 / 54 freemium
v261.584.13 · preview Released
| Multica 3 0 / 54 freemium
oss
v0.3.6 · preview Released
| mux (Coder) 3 0 / 54 free
oss
v0.25.0 · preview Released
| Nimbalyst 6 0 / 54 free
oss
v0.61.1 · preview Released
| OpenDucktor 10 0 / 54 free
oss
v0.3.1 · preview Released
| Switchboard 4 0 / 54 free
oss
v0.0.30 · preview Released
| T3 Code 18 7 / 54 free
oss
v0.0.24 · latest reviewed Released
| Vibe Kanban 17 7 / 54 free
oss
v0.1.44 · latest reviewed Released
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Worth noting | |||||||||||||||||||
| Model wiring how vendor models are plugged in |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Workflow 21 features | 6 1 / 21 | 0 0 / 21 | 4 3 / 21 | 10 0 / 21 | 10 0 / 21 | 4 1 / 21 | 3 1 / 21 | 2 0 / 21 | 0 0 / 21 | 1 0 / 21 | 0 0 / 21 | 0 0 / 21 | 0 0 / 21 | 1 0 / 21 | 2 0 / 21 | 4 0 / 21 | 1 0 / 21 | 5 4 / 21 | 3 2 / 21 |
| Git worktree isolation Each agent works in its own isolated git worktree. | ● Every session in the Code tab automatically runs in its own git worktree under `.claude/worktrees/`; location and branch prefix are configurable in Settings → Claude Code. Proof 1
| ? | ● Codex App ships built-in worktree support so each agent thread can work on an isolated copy of the repo. Proof
| ● Proof 3
| ● Proof 3
| ● Proof
| ○ No worktree concept; the agent runs against the directory passed via --working-dir. Proof
| ? | ? | ? | ? | ? | ? | ? | ● Visual Git management and worktrees supported natively. | ● Each Builder task runs in a dedicated Git worktree to isolate implementation from the main checkout. | ? | ● Proof
| ● Proof
|
| Agent sandbox isolation Whether the orchestrator itself confines agent tool-calls inside a sandbox (container, micro-VM, chroot, macOS sandbox-exec…), independently of git-worktree filesystem separation. Tools that simply delegate sandboxing to the underlying agent CLI count as "no" at the orchestrator layer. The note records the underlying technology when supported. | ○ No orchestrator-managed sandbox: the desktop app launches Claude Code with the host user’s permissions. Any per-tool confinement is whatever Claude Code itself exposes. | ? | ● OS-level sandbox: Seatbelt on macOS, native Windows sandbox under PowerShell (or bwrap under WSL2), bubblewrap on Linux. Proof
| ○ No orchestrator-level sandbox: agents run with the host user’s permissions inside the worktree. Any confinement comes from the underlying agent CLI (Claude Code / Codex). | ○ No orchestrator-level sandbox: agents run with the host user’s permissions inside the worktree. Any confinement comes from the underlying agent CLI (Claude Code / Codex). | ○ No orchestrator-managed sandbox: Background Agents run in Cursor-hosted containers, but the local Agents Window executes tools with host user permissions; no Docker/VM confinement at the orchestrator layer. | ● Tool capabilities can be wired through Docker-based MCP servers, so external tools run inside their own container instead of on the host. Proof
| ● Desktop app grants supervised access to local filesystem, browser, and command line. | ? | ? | ? | ? | ? | ? | ? | ○ The orchestrator delegates execution to local runtimes (OpenCode, Codex) and does not natively wrap tools in a Docker/VM sandbox. | ? | ○ No orchestrator-managed sandbox: threads run agent CLIs with the host user’s permissions inside the worktree. Any confinement is whatever the underlying agent provides. | ○ No orchestrator-managed sandbox: agent CLIs run with the host user’s permissions inside the worktree. Any confinement is whatever the underlying agent provides. |
| Multiple sessions per worktree A single worktree can host multiple independent agent sessions running in parallel, each with its own context, model, and topic — useful to reset context, mix models, or split unrelated subjects without leaving the worktree. | ○ Every new session in the sidebar gets its own isolated worktree; sessions cannot be attached to the same worktree. The side-chat surface (Cmd+;) is a single ephemeral aside that reads the main thread but does not write back. Proof
| ? | ? Threads are organized "by project", with worktree isolation per agent; whether multiple threads can share a single worktree is not documented. Proof
| ● Multiple chat tabs per workspace; switching agents mid-chat opens a new tab. Proof 1
| ● Multiple chat tabs per workspace; switching agents mid-chat opens a new tab. Proof 1
| ? Each agent runs in its own worktree; no documented mechanism to attach multiple independent sessions to a single worktree. | ○ No worktree model; each invocation is its own process. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● `chat.new` opens a new thread while preserving the active worktree state. Proof
| ● Proof
|
| Work without a worktree Run the agent directly inside an existing repository, without creating a git worktree. | ● The session toolbar exposes a "worktree" toggle that can be unchecked to run the session directly against the original checkout without allocating a git worktree. Proof 1
| ? | ? Worktree usage is highlighted as built-in; whether the app can also run directly inside an existing repo without spawning a worktree is not documented. | ○ Every workspace is a worktree; there is no mode that runs against the original checkout. Proof
| ○ Every workspace is a worktree; there is no mode that runs against the original checkout. Proof
| ● Worktrees are opt-in via the /worktree command — agents otherwise run on the current checkout. Proof
| ● Always operates in the current directory (or --working-dir); there is no worktree layer. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Workspace env mode is a toggle between "local" (no worktree, run inside the main repo) and "worktree". Proof
| ○ Worktree creation is a required step for every workspace. Proof
|
| Workflow shell hooks Run arbitrary shell scripts at predefined points of the discussion/worktree lifecycle — e.g. on worktree creation, archival, session start/stop — to bootstrap services, seed data, or clean up resources. | ○ Claude Code hooks (PreToolUse, PostToolUse, Stop, etc.) react to tool/conversation events only. No Desktop-level lifecycle hooks exist (e.g. worktree init), and the UI provides no custom orchestration/workflow hook system. Proof
| ? | ● Hooks went GA on 2026-05-14; lifecycle hooks include PreToolUse and pre/post-compaction, browsable from `/hooks`. Proof
| ● Three lifecycle scripts: setup (on creation), run (on demand), archive (before archival). Proof 1
| ● Three lifecycle scripts: setup (on creation), run (on demand), archive (before archival). Proof 1
| ◐ Worktree setup scripts (setup-worktree-unix / -windows) run on worktree creation. No archival hook documented; plugin hooks cover broader agent events. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ◐ ProjectScript exposes a single lifecycle flag (`runOnWorktreeCreate`); no archival/session-stop hooks documented. Proof
| ◐ Setup script only (runs before the agent starts); no archival/lifecycle hooks documented. Proof
|
| Per-worktree port allocation & env vars Each worktree gets a dedicated pool of free ports, exposed via environment variables to scripts and run configurations, so multiple worktrees can run their own web server / DB / backend in parallel without conflicts. | ◐ `autoPort: true` in `launch.json` allocates a free port and passes it via `PORT`; no general per-worktree port pool. Proof
| ? | ? No documented per-worktree port pool or env-var injection in public docs. | ● CONDUCTOR_PORT exposes the first of 10 ports assigned to the workspace, plus other workspace env vars. Proof 1
| ● CONDUCTOR_PORT exposes the first of 10 ports assigned to the workspace, plus other workspace env vars. Proof 1
| ○ Only $ROOT_WORKTREE_PATH is exposed to setup scripts; no per-worktree port pool or env-var allocation documented. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ Project scripts receive `T3CODE_PROJECT_ROOT` and `T3CODE_WORKTREE_PATH`, but no per-worktree free-port pool is allocated. Proof
| ○ No per-worktree port allocation or env-var pool documented. |
| Session handoff via shared context dir A dedicated gitignored directory (e.g. .context) lets sessions persist artifacts like plans, notes or handoff files that subsequent sessions on the same worktree can reference. | ○ No user-controlled session handoff. Plan mode writes a plan to `~/.claude/plans/` but there is no UI to reference or restore it, and the lack of multi-session support per worktree further limits continuity. | ? | ? Threads persist per project and can resume after pause, but no documented gitignored shared-context directory pattern equivalent to `.context`. | ● Every workspace ships with a .context directory for attachments, plans, and handoff notes. Plans authored in Plan mode can be picked up by later chats via "Hand off" and "Implement plan" actions. Proof 3
| ● Every workspace ships with a .context directory for attachments, plans, and handoff notes. Plans authored in Plan mode can be picked up by later chats via "Hand off" and "Implement plan" actions. Proof 3
| ? No dedicated shared-context directory documented; users typically rely on rules/skills or AGENTS.md. | ◐ Sessions are persisted to a SQLite-style session DB (`--session-db`) accessible through the API server, but no shared context-dir convention is documented for CLI runs. Proof
| ? | ? | ? | ? | ? | ? | ? | ● Integrated task tracking linked to files and session history. | ● Context handoff occurs via task-linked documents (spec, implementation plan, QA reports) stored in the Beads issue tracker metadata instead of a traditional .context folder. | ? | ◐ Plan mode produces a proposed plan that the user can save to the workspace root as markdown via PlanSidebar (copy / download / save-to-workspace); no dedicated gitignored handoff directory (e.g. `.context`). Proof
| ○ No shared-context dir; sessions explicitly do not inherit conversation history. Proof
|
| Remote ADE control Remote control of the Agent Development Environment as a product surface — e.g. open the ADE from a phone, inspect sessions, send prompts, approve actions, or manage runs. Remote-control features provided solely by an embedded coding agent do not count unless the ADE exposes and owns the remote control surface. | ○ The feature assessed here is the ability to control an ADE (Agent Development Environment) remotely, not the ability to use a coding assistant from a remote device. Claude Code Desktop offers no mechanism to control it remotely as an ADE. | ? | ● Since 2026-05-14 the ChatGPT mobile app can connect to a Mac running the Codex app to drive sessions remotely; `codex remote-control` exposes a headless app-server. Proof
| ○ No mobile / remote-access surface documented; Conductor is a local macOS app. | ○ No mobile / remote-access surface documented; Conductor is a local macOS app. | ● Cursor exposes its Cloud Agent ADE surface from web, iOS PWA, Slack, GitHub, Linear, and API, so sessions can be started and managed remotely. Proof
| ○ `cagent api` exposes the agent runtime over HTTP, but this row requires remote control of an ADE product surface itself; no first-party remote ADE client is shipped. Proof
| ● Works across Web, Slack/Teams, Linear/Jira and Mobile. | ? | ? | ? | ? | ? | ● Mobile responsive UI via server mode. | ? | ? | ? | ● Pair from a phone/tablet via QR code, pairing token, or hosted web app at app.t3.codes. Proof
| ● Proof
|
| Switch model mid-session Pick a different model in the middle of a running discussion. Cross-vendor switches that require spinning up a new session (ideally seeded with a summary of the previous one to preserve continuity) still count as supported — vendor SDKs are usually too different for an in-place swap. | ● Model dropdown next to the send button (Cmd+Shift+I) swaps the Anthropic model mid-session; the selection persists. Proof 1
| ? | ? Multiple OpenAI models (GPT-5.5, GPT-5.4 with reasoning levels) are available; mid-session model switching in the app UI is not documented. Vendor lock means a same-vendor swap should be feasible without a new session. | ● Switching the agent mid-chat opens a new chat tab seeded with a summary of the previous one, allowing seamless continuation with a different model. Proof 1
| ● Switching the agent mid-chat opens a new chat tab seeded with a summary of the previous one, allowing seamless continuation with a different model. Proof 1
| ? Each tab carries its own model selection; documentation does not explicitly confirm mid-conversation switch on the same tab. | ○ The model is pinned in the agent YAML config; switching requires editing the file and re-running. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Proof
| ◐ Agent dropdown is set per session before sending a message; TUI /model command is unsupported. Cross-vendor switches effectively spin up a new session. Proof
|
| Repo-less quick chat A lightweight, repo-less chat surface for ad-hoc questions to a model — useful for one-off prompts, brainstorming, or scripting tasks that should not pollute a worktree session. | ● The Desktop app ships two repo-less tabs alongside Code: Chat (standard Claude conversations) and Cowork (Dispatch-style agentic work), both detached from any worktree. Proof 1
| ? | ? All Codex App threads are anchored to a project; a repo-less chat surface is not documented. | ○ Chats live inside a workspace, which requires a repository. Proof
| ○ Chats live inside a workspace, which requires a repository. Proof
| ? Agents Window is workspace-scoped; community has open feature requests for empty / repo-less chats. Proof
| ● A one-shot prompt can be piped to any agent file without attaching the session to a repository. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ `chat.newLocal` still attaches the thread to the active project; no repo-less chat surface documented. Proof
| ○ Chat lives inside the conversation panel of a workspace, which requires a project / repository. Proof
|
| Copy files from origin workspace Bring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. | ● `.worktreeinclude` (gitignore-syntax) copies untracked files like `.env` or `secrets.json` into each new worktree. Proof
| ? | ? Worktree behaviour for untracked files like `.env` is not documented in public sources. | ● Glob-based "Files to copy" feature; defaults to `.env*` and can be shared via `.worktreeinclude`. Proof 1
| ● Glob-based "Files to copy" feature; defaults to `.env*` and can be shared via `.worktreeinclude`. Proof 1
| ● Worktree setup script exposes $ROOT_WORKTREE_PATH to copy files from the main checkout (typically .env). Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ◐ No first-class glob-based "files to copy" UI, but a project script flagged `runOnWorktreeCreate: true` can use the documented `T3CODE_PROJECT_ROOT` env var to `cp` files (e.g. `.env`) from the origin checkout into the new worktree. Proof
| ○ No mechanism documented; uncommitted files in the origin repo are flagged as a failure cause for worktree creation. Proof
|
| Symlink files from origin workspace Expose files from the source repo inside the agent worktree via symlinks (ln -s). | ○ `.worktreeinclude` copies files; no first-class symlink mechanism is documented (could be scripted via a `WorktreeCreate` hook). Proof
| ? | ? No documented symlink-from-origin mechanism. | ● No first-class UI, but documented as a setup-script pattern using `ln -sf "$CONDUCTOR_ROOT_PATH/…"`. Proof 1
| ● No first-class UI, but documented as a setup-script pattern using `ln -sf "$CONDUCTOR_ROOT_PATH/…"`. Proof 1
| ○ Explicitly discouraged by Cursor. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ◐ Same `runOnWorktreeCreate` setup-script pattern with `T3CODE_PROJECT_ROOT` lets the user `ln -sf` files into a new worktree, but no first-class symlink declaration is documented. Proof
| ○ No symlink / shared-file mechanism documented. Proof
|
| Read-only plan/research mode A discussion mode where the agent can inspect and reason over the codebase without editing it, typically using a stronger thinking model to prepare context, architecture notes, and an implementation plan that can then be handed off to a cheaper implementation model without advanced thinking. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Specifier and Planner roles are explicitly read-only and automatically reject mutating permissions. | ? | ? | ? |
| Predefined deterministic workflows Launch a discussion that walks through a fixed deterministic sequence of phases, picked from a catalog of built-in workflows — e.g. research → plan → implement → review, idea-to-PR, bug-repro-and-fix, debugging-session — each with phase-specific prompts, models or tool permissions, instead of a free-form single-turn loop. | ○ No built-in research/plan/implement/review phased workflow; Plan Mode is a single toggle, not a multi-phase pipeline. | ? | ◐ Persisted `/goal` workflows (2026-04-30) cover create / pause / resume / clear across app-server APIs; predefined research→plan→implement catalog is not documented. Proof
| ○ Chats are free-form within a workspace; no built-in research/plan/implement/review phased workflow documented. | ○ Chats are free-form within a workspace; no built-in research/plan/implement/review phased workflow documented. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Follows a strict Specifier -> Planner -> Builder -> QA loop based on task transitions. | ? | ○ No built-in phased workflow (research/plan/implement/review) documented for chat threads. | ○ Chat sessions are free-form; no built-in research/plan/implement/review phased workflow documented. |
| Custom deterministic workflows Define your own deterministic discussion workflows — ordered phases, per-step prompts, gating conditions, model/tool overrides — to make agent sessions repeatable across runs. | ○ Claude Code Desktop offers no mechanism to define or customize discussion workflows. This is a CLI-level feature and is not surfaced in the Desktop UI. | ? | ◐ Skills + `/goal` workflows let users author reusable multi-step flows; no fully deterministic ordered-phases workflow definition is documented. Proof
| ○ No user-authored multi-step discussion workflow mechanism documented. | ○ No user-authored multi-step discussion workflow mechanism documented. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ Project scripts and provider skills exist, but no multi-step discussion-workflow definition documented. | ○ Slash commands surface single prompts but no multi-step discussion-workflow authoring is documented. |
| Fork workspace to a new worktree Fork the entire state of a workspace — git worktree contents, session/chat history, and any local-only files — into a brand-new worktree, so you can branch off an alternative exploration without disturbing the original session. | ● The "Fork from here" button on hover over any past message creates a new session and worktree from that point. The chat history is preserved but all local and committed changes since the origin worktree's starting commit are reset in the new worktree. Proof 2 | ? | ◐ TUI resume/fork picker can fork a conversation; cloning the full workspace state (worktree + history) into a brand-new worktree from the app UI is not documented. Proof
| ● Per-chat "Fork to new workspace" action clones the current workspace (worktree state + session history) into a new worktree, letting you branch off an alternative exploration. Proof 1 | ● Per-chat "Fork to new workspace" action clones the current workspace (worktree state + session history) into a new worktree, letting you branch off an alternative exploration. Proof 1 | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Launch, resume, fork, and monitor sessions. | ○ No "fork workspace" action found in the contracts or web app — neither `forkThread` nor a worktree-cloning command exists, and the keybinding catalog exposes only `chat.new` / `chat.newLocal`. | ○ No documented "fork workspace" action; new workspaces are created from the source repo, not by cloning an existing workspace. Proof
|
| Unarchive a worktree After a worktree has been archived — manually or automatically (e.g. on PR merge) — the orchestrator exposes an action to bring it back as an active workspace, preserving its session/chat history and git state. "Partial" when only the metadata is restored (no underlying worktree/state), "yes" when the restored workspace is fully resumable. | ○ Archive (manual or auto on PR merge/close) is documented as the way to "remove a worktree when you're done"; no inverse unarchive/restore action is documented. Proof
| ? | ? | ● Since v0.50.0, an explicit Unarchive action restores an auto-archived workspace (typically archived after PR merge) back to the active list with its worktree and session history intact. Proof 1
| ● Since v0.50.0, an explicit Unarchive action restores an auto-archived workspace (typically archived after PR merge) back to the active list with its worktree and session history intact. Proof 1
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Local merge to target branch Merge the current work locally into the configured target branch directly from the ADE. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| LLM-assisted merge/rebase Merge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Agent Merge addresses review comments, fixes failing checks, and merges. | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Multi-repository view Show multiple repositories at once and filter the UI to focus on selected repositories. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Multi-repository chat targeting Target several repositories, such as frontend and backend, within one discussion. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| User experience 20 features | 8 0 / 20 | 0 0 / 20 | 6 3 / 20 | 12 2 / 20 | 11 2 / 20 | 4 6 / 20 | 0 0 / 20 | 1 0 / 20 | 0 0 / 20 | 0 0 / 20 | 0 0 / 20 | 0 0 / 20 | 0 0 / 20 | 0 0 / 20 | 2 0 / 20 | 3 0 / 20 | 3 0 / 20 | 6 2 / 20 | 7 3 / 20 |
| Visual task management (e.g. kanban board) Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. | ○ Sidebar lists sessions and supports filtering by status / project / environment plus grouping by project, but it stays a vertical list — no kanban-style board surface in the Code tab. Proof
| ? | ○ Threads are organized by project in a sidebar/list, not as a board-style visual surface. Proof
| ● Kanban-style Dashboard view available behind an experimental flag (Settings → Experimental → Dashboard). Statuses are hardcoded (Backlog / In progress / In review / Done / Canceled), no customization. Proof 2
| ● Kanban-style Dashboard view available behind an experimental flag (Settings → Experimental → Dashboard). Statuses are hardcoded (Backlog / In progress / In review / Done / Canceled), no customization. Proof 2
| ○ No board-style visual task surface in the Agents Window — agents are listed in a sidebar / grid view. | ○ CLI / TUI tool; no board-style visual surface. | ? | ? | ? | ? | ? | ? | ? | ● Kanban board for parallel session management. | ● Task-first workflow with a Kanban board as the main operational view. | ● Launch, resume, fork, and monitor sessions; no juggling terminal tabs. | ○ No board-style visual surface; threads are surfaced through a sidebar/workspace list. | ● Proof
|
| In-app diff viewer Built-in UI to display agent-produced code changes directly in-app (file-by-file). | ● Desktop app diff viewer shows changes file by file before creating a pull request. Proof 1
| ? | ● In-thread diff view lets the user review the agent changes and comment before committing. Proof
| ● Built-in Diff Viewer renders agent-produced changes file by file, with inline comment and PR actions. Proof 1
| ● Built-in Diff Viewer renders agent-produced changes file by file, with inline comment and PR actions. Proof 1
| ● Proof
| ○ No built-in diff UI; file edits land directly on disk subject to tool-call approval prompts. | ? | ? | ? | ? | ? | ? | ? | ● Red/green inline diffs with block-level approval. | ● Built-in tools to inspect diffs and track Git state for the worktree. | ● Shows file diffs and opens in a side panel (IDE Emulation). | ● Proof
| ● Proof
|
| Diff: ignore-whitespace toggle Toggle to hide or show whitespace-only changes in the diff viewer. | ○ No ignore-whitespace toggle documented in the diff viewer. | ? | ? No ignore-whitespace toggle explicitly documented in the in-thread diff view. | ● Conductor 0.54 adds an ignore-whitespace toggle to the Diff Viewer so whitespace-only changes can be hidden or shown. Proof 1
| ○ Ignore-whitespace toggle was not supported before Conductor 0.54. Proof
| ? No ignore-whitespace toggle explicitly documented in the diffs view or PR review surface. | ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Pilcrow toggle in the DiffPanel shows/hides whitespace-only changes. Proof
| ● Ignore Whitespace toggle in the file tree hides whitespace-only changes. Proof
|
| Diff: multiple scopes / views Beyond a single static diff, the orchestrator offers multiple selectable diff scopes — e.g. changes from a single commit, currently uncommitted changes, or the cumulative diff against the target branch. "Partial" when only one alternative scope is available, "yes" when several are. Per-turn diffs surfaced inside the chat are tracked separately by the `chat-turn-diff` row. | ○ Desktop diff viewer renders the current pending changes file by file before the PR is opened; no documented selector to switch between per-commit / per-turn / branch-vs-target scopes. Proof
| ? | ? Diff covers PR reviewing and viewing multiple files; no documented selector to switch between per-commit / per-turn / branch-vs-target scopes. | ● Diff Viewer offers several selectable scopes: branch vs. target, uncommitted changes, per-commit, and per-turn (changes produced by a single agent discussion). Proof 4
| ● Diff Viewer offers several selectable scopes: branch vs. target, uncommitted changes, per-commit, and per-turn (changes produced by a single agent discussion). Proof 4
| ◐ PR review surface adds a "Changes" tab on top of the in-app diffs view (current pending changes vs. PR-scope changes). No documented per-commit / per-turn selector beyond that. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ◐ DiffPanel exposes two scopes: the whole-thread cumulative diff (selectWholeConversation) and a per-turn diff selected via the turn strip; no per-commit or branch-vs-target selectors found. Proof
| ? Changes panel is workspace-scoped (current pending changes); no documented selector for per-commit / per-turn / branch-vs-target scopes. |
| Per-turn diff in chat From within the chat, each LLM turn exposes the diff it produced — typically as a footer listing the files it touched, or a click-through to a per-turn scope of the diff viewer. This lets the user review what a given turn changed without manually committing after each turn just to delimit the diff. Distinct from `diff-multi-views`, which tracks whether the diff viewer itself offers several scopes to pick from. | ○ A single session-wide diff stats indicator (e.g. `+12 -1`) opens the global diff viewer; no per-turn file list or per-turn diff scope exposed inside the chat transcript. Proof
| ? | ? | ● Each agent turn exposes a footer listing the files it changed; clicking a file jumps straight to its diff scoped to that turn — no manual commit needed to delimit the per-turn diff. Proof 1
| ● Each agent turn exposes a footer listing the files it changed; clicking a file jumps straight to its diff scoped to that turn — no manual commit needed to delimit the per-turn diff. Proof 1
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Configurable sound notifications Configure sound alerts for key agent events (idle, awaiting input, task done…). | ○ Desktop fires a system OS notification when a session finishes and the user isn’t viewing it, but exposes no configurable sound-effect picker. The `Notification` hook event can be wired to a shell hook to play a sound, but that is not a first-class setting. Proof
| ? | ? No mention of configurable sound alerts in public docs; OS-level notifications exist (e.g. action-required terminal titles in the CLI). | ● Multiple themed completion sounds (SNCF jingle, Paris Métro chime, SF Muni, NYC MTA…) selectable from General settings with a Test button. Proof 1
| ● Multiple themed completion sounds (SNCF jingle, Paris Métro chime, SF Muni, NYC MTA…) selectable from General settings with a Test button. Proof 1
| ◐ Sound played when an agent finishes; configuration is binary (on/off), not per-event. Custom audio achievable via plugin hooks. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No audio/sound notification system found in the codebase or docs. | ● Proof
|
| Run configurations Define and launch shell commands ("run configurations") directly from the UI. | ○ Only web preview is supported through .claude/launch.json, but specific configurations cannot be triggered directly from the UI Proof
| ? | ● Each thread can launch "repeatable project actions" and run commands directly from the UI. Proof
| ◐ A single run script per repo, launched from the Run button (concurrent or nonconcurrent mode). Proof 3
| ◐ A single run script per repo, launched from the Run button (concurrent or nonconcurrent mode). Proof 3
| ○ No user-defined "run configuration" UI; the worktree setup script is a single hook, not a launchable command catalogue. | ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Project scripts are user-defined shell commands launched from the UI (ProjectScriptsControl) and bindable to keybindings via `script.{id}.run`. Proof
| ◐ Three predefined scripts (Dev Server, Setup, Cleanup); dev server toggleable from the UI, but no user-defined arbitrary run configurations. Proof
|
| Comments on diff panel Leave comments on the diff and reference them back in the LLM discussion. | ● Click any line in the desktop diff to add a comment; Claude reads the comments and revises. Proof 2
| ? | ● Users can comment on the diff inside the thread; comments are surfaced back to the agent. Proof
| ● Comments on changed lines are sent back to the agent as precise context. Proof 2
| ● Comments on changed lines are sent back to the agent as precise context. Proof 2
| ◐ Inline comments exist on the PR Review surface (synced with GitHub). The local diffs view itself does not document standalone in-app diff comments. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No comment/annotation surface on the diff panel found in the codebase. | ● Inline comments collected and sent to the agent in the next message. Proof
|
| Terminal in worktree Open one or several terminal windows rooted in the current worktree. | ● Desktop app has an integrated terminal pane rooted in the session's working directory. Proof 1
| ? | ● Multiple terminal tabs per thread, rooted in the thread workspace. Proof
| ● Multiple terminal windows can be opened simultaneously on the same worktree (Terminal 1, Terminal 2, ...). Proof 2
| ● Multiple terminal windows can be opened simultaneously on the same worktree (Terminal 1, Terminal 2, ...). Proof 2
| ● Proof
| ○ cagent is itself a terminal tool — no embedded shell pane in a worktree because there is no worktree UI. | ● Supervised command line access. | ? | ? | ? | ? | ? | ? | ? | ? | ● Built-in Terminal to connect to running sessions or launch new ones. | ● Built-in terminal drawer with split, new, toggle and close commands; default `mod+j` binding. Proof
| ● Proof
|
| File tree browser Browse the worktree file tree from within the app. | ● The Files panel exposes a full project file-tree browser that lets you navigate and open any file in the project. Proof 1
| ? | ● Sidebar exposes the project files with rich previews (PDF, spreadsheets, documents) since the April 2026 update. Proof
| ● Built-in file tree pane in the workspace; click a file to open it in the built-in editor, drag folders onto the Composer to attach. Proof 1
| ● Built-in file tree pane in the workspace; click a file to open it in the built-in editor, drag folders onto the Composer to attach. Proof 1
| ◐ Editor Window exposes a full file tree. The Agents Window itself does not (community feature-request open). PR Changes tab has a changed-files tree. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ Only the diff-scoped ChangedFilesTree was found; no general worktree file browser component identified in the web app. | ◐ Changed-files tree inside the diff panel; no full worktree browser documented. Proof
|
| Inline file editing Edit and save files directly from the in-app file browser. | ● Desktop file pane supports spot edits with Save, with stale-file detection. Proof 1
| ? | ? Files can be opened with rich previews from the sidebar; user-driven inline editing/save is not explicitly documented. | ● Built-in file editor with full syntax highlighting and ⌘F. Proof 1
| ● Built-in file editor with full syntax highlighting and ⌘F. Proof 1
| ● Cursor is a full code editor — files can be edited and saved directly. Proof
| ○ Agents can edit files via the filesystem toolset, but there is no in-app editor surface. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No in-app file editor surface; the only documented client-side use of the `writeFile` RPC is saving a Plan markdown to the workspace root. For actual edits, the user is sent to an external IDE. Proof
| ○ Files are reviewed and commented on; no in-app editor documented. Open-in-IDE is the documented path to edit. |
| Custom UI actions (prompts or commands) Define custom actions surfaced in the UI — each action being a shell command (git push, git push --force-with-lease, rebase on target branch…) or a parameterized LLM prompt (resolve conflicts during rebase, open a PR on GitHub, run a review prompt…). A single editable run script alone does NOT qualify as "partial": at minimum the user must be able to declare multiple custom actions (multiple shell commands, or a mix of shell + LLM-prompt actions). | ○ There is no mechanism to add custom buttons to the Claude Code Desktop UI that would execute shell commands or prompts. Skills and slash commands are invocable from the prompt box but are not surfaced as UI buttons. | ? | ◐ Skills bundle reusable instructions and scripts; slash commands and "repeatable project actions" surface custom flows. No fully user-defined UI button system is documented for the app. Proof
| ○ Only built-in Run button bound to the run script; no user-defined UI buttons and no parameterized LLM-prompt actions. | ○ Only built-in Run button bound to the run script; no user-defined UI buttons and no parameterized LLM-prompt actions. | ◐ Slash commands surface user-defined LLM prompts (.cursor/commands/*.md). No documented button surface running shell commands. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ◐ User-defined project scripts (shell commands) can be surfaced and bound to keybindings; no parameterized custom LLM prompt buttons documented. Proof
| ◐ Slash commands surface LLM prompts in the chat; no user-defined shell-command buttons. Proof
|
| Embedded web preview In-app web preview pane that renders the output of a local HTTP server. "Partial" covers an external-browser launch or a pane that merely displays the preview. A "yes" requires an embedded preview integrated with the ADE workflow. Annotation and element inspection are tracked as separate feature rows. | ● Desktop preview pane embeds a browser bound to `launch.json` dev servers; Claude can drive it (start dev server, hit API endpoints), read server logs, and act on the preview. Proof 1
| ? | ● In-app browser added in April 2026 lets Codex operate local dev servers and navigate rendered pages — i.e. the orchestrator can both display and act on the preview. Proof
| ◐ When a port is detected during a run, Conductor exposes an "Open in Browser" action that launches the preview in the user’s default browser. The preview is not embedded in-app and is not controllable by the orchestrator (no integrated visual debug surface). Proof 1 | ◐ When a port is detected during a run, Conductor exposes an "Open in Browser" action that launches the preview in the user’s default browser. The preview is not embedded in-app and is not controllable by the orchestrator (no integrated visual debug surface). Proof 1 | ● Integrated browser with Design Mode lets the orchestrator drive a local web app (clicks, navigation) and "see" the rendered page (screenshots, accessibility audits) — full criterion met. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No embedded web preview / iframe browser component found. | ● Built-in preview browser tied to the dev server script configured per repository. Proof
|
| Web preview annotation Annotate regions of the embedded web preview and feed that visual feedback back into the discussion. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Web preview element inspector Inspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Activity history dashboard A dedicated dashboard surfacing the historical activity of the orchestrator across all worktrees / projects: past discussions, completed or archived tasks, prior agent runs, audit-style timeline. Complementary to the live visual-task-management board, which focuses on what is currently in flight. | ○ Sidebar in the Code tab aggregates live sessions across projects (filter/group controls included), but it focuses on what is currently in flight; no dedicated historical/audit timeline of past or archived activity. Proof
| ? | ◐ Codex App is positioned as a "command center" managing many parallel agents and threads across projects from a single window. Live-oriented; no dedicated historical/audit timeline of past archived activity documented. Proof
| ○ No dedicated activity history surface aggregating past runs / archived workspaces across the orchestrator. Only the live sidebar grouping (and the experimental Dashboard) plus a "next session needing attention" jump. | ○ No dedicated activity history surface aggregating past runs / archived workspaces across the orchestrator. Only the live sidebar grouping (and the experimental Dashboard) plus a "next session needing attention" jump. | ◐ Agents Window sidebar aggregates local + cloud + remote SSH agents across repos. Live-oriented; no dedicated historical/audit timeline of past archived activity documented. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ Sidebar groups live threads per workspace; no dedicated dashboard surfacing historical activity (past runs, archived threads) across the whole orchestrator was found in the web app. | ○ Live workspace sidebar groups Needs Attention / Idle / Running across workspaces, but no dedicated historical/audit timeline of past activity is documented. Proof
|
| Inline user-question tools in chat Modern coding agents expose tools to ask the user a clarifying question (e.g. `AskUserQuestion`). "Yes" means the orchestrator detects these tool calls and renders them inline in the chat as a dedicated interactive surface — radio buttons, multi-choice, free-text prompt — instead of leaving them as raw markdown that the user has to answer manually. | ● The `AskUserQuestion` tool call is rendered inline in the Desktop chat as a structured dialog with multiple-choice options and a free-text fallback. Proof 1 | ? | ? Codex agents can pause for clarification, but no documented inline interactive rendering of user-question tools in the app chat surface. | ● Conductor renders Claude's AskUserQuestion tool calls as an interactive, keyboard-navigable UI inline in chat; supports multi-select questions. Proof 1
| ● Conductor renders Claude's AskUserQuestion tool calls as an interactive, keyboard-navigable UI inline in chat; supports multi-select questions. Proof 1
| ? No documented inline rendering of agent user-question tools (AskUserQuestion-style) in the Cursor chat surface. | ○ TUI-only CLI; no chat surface to render inline user-question tools. | ? | ? | ? | ? | ? | ? | ? | ? | ● The system intercepts MCP pending permissions and pending questions to expose them to the user. | ? | ● ClaudeAdapter detects `AskUserQuestion` tool calls and emits a `user-input.requested` runtime event; the composer renders a dedicated ComposerPendingUserInputPanel with keyboard-shortcut option selection and multi-select support. Proof
| ? No documented inline rendering of agent user-question tools (AskUserQuestion-style) in the Vibe Kanban chat surface. |
| Rewind chat to a past message Navigate back to any past message in a discussion and resume from there — truncating or branching the conversation history. An advanced variant also rolls back the workspace filesystem state to match the message, so the agent restarts from the exact code context it had at that point. | ● Claude Code Desktop offers a "Rewind to here" button on hover over any past message, allowing the user to restore the conversation and/or file edits to that checkpoint directly from the UI. Proof 1 | ? | ◐ Resume/fork picker (introduced 2026-05-07) rewinds and forks conversation history; this is documented for the TUI — equivalent app surface not explicitly described. Proof
| ● Reset-to-this-point action on any past user message: deletes subsequent chat AND rolls back the workspace git state via a per-response checkpoint (cannot be undone). Proof 2 | ● Reset-to-this-point action on any past user message: deletes subsequent chat AND rolls back the workspace git state via a per-response checkpoint (cannot be undone). Proof 2 | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Per-turn "Revert to checkpoint" action (dispatching `thread.checkpoint.revert`) rolls back both newer messages AND turn diffs in the worktree; warns the action cannot be undone. Proof
| ? No rewind-to-past-message feature documented in the chat interface. |
| In-app voice input Dictate prompts or chat messages directly inside the ADE. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Chat message stacking Queue several user messages in the chat so they are sent or applied as a stacked sequence. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? |
| Integrations 6 features | 4 1 / 6 | 1 0 / 6 | 1 4 / 6 | 4 2 / 6 | 4 2 / 6 | 4 2 / 6 | 1 0 / 6 | 1 0 / 6 | 1 0 / 6 | 2 0 / 6 | 1 0 / 6 | 1 0 / 6 | 1 0 / 6 | 1 0 / 6 | 1 0 / 6 | 2 0 / 6 | 0 0 / 6 | 4 1 / 6 | 4 2 / 6 |
| Multiple model families (multi-vendor) A "yes" requires the orchestrator to drive models from several distinct vendors (Anthropic + OpenAI + Google + …). Supporting only multiple Anthropic models (Opus / Sonnet / Haiku) — or only multiple OpenAI models — counts as "no" because it locks the user into a single vendor. Two vendors is treated as "partial" since the surface remains thin compared to broadly multi-vendor orchestrators. | ○ Claude-only support (Opus/Sonnet/Haiku). Multiple gateways possible (Anthropic API, Bedrock, Vertex AI, Foundry) but still a single vendor. Unofficial env-var hacks exist for non-Anthropic models, but OpenAI/Google/xAI support is not officially supported. Proof
| ● Supports Claude Code, Codex, Grok, OpenCode, Pi, Amp, Cursor CLI, Gemini, Copilot, etc. | ○ Single vendor: OpenAI models only (GPT-5.5 default, GPT-5.4 with reasoning levels). No third-party model families; ChatGPT login required. Proof
| ◐ Two vendors supported: Anthropic (Claude Code family) and OpenAI (Codex family). Lighter than orchestrators that wire many vendors (Google, xAI, Moonshot…), hence "partial" rather than "yes". Proof 1
| ◐ Two vendors supported: Anthropic (Claude Code family) and OpenAI (Codex family). Lighter than orchestrators that wire many vendors (Google, xAI, Moonshot…), hence "partial" rather than "yes". Proof 1
| ● Six vendor families: Anthropic (Claude Opus/Sonnet/Haiku), OpenAI (GPT-5.x), Google (Gemini 2.5/3), Cursor (Composer 1/2), xAI (Grok), Moonshot (Kimi). Proof
| ● BYOK across multiple vendors: OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, xAI, Docker Model Runner, and more — direct provider SDKs. Proof
| ● Factory Droid Core plus BYOK (Anthropic, OpenAI, Google). | ● Supports OpenAI, Anthropic, Google Gemini, Ollama, LM Studio, llama.cpp, Claude Code, Kimi CLI, Codex, Copilot CLI. | ○ Uses GitHub Copilot agent exclusively. | ● Supports Gemini, Anthropic (Claude), and OpenAI models. | ● Supports Claude Agent, Codex, Gemini CLI, and Junie (JetBrains). | ● Works with Claude Code, Codex, GitHub Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, and Kiro CLI. | ● Anthropic, OpenAI, xAI, Ollama, OpenRouter. | ● Supports Claude Code, Codex, Opencode, and Copilot. | ● Supports OpenCode and Codex runtimes out of the box. | ○ Exclusively a front-end for Claude Code CLI sessions. | ● Anthropic (Claude Code), OpenAI (Codex), plus OpenCode and Cursor agents — bring your own subscription, drives multiple vendor families. Proof
| ● 10+ coding agents from multiple vendor families: Anthropic (Claude Code), OpenAI (Codex), Google (Gemini), GitHub (Copilot), Cursor, Sourcegraph (Amp), Alibaba (Qwen Code), and more. Proof
|
| Automatic PR creation The agent opens a GitHub/GitLab PR when a task completes. | ● Creates the PR via the /create-pr embedded command, which is going to ask you if you want to create a draft/ready-to-review PR. Proof 3
| ? | ● Built-in review pane stages files, commits and pushes; PR creation and PR-feedback addressing are first-class. Proof
| ● Dedicated button (and Cmd+Shift+P shortcut) creates the PR in one click, with an option to open it as a Draft. The prompt used to draft the PR description is customizable in project preferences (e.g. to enforce a specific language or formalism). Proof 2
| ● Dedicated button (and Cmd+Shift+P shortcut) creates the PR in one click, with an option to open it as a Draft. The prompt used to draft the PR description is customizable in project preferences (e.g. to enforce a specific language or formalism). Proof 2
| ● Proof
| ○ No built-in GitHub/GitLab PR action; an agent could shell out to `gh`, but nothing is shipped. | ? | ? | ● Agent Merge addresses review comments, fixes failing checks, and merges. | ? | ? | ? | ? | ? | ● The approval flow includes a dedicated Builder session to generate the pull request (build_pull_request_generation). | ? | ● Proof
| ● Proof
|
| One-way GitHub comment sync (PR → in-app) GitHub PR review comments are pulled into the orchestrator’s in-app changes panel so the user (and the agent) can read and react to them without leaving the app. This is intentionally a one-way flow — the reverse direction (pushing in-app comments back to GitHub) is out of scope of this row. | ● GitHub PR review comments are synced and displayed inline in the Desktop diff viewer alongside the code changes. Proof 1 | ? | ◐ Codex surfaces and addresses GitHub PR review comments from inside the app (one-way ingestion). No explicit documentation of a polished in-thread comment surface fed by GitHub, so kept partial. Proof
| ● One-way: GitHub review comments are surfaced in Conductor and resolving them updates the Checks tab. Proof 1
| ● One-way: GitHub review comments are surfaced in Conductor and resolving them updates the Checks tab. Proof 1
| ● PR Review experience reads GitHub review threads inside Cursor (one-way ingestion fully covered; bidirectional sync also documented but not required by this row). Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ Source-control docs cover PR creation and listing, not comment sync. Proof
| ◐ One-way: GitHub PR comments are surfaced inside the Changes panel; in-app comments are sent to the agent, not pushed to GitHub. Proof
|
| Open in IDE / external app Launch the current worktree in an IDE / editor / app. Covers which apps ship built-in (VS Code, JetBrains, Cursor…) and whether custom apps can be configured by the user. | ◐ Right-click "Open in" on a file path and the "Continue in" menu on the toolbar both open a fixed list of installed editors (VS Code, Cursor, Zed…); no user-defined custom external apps. Proof 1
| ? | ◐ Codex IDE Extension syncs context with the app (Auto Context); no documented "Open in <editor>" picker for arbitrary external apps. Proof
| ◐ Fixed built-in app list (Finder, VS Code, Zed, Windsurf, Sublime Text, Android Studio, Xcode, Ghostty, iTerm, Hyper, Terminal, GitHub Desktop, Sourcetree, DataGrip). No user-defined custom apps. Proof 1
| ◐ Fixed built-in app list (Finder, VS Code, Zed, Windsurf, Sublime Text, Android Studio, Xcode, Ghostty, iTerm, Hyper, Terminal, GitHub Desktop, Sourcetree, DataGrip). No user-defined custom apps. Proof 1
| ◐ Cursor IS the IDE; Cmd+Shift+P → "Open Editor Window" switches from Agents Window to the full editor. No "open in external app" picker documented. Proof
| ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● VS Code (+ Insiders, VSCodium), Cursor, Zed, Antigravity, Trae, Kiro, plus 12 JetBrains IDEs and the platform file manager; no user-defined custom apps. Proof
| ● VS Code, Cursor, Windsurf, Zed, Antigravity, Neovim, Emacs, Sublime Text, plus custom editor command. Proof
|
| GitHub PR status sync & auto-close Track linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. | ● Desktop CI status bar tracks PR checks; auto-archive setting closes the session when the PR merges or closes. Proof 2
| ? | ◐ App reviews PRs and addresses feedback inline; no documented auto-archive of the thread/worktree when the PR merges. Proof
| ● Checks and merge state tracked in-app; manual merge from the workspace; "Archive on merge" + "Delete branch on archive" toggles auto-archive on in-app and external merges (Unarchive action since v0.50.0). Proof 4
| ● Checks and merge state tracked in-app; manual merge from the workspace; "Archive on merge" + "Delete branch on archive" toggles auto-archive on in-app and external merges (Unarchive action since v0.50.0). Proof 4
| ◐ PR Review surfaces PR state and allows merge from inside Cursor; no documented auto-archival of the worktree on merge. Proof
| ○ | ? | ? | ● Agent Merge addresses review comments. | ? | ? | ? | ? | ? | ? | ? | ◐ T3 Code detects whether an open PR/MR exists for the current branch; no auto-archive on merge documented. Proof
| ◐ PR-status badge on the workspace sidebar; no auto-archive on merge documented (archive is manual). Proof
|
| Reasoning effort control Tune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). | ● Effort menu reachable via Cmd+Shift+E lets the user pick adaptive reasoning levels (`low`, `medium`, `high`, `xhigh`, `max`). Proof 1
| ? | ◐ GPT-5.4 exposes reasoning levels (fixed in the 2026-04-30 release); the app UI for tuning effort mid-task is not explicitly documented. Proof
| ● Fast Mode + reasoning-effort levels exposed when the model supports it. Proof 1
| ● Fast Mode + reasoning-effort levels exposed when the model supports it. Proof 1
| ● Reasoning effort variants exposed for OpenAI models (e.g. gpt-5-high, gpt-5.2-high) and Max Mode for Anthropic / Gemini. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● TraitsPicker surfaces per-provider effort/thinking/fast-mode/context-window controls (with Claude ultrathink prompt prefix support) in the chat composer. Proof
| ● reasoning_effort exposed for Codex (low/medium/high) and Droid (off/low/medium/high) agent configurations. Proof
|
| Observability 2 features | 2 0 / 2 | 0 0 / 2 | 1 0 / 2 | 2 0 / 2 | 2 0 / 2 | 2 0 / 2 | 1 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 2 0 / 2 | 2 0 / 2 |
| Live logs Streaming logs/output for each agent in real time. | ● Each session streams tool calls, file edits and intermediate steps live in the chat transcript; a Verbose view mode exposes every step. Logs for each session are also available as jsonl files under `~/.claude/projects/<project-path>/`. Proof 1
| ? | ● Each thread streams the agent output in real time, including tool calls and terminal commands. Proof
| ● Proof
| ● Proof
| ● Proof
| ● Streaming agent output rendered in the built-in TUI. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Provider runtime events stream from codex app-server to the browser via ordered WebSocket pushes. Proof
| ● Proof
|
| Context usage indicator Visualize the current context window fill ratio in the ongoing discussion. | ● Prompt box shows context-window usage; `/compact` and auto-compaction kick in when full. Proof 1
| ? | ? Remote compaction and `/compact`-style flows exist in the CLI; an explicit context-window indicator in the app UI is not documented. | ● Proof 1
| ● Proof 1
| ● "Context ring" with click-through breakdown across rules / skills / MCPs / subagents (since 3.3). Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● ContextWindowMeter component renders the percentage of the context window used. Proof
| ● Proof
|
| Collaboration 3 features | 0 1 / 3 | 0 0 / 3 | 1 1 / 3 | 1 0 / 3 | 1 0 / 3 | 1 0 / 3 | 1 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 1 0 / 3 | 1 0 / 3 |
| Remote plan collaboration A first-class way to publish or share a plan / session artifact with teammates so they can review, comment, or annotate remotely, without needing direct access to the local worktree. | ○ No remote plan-collaboration feature documented for Claude Code Desktop. The app has no first-class way to share planning artifacts with teammates for remote review. | ? | ○ No documented remote plan-collaboration feature. | ○ No remote plan-collaboration surface in Conductor 0.52.3 (no doc/changelog/homepage mention). | ○ No remote plan-collaboration surface in Conductor 0.52.3 (no doc/changelog/homepage mention). | ○ No remote plan-collaboration feature documented. | ○ | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No external plan-collaboration feature documented. | ○ No remote plan-collaboration feature documented. |
| Shared configuration with teammates As soon as the orchestrator exposes a way to share the interesting bits of its configuration with team mates — a committed config file in the repo, an OCI/marketplace registry, an organization-wide settings tier… — this row counts as "yes". A full multi-level hierarchy (user / project / project-local / org…) is a plus but not a requirement. | ◐ The only Desktop-level shared configuration is `.claude/launch.json` (dev server definitions) and Claude Code CLI commands auto-discovered from the project. There is no mechanism to share Desktop-specific UI prompts or run configurations with the team. Proof
| ? | ● Plugins support workspace sharing, share access controls and marketplace distribution, so the interesting bits of configuration can be shared with teammates. CLI also exposes a tiered settings.json hierarchy. Proof
| ● Repo-level conductor.json committed into the codebase shares scripts and settings with the team; org-managed ~/.conductor/settings.json provides an additional admin override tier. Proof 2
| ● Repo-level conductor.json committed into the codebase shares scripts and settings with the team; org-managed ~/.conductor/settings.json provides an additional admin override tier. Proof 2
| ● Project-level .cursor/rules is git-tracked and shared with the team. A full three-tier hierarchy (Team via dashboard / Project / User) is available on top. Proof
| ● Agent teams are declared in versionable YAML files and can be pushed/pulled as OCI artifacts on Docker Hub or any registry — the interesting bits of configuration are fully shareable with teammates. Proof
| ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ● Provider skills resolve from App / System / Project / Personal scopes — the project tier shares the interesting bits of configuration with teammates via the repo. Proof
| ● Cloud mode exposes organization-wide settings and project settings, so the interesting bits of configuration can be shared with teammates. Proof
|
| Share discussion workflows with teammates Distribute authored discussion workflows to team mates — via a shared repository, an in-app registry, or import/export files — so a whole team can run the same deterministic agent playbooks. | ○ Claude Code Desktop offers no mechanism to share discussion workflows. This is a CLI-level feature and is not surfaced in the Desktop UI. | ? | ◐ Plugins and skills can be shared via workspace sharing, share-access controls, and the plugin marketplace; not a dedicated "workflow registry". Proof
| ○ No discussion-workflow authoring, so no sharing surface. | ○ No discussion-workflow authoring, so no sharing surface. | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ? | ○ No discussion-workflow concept to share. | ○ No discussion-workflow concept to share. |
| Platform 2 features | 1 0 / 2 | 0 0 / 2 | 1 1 / 2 | 0 0 / 2 | 0 0 / 2 | 2 0 / 2 | 1 0 / 2 | 1 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 | 1 0 / 2 | 2 0 / 2 | 1 0 / 2 | 1 0 / 2 | 1 0 / 2 | 0 0 / 2 | 0 0 / 2 | 0 0 / 2 |
| Cloud execution The orchestrator runs agents in a cloud environment, not locally. | ● Environment selector in the prompt area exposes a Remote option that runs the session on Anthropic-hosted cloud; sessions continue even after closing the app. SSH sessions are an additional remote option. Proof 1
| ? | ◐ Local execution is the default for the desktop app; "Codex cloud" offers optional background/parallel runs in an OpenAI-managed cloud environment, accessible from the app. Proof
| ○ Conductor v0.52.3 runs locally on macOS. A "Conductor Cloud" tier is announced as Early Access (not tested), so cloud execution is not generally available. Proof
| ○ Conductor v0.52.3 runs locally on macOS. A "Conductor Cloud" tier is announced as Early Access (not tested), so cloud execution is not generally available. Proof
| ● Proof
| ○ Executes locally as a CLI / standalone binary; no managed cloud runtime is offered. Proof
| ● Web-based interface at app.factory.ai. | ? | ? | ? | ? | ● Hosted cloud version available. | ● Browser-based application available with a mobile responsive UI via server mode. | ○ Local-first desktop application. | ○ Focuses on local desktop and web runner executions. | ○ Local desktop application. | ○ No SaaS cloud runtime; T3 Code is a local Node.js server (loopback) optionally exposed over LAN/Tailscale/SSH. Proof
| ○ |
| Plugin system Extend the orchestrator with third-party or user-authored plugins. | ○ The feature assessed here is a plugin system for the ADE itself, not for the coding assistant. Claude Code Desktop has no plugin system that extends the ADE platform. | ? | ● First-class plugin system: 90+ plugins (Atlassian Rovo, CircleCI, CodeRabbit, GitLab, Microsoft Suite, Neon, Render…), plus skills and MCP servers, distributed via a marketplace. Proof
| ○ No plugin / extension mechanism documented. | ○ No plugin / extension mechanism documented. | ● Marketplace bundling rules, skills, agents, commands, MCP servers and hooks. /add-plugin from the editor. Proof
| ● External tools are added by wiring MCP servers (local, remote or Docker-based) into the agent YAML. Proof
| ? | ? | ? | ? | ● Supports Agent Client Protocol (ACP) and ACP Agent Registry. | ● Supports MCP (Model Context Protocol) and ACP. | ? | ● MCP support built-in. | ● Built-in MCP server allows defining workflows, and it supports hooking into different runtimes via an adapter model. | ? | ○ No third-party plugin/extension API for the orchestrator itself. Forking the repo is the documented extensibility path. Proof
| ○ No plugin / extension mechanism documented. |
Reference desk
Tracking sources
Where each vendor publishes news, changelogs, and docs. Used as the starting point when refreshing this dataset for a new release — no need to re-hunt every cycle.
-
Claude Code Desktop
- GitHub releases claude-code GitHub releases
- Docs Claude Code docs (overview)
- Docs Claude Code desktop docs
- Other Claude Code homepage
- Twitter / X ClaudeCodeLog on X
- Twitter / X ClaudeDevs on X
-
cmux
- Other Homepage
- Docs Documentation
- Other GitHub repository
- GitHub releases GitHub Releases
- Twitter / X @manaflowai on X
- Discord Manaflow Discord
- YouTube Manaflow on YouTube
-
Codex App
- Docs Codex App documentation
- Changelog Codex changelog
- Blog OpenAI news — Codex tag
- GitHub releases openai/codex GitHub releases (CLI sibling)
-
Conductor
- Changelog Conductor changelog
- Docs Conductor documentation
- Other Conductor homepage
-
Conductor
- Changelog Conductor changelog
- Docs Conductor documentation
- Other Conductor homepage
-
Cursor 3
- Changelog Cursor changelog
- Blog Cursor blog
- Docs Cursor documentation
- Other Cursor community forum User-driven feature requests and roadmap signals.
-
Docker Agent (cagent)
- GitHub releases cagent GitHub releases
- GitHub commits cagent main commits
- Docs Docker Agent docs
-
Factory
- Other Homepage
- Docs Factory Documentation
- Changelog Factory Changelog
- Other Pricing
- Other Factory IDE product page
- Other Factory GitHub org
- Other Factory CLI repo
- Twitter / X @FactoryAI on X
- Other Factory on LinkedIn
-
GenieBuilder
- Other Homepage
- Docs Documentation
- Blog GenieBuilder blog
- Release notes Releases
- YouTube @GenieBuilder on YouTube
- Twitter / X @DevoxxGenie on X
- GitHub commits GitHub issues (stephanj/GenieBuilder)
-
GitHub Copilot app
- Other GitHub Copilot app preview page
- Release notes Technical preview announcement (GitHub Changelog)
- Blog GitHub Blog
- Docs GitHub Docs
-
Google Antigravity
- Other Homepage
- Docs Antigravity Docs
- Changelog Antigravity Changelog
- Blog Antigravity Blog
- Release notes Antigravity 2.0 Launch Post
- Other Pricing & Plans
- Twitter / X @antigravity on X
- Discord Antigravity community on discuss.ai.google.dev
- YouTube Google Antigravity on YouTube
- GitHub releases Antigravity SDK Python (GitHub)
-
JetBrains Air
- Other Homepage
- Docs JetBrains Air documentation
- Changelog JetBrains Air changelog
- Blog The Air Blog
- Twitter / X @getsome_air on X
-
Multica
- Other Multica — official site
- Docs Multica Docs
- Changelog Multica Changelog
- Blog Multica About / story
- GitHub releases multica-ai/multica releases
- Twitter / X @MulticaAI on X
-
mux (Coder)
- Other Homepage / Documentation
- Other GitHub repository
- GitHub releases GitHub Releases
- Discord Coder Discord
-
Nimbalyst
- Other Homepage
- Docs Documentation
- Blog Nimbalyst blog
- Other Features
- Other GitHub repository
- GitHub releases GitHub Releases
- Discord Nimbalyst Discord
-
OpenDucktor
- Other GitHub repository
- Docs Docs directory
- GitHub releases GitHub Releases
- GitHub commits GitHub Commits (main)
-
Switchboard
- Other GitHub repository
- GitHub releases GitHub Releases
- GitHub commits GitHub Commits (main)
-
T3 Code
- GitHub releases t3code GitHub releases
- GitHub commits t3code main commits
- Docs t3code README
- Other t3.codes homepage
-
Vibe Kanban
- GitHub releases vibe-kanban GitHub releases
- GitHub commits vibe-kanban main commits
- Docs Vibe Kanban documentation
- Blog Vibe Kanban blog Only the shutdown announcement is currently linked; no public blog index found.