Your call
Rate features.
Shape your ranking.
Raw coverage treats every feature the same. Weigh the 56 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.61 63.4%
- #2 Claude Code Desktop v1.8089.1 50.9%
- #3 Vibe Kanban v0.1.44 50.9%
- #4 T3 Code v0.0.24 46.4%
Main event
4 contenders · 56 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 26 5 / 56 paid
closed source
v1.8089.1 · latest reviewed Released
| cmux 1 0 / 56 free
oss
v0.64.9 · preview Released
| Codex App 14 12 / 56 paid
closed source
v26.513.31313 · preview Released
| Conductor 33 5 / 56 free
v0.61 · latest reviewed Released
| Conductor 32 5 / 56 free
v0.52.3 Released
| Cursor 3 17 9 / 56 freemium
v3.4.17 · preview Released
| Docker Agent (cagent) 7 1 / 56 free
oss
v1.59.0 · preview Released
| Emdash 21 5 / 56 free
oss
v1.1.27 · preview Released
| Factory 5 0 / 56 paid
closed source
v0.128.0 · preview Released
| GenieBuilder 1 0 / 56 closed source
v0.7.2 · preview Released
| GitHub Copilot app 3 0 / 56 paid
vtechnical-preview-2026-05-14 · preview Released
| Google Antigravity 1 0 / 56 freemium
closed source
v2.0.2 · preview Released
| JetBrains Air 2 0 / 56 freemium
v261.584.13 · preview Released
| Multica 3 0 / 56 freemium
oss
v0.3.6 · preview Released
| mux (Coder) 3 0 / 56 free
oss
v0.25.0 · preview Released
| Nimbalyst 6 0 / 56 free
oss
v0.61.1 · preview Released
| OpenDucktor 10 0 / 56 free
oss
v0.3.1 · preview Released
| Orca 21 4 / 56 free
oss
v1.4.43 · preview Released
| Superconductor 16 7 / 56 free closed source
valpha · preview Released
| Superset 16 14 / 56 freemium
oss
v1.12.1 · preview Released
| Switchboard 4 0 / 56 free
oss
v0.0.30 · preview Released
| T3 Code 23 6 / 56 free
oss
v0.0.24 · latest reviewed Released
| Vibe Kanban 26 5 / 56 free
oss
v0.1.44 · latest reviewed Released
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Worth noting | |||||||||||||||||||||||
| Model wiring how vendor models are plugged in |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Workflow 18 features | 5 3 / 18 | 0 0 / 18 | 3 3 / 18 | 10 1 / 18 | 10 1 / 18 | 3 1 / 18 | 2 1 / 18 | 7 1 / 18 | 1 0 / 18 | 0 0 / 18 | 1 0 / 18 | 0 0 / 18 | 0 0 / 18 | 0 0 / 18 | 0 0 / 18 | 2 0 / 18 | 4 0 / 18 | 2 2 / 18 | 3 3 / 18 | 2 3 / 18 | 1 0 / 18 | 6 3 / 18 | 9 0 / 18 |
| Each agent works in its own isolated git worktree. | 1Git worktree isolationEach agent works in its own isolated git worktree. Proof
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. | | Git worktree isolationEach agent works in its own isolated git worktree. Proof
Codex App ships built-in worktree support so each agent thread can work on an isolated copy of the repo. | 3Git worktree isolationEach agent works in its own isolated git worktree. Proof
| 3Git worktree isolationEach agent works in its own isolated git worktree. Proof
| Git worktree isolationEach agent works in its own isolated git worktree. Proof
| Git worktree isolationEach agent works in its own isolated git worktree. Proof
No worktree concept; the agent runs against the directory passed via --working-dir. | Git worktree isolationEach agent works in its own isolated git worktree. Proof
Each task runs in its own isolated git worktree by default. | | | | | | | | Visual Git management and worktrees supported natively. | Each Builder task runs in a dedicated Git worktree to isolate implementation from the main checkout. | Git worktree isolationEach agent works in its own isolated git worktree. Proof
Each task runs in its own real git worktree, the core of Orca’s parallel-agent isolation model. | Git worktree isolationEach agent works in its own isolated git worktree. Proof
Each Git-backed task runs in its own isolated git worktree with its own branch, terminal, sessions and review diff. | Git worktree isolationEach agent works in its own isolated git worktree. Proof
Core architecture: each agent/branch runs in its own isolated git worktree. | | 1Git worktree isolationEach agent works in its own isolated git worktree. Proof | Git worktree isolationEach agent works in its own isolated git worktree. Proof
|
| 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 runs Claude Code with the host user’s permissions. The system prompt does include claims telling the session not to modify files outside its worktree, but that is a prompt-level guardrail, not enforced isolation. | | Agent sandbox isolationWhether 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. Proof
OS-level sandbox: Seatbelt on macOS, native Windows sandbox under PowerShell (or bwrap under WSL2), bubblewrap on Linux. | 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. | Agent sandbox isolationWhether 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. Proof
Tool capabilities can be wired through Docker-based MCP servers, so external tools run inside their own container instead of on the host. | Agent sandbox isolationWhether 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. Proof
Isolation is git-worktree-based only; the only Docker mention is a user-authored lifecycle-script example, not orchestrator-level sandboxing. | 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. | Agent sandbox isolationWhether 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. Proof
Only worktree-level filesystem separation, not orchestrator OS sandboxing (no Docker/micro-VM/chroot). The Docker-isolated "orca" in search results is the unrelated rasca/orca repo, not stablyai/orca. | No orchestrator-level sandbox (container/micro-VM/chroot/sandbox-exec) documented. Agents run as local processes using your shell, tools and credentials; the only documented isolation is the git worktree. Any sandboxing is delegated to the agent CLI. | Isolation is git-worktree (filesystem) only; no orchestrator-level Docker/VM/chroot/sandbox-exec layer documented. Docker appears solely as user-supplied setup/teardown commands, not a sandbox Superset enforces. | | 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. |
| Run the agent directly inside an existing repository, without creating a git worktree. | 1Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
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. | | 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. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Every workspace is a worktree; there is no mode that runs against the original checkout. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Every workspace is a worktree; there is no mode that runs against the original checkout. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Worktrees are opt-in via the /worktree command — agents otherwise run on the current checkout. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Always operates in the current directory (or --working-dir); there is no worktree layer. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Worktrees can be disabled to run directly on the checked-out branch (with a warning that changes are not isolated). | | | | | | | | | | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
All sources frame worktrees as core/mandatory; no documented no-worktree / run-in-place mode. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
The primary worktree runs agents directly in the repo checkout without creating a task worktree; non-Git plain folders also run sessions without worktrees. | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Existing on-disk worktrees can be imported as workspaces, but agent sessions still require a workspace/worktree. No documented mode to run an agent directly in the repo without a worktree. | | 1Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof | Work without a worktreeRun the agent directly inside an existing repository, without creating a git worktree. Proof
Worktree creation is a required step for every workspace. |
| 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
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. | | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
Threads are organized "by project", with worktree isolation per agent; whether multiple threads can share a single worktree is not documented. | 1Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
Multiple chat tabs per workspace; switching agents mid-chat opens a new tab. | 1Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
Multiple chat tabs per workspace; switching agents mid-chat opens a new tab. | 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. | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
A task (worktree) hosts multiple conversation tabs and terminals, each created with ⌘T / ⌘⇧T. | | | | | | | | | | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
Plural "agent sessions" per worktree card with per-session status dots = multiple sessions per worktree, visually attached. README: agents run side-by-side in tabs and panes, each launched via combobox (mixed models possible). | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
A Git-backed task worktree owns multiple terminal tabs and chat sessions, each bound to that worktree, with per-session model/reasoning controls. | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
CLI can create multiple agent sessions in one workspace, each a fresh terminal session with its own agent preset. Per-session model/topic and explicit UI attachment to the parent worktree are not documented verbatim. | | 1Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof The new-thread composer can point a thread at an existing worktree, but there is no visual way to group or surface the several sessions that share one worktree together. | Multiple sessions per worktreeA 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. Each session must also be visually attached to its parent worktree in the UI, so it stays obvious at a glance which sessions share the same workspace. Proof
|
| 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. | Workflow shell hooksRun 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. Proof
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. | | Workflow shell hooksRun 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. Proof
Hooks went GA on 2026-05-14; lifecycle hooks include PreToolUse and pre/post-compaction, browsable from `/hooks`. | 1Workflow shell hooksRun 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. Proof
Three lifecycle scripts: setup (on creation), run (on demand), archive (before archival). | 1Workflow shell hooksRun 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. Proof
Three lifecycle scripts: setup (on creation), run (on demand), archive (before archival). | Workflow shell hooksRun 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. Proof
Worktree setup scripts (setup-worktree-unix / -windows) run on worktree creation. No archival hook documented; plugin hooks cover broader agent events. | | Workflow shell hooksRun 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. Proof
Lifecycle scripts run setup/run/teardown commands at task lifecycle events. | | | | | | | | | | Workflow shell hooksRun 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. Proof
Setup hooks run arbitrary shell commands on worktree creation. No evidence of archival or session start/stop hooks, hence partial. | Workflow shell hooksRun 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. Proof
Lifecycle shell hooks exist for worktree creation (setup) and deletion (teardown, pre_cleanup, post_cleanup), but no documented session start/stop hooks. Worktree-level bootstrap/cleanup only. | Workflow shell hooksRun 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. Proof
Setup runs on workspace creation, teardown on deletion, run on the Run button — configured in .superset/config.json. No session start/stop hooks documented. | | 2Workflow shell hooksRun 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. Proof | Workflow shell hooksRun 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. Proof
vk 0.1.44 exposes four per-repo lifecycle scripts: Setup (after worktree creation, before the agent), Cleanup (after the agent run, if changes were made), Archive (on workspace archival), plus Dev Server. Public docs still lag (Archive not yet listed). |
| 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. | Per-worktree port allocation & env varsEach 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. Proof
`autoPort: true` in `launch.json` allocates a free port and passes it via `PORT`; no general per-worktree port pool. | | No documented per-worktree port pool or env-var injection in public docs. | 1Per-worktree port allocation & env varsEach 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. Proof
CONDUCTOR_PORT exposes the first of 10 ports assigned to the workspace, plus other workspace env vars. | 1Per-worktree port allocation & env varsEach 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. Proof
CONDUCTOR_PORT exposes the first of 10 ports assigned to the workspace, plus other workspace env vars. | Per-worktree port allocation & env varsEach 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. Proof
Only $ROOT_WORKTREE_PATH is exposed to setup scripts; no per-worktree port pool or env-var allocation documented. | | Per-worktree port allocation & env varsEach 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. Proof
Each task gets EMDASH_PORT, the base of a reserved 10-port range, exposed to scripts. | | | | | | | | | | Worktrees described as having own branch/files/terminals, but no mention of port allocation or ORCA_ env vars. Only port feature found is SSH port forwarding, unrelated to per-worktree port pools. | No documentation of per-worktree port pools or port env vars. Only SUPERCONDUCTOR_TERMINAL_ID and provider config-dir env vars are mentioned; nothing about free-port allocation for parallel servers. | Per-worktree port allocation & env varsEach 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. Proof
Superset does not allocate per-workspace ports; it only discovers listening ports and manages them in the UI. Scripts get SUPERSET_ROOT_PATH/WORKSPACE_NAME/WORKSPACE_PATH env vars but no port env vars. | | Project scripts receive T3CODE_PROJECT_ROOT and T3CODE_WORKTREE_PATH, but no per-worktree free-port pool is allocated. | No per-worktree port allocation or env-var pool documented. |
| Bring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. | Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
`.worktreeinclude` (gitignore-syntax) copies untracked files like `.env` or `secrets.json` into each new worktree. | | Worktree behaviour for untracked files like `.env` is not documented in public sources. | 1Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Glob-based "Files to copy" feature; defaults to `.env*` and can be shared via `.worktreeinclude`. | 1Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Glob-based "Files to copy" feature; defaults to `.env*` and can be shared via `.worktreeinclude`. | Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Worktree setup script exposes $ROOT_WORKTREE_PATH to copy files from the main checkout (typically .env). | | Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Preserve patterns copy untracked/gitignored files such as .env into new tasks. | | | | | | | | | | No mention of copying gitignored/.env files or a worktree setup script in any Orca source; CLI worktree create shows no copy/setup flag. Insufficient evidence to confirm or deny. | Docs cover config-file fallback to the primary worktree, but never describe copying source-repo files (e.g. .env/secrets) into a new worktree. Area not covered. | Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Setup scripts run on each workspace creation and the canonical docs example copies the root .env into the worktree via cp. SUPERSET_ROOT_PATH points to the main repo, so any source-repo file can be copied in. | | 1Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof No first-class glob UI, but a project script with runOnWorktreeCreate:true can use T3CODE_PROJECT_ROOT env var to cp files into the new worktree. | Copy files from origin workspaceBring files (e.g. .env, local secrets) from the source repo into the agent worktree by copy. Proof
Repository 'Copy Files' setting: a comma-separated list of files (e.g. .env, .claude) copied from the original repo directory into the worktree, after creation and before the setup script runs. |
| Expose files from the source repo inside the agent worktree via symlinks (ln -s). | Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof
`.worktreeinclude` copies files; no first-class symlink mechanism is documented (could be scripted via a `WorktreeCreate` hook). | | No documented symlink-from-origin mechanism. | 1Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof
No first-class UI, but documented as a setup-script pattern using `ln -sf "$CONDUCTOR_ROOT_PATH/…"`. | 1Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof
No first-class UI, but documented as a setup-script pattern using `ln -sf "$CONDUCTOR_ROOT_PATH/…"`. | Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof
Explicitly discouraged by Cursor. | | Docs describe copying (preserve patterns) files into worktrees but never mention symlinking source-repo files. | | | | | | | | | | No dedicated symlink/copy-from-origin feature. Settings only offer "Auto-run commands on worktree create" (generic hook, could run ln -s manually). No explicit .env/secrets file-sharing. | No mention of symlinking origin-repo files into a worktree anywhere in the docs. Area not covered. | Setup scripts run arbitrary shell, so ln -s from SUPERSET_ROOT_PATH is technically achievable, but no docs describe symlinking source-repo files into the worktree as a feature. | | 1Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof Same runOnWorktreeCreate setup-script pattern; user runs ln -sfn with T3CODE_PROJECT_ROOT env var, no first-class symlink declaration. | Symlink files from origin workspaceExpose files from the source repo inside the agent worktree via symlinks (ln -s). Proof
No symlink mechanism. The 'Copy Files' repository setting performs a real copy of the listed files into the worktree, not a symlink; no ln -s / shared-file option exists. (Distinct from copy-from-origin-workspace, which Copy Files does support.) |
| 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`. | 3Session handoff via shared context dirA 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. Proof
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. | 3Session handoff via shared context dirA 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. Proof
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. | No dedicated shared-context directory documented; users typically rely on rules/skills or AGENTS.md. | Session handoff via shared context dirA 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. Proof
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. | No documented gitignored persistence dir for plans/notes carried between sessions; tmux state persistence exists but is different. | | | | | | | | 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. | Session handoff via shared context dirA 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. Proof
Orca's "session restore" is terminal/UI state only; tab-profiles recreate pane layouts. No gitignored dir for plan.md/handoff artifacts is documented. | The 'shared context' page covers shared-context workspaces grouping child repos for joint review, not a gitignored handoff dir; it states it gives 'no built-in notes surface'. No persisted cross-session artifact dir documented. | No documentation of a dedicated gitignored shared-context dir (e.g. .context) for persisting plans/notes/handoff artifacts that later sessions on the same worktree reference. | | 1Session handoff via shared context dirA 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. Proof | Session handoff via shared context dirA 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. Proof
No shared-context dir; sessions explicitly do not inherit conversation history. |
| 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. | Read-only plan/research modeA 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. Proof
Plan mode is a first-class permission mode in the Code tab, with its own "plan" pane and the Cmd+Shift+M permission-mode menu — Claude explores and proposes a plan without editing source. | | | Read-only plan/research modeA 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. Proof
Conductor surfaces a first-class Plan Mode (distinct from Fast Mode) where the agent prepares an approach before editing; v0.50.0 hardened it so plan-mode sessions no longer terminate when ExitPlanMode is denied. | Read-only plan/research modeA 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. Proof
Conductor surfaces a first-class Plan Mode (distinct from Fast Mode) where the agent prepares an approach before editing; v0.50.0 hardened it so plan-mode sessions no longer terminate when ExitPlanMode is denied. | | | No mention of a read-only plan/research discussion mode; emdash delegates to the underlying agent CLI. | | | | | | | | | Specifier and Planner roles are explicitly read-only and automatically reject mutating permissions. | Searched docs, subpages, homepage, changelog, GitHub. No read-only/plan/research mode found. Orca runs CLI agents in their own terminals, so plan mode would be the agent's, not Orca's. | Docs cover chat agents, model/reasoning controls and mention 'a short implementation plan' as shared context, but describe no dedicated read-only plan/research mode that inspects without editing and hands off to a cheaper model. | No mention of a read-only plan/research discussion mode. Superset is agent-agnostic and launches CLI agents; any plan mode would belong to the underlying agent, not Superset itself. | | 1Read-only plan/research modeA 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. Proof | Read-only plan/research modeA 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. Proof
Both the Claude and Codex executors expose a `plan` config toggle: when on, permission_mode() returns Plan and a PreToolUse hook blocks every editing tool except ExitPlanMode/AskUserQuestion — a read-only planning mode (per-executor config, not a one-click chat toggle). |
| 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. | | Predefined deterministic workflowsLaunch 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. Proof
Persisted `/goal` workflows (2026-04-30) cover create / pause / resume / clear across app-server APIs; predefined research→plan→implement catalog is not documented. | 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. | | | Predefined deterministic workflowsLaunch 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. Proof
No built-in research→plan→implement→review pipelines; agents run freely in worktrees with optional setup/run/teardown shell scripts only. | | | | | | | | | Follows a strict Specifier -> Planner -> Builder -> QA loop based on task transitions. | Predefined deterministic workflowsLaunch 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. Proof
No catalog of fixed-phase workflows found. Automations run one prompt per session on a schedule, not a phased pipeline. | Settings offer per-action agent routing and a fixed list of action prompts (Create PR, Fix CI, Resolve conflicts, Review…), but no catalog of built-in fixed multi-phase deterministic workflows (research→plan→implement→review). | Predefined deterministic workflowsLaunch 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. Proof
Closest feature, Automations, is a cron-style scheduler for single-prompt agent runs, not phased workflows. Presets are static terminal-launch configs. No built-in research→plan→implement→review pipelines. | | 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. |
| 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. | | Custom deterministic workflowsDefine your own deterministic discussion workflows — ordered phases, per-step prompts, gating conditions, model/tool overrides — to make agent sessions repeatable across runs. Proof
Skills + `/goal` workflows let users author reusable multi-step flows; no fully deterministic ordered-phases workflow definition is documented. | No user-authored multi-step discussion workflow mechanism documented. | No user-authored multi-step discussion workflow mechanism documented. | | | Custom deterministic workflowsDefine your own deterministic discussion workflows — ordered phases, per-step prompts, gating conditions, model/tool overrides — to make agent sessions repeatable across runs. Proof
Customization is limited to reusable prompts and setup/run/teardown shell scripts, not authored multi-step deterministic workflows. | | | | | | | | | | Custom deterministic workflowsDefine your own deterministic discussion workflows — ordered phases, per-step prompts, gating conditions, model/tool overrides — to make agent sessions repeatable across runs. Proof
Docs/changelog/repo describe parallel agent execution + cron-style automations only. No ordered-phase, gated, per-step workflow authoring. | The sc CLI/local API can script the live app and settings allow per-action prompts/routing, but nothing documents user-defined ordered discussion phases with per-step prompts, gating and model/tool overrides repeatable across runs. | Custom deterministic workflowsDefine your own deterministic discussion workflows — ordered phases, per-step prompts, gating conditions, model/tool overrides — to make agent sessions repeatable across runs. Proof
No authoring of ordered multi-phase workflows with per-step prompts/gating/model overrides. Automations are single-prompt scheduled runs; presets only define launch commands and panes. | | 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 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. | 2Fork workspace to a new worktreeFork 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. Proof 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. | | Fork workspace to a new worktreeFork 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. Proof
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. | 1Fork workspace to a new worktreeFork 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. 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. | 1Fork workspace to a new worktreeFork 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. 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. | | | Fork workspace to a new worktreeFork 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. Proof
The only 'fork' feature is a git remote split for GitHub fork workflows (upstream/origin), not cloning a worktree's state + history into a new workspace. | | | | | | | | | | Fork workspace to a new worktreeFork 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. Proof
Worktree creation = pick a git start-from ref. No "fork workspace incl. session history + local files" feature found across docs, changelog, README, releases. Session restore covers relaunch, not forking. | Docs describe creating new worktrees and parallel work, but no action forks an entire workspace state (worktree contents + session/chat history + local-only files) into a brand-new worktree. | No public doc or changelog entry describes forking/cloning a workspace (worktree + session/chat history) into a new worktree. Docs cover creating from branch/PR and importing existing worktrees, but not duplicating a workspace. | 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. | Fork workspace to a new worktreeFork 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. Proof
No documented "fork workspace" action; new workspaces are created from the source repo, not by cloning an existing workspace. |
| 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. | Unarchive a worktreeAfter 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. Proof
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. | | | 1Unarchive a worktreeAfter 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. 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. | 1Unarchive a worktreeAfter 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. 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. | | | Unarchive a worktreeAfter 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. Proof
Tasks can be archived and restored. | | | | | | | | | | Archive exists, but no documented unarchive/restore action found anywhere; archive is paired with delete as removal. Insufficient evidence to confirm or deny resumability. | Unarchive a worktreeAfter 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. Proof
Worktree cleanup is destructive: it removes the worktree and clears Superconductor's local runtime state (stale diffs, PR state, setup markers, session metadata). There is no archive/unarchive concept to bring a removed worktree back. | No archive/unarchive concept exists in Superset. Docs and changelog reference creating, importing, and deleting worktrees only; best practice is deleting workspaces after merging. | | 1Unarchive a worktreeAfter 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. Proof | Archived workspaces remain viewable via 'View Archive', but no unarchive action is reachable in the 0.1.44 UI — there is no surfaced affordance to restore an archived workspace to the active list. |
| Merge the current work locally into the configured target branch directly from the ADE. | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
Integration is PR-centric: the only merge surfaced is GitHub PR auto-merge (squash, server-side once CI passes). No UI action merges the current worktree into a configured local target branch. | | | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
The review/merge flow is GitHub-PR-centric (merge happens via the approved PR; v0.55.0 added automerge-on-CI for PRs). No documented action to merge the workspace into the target branch locally. | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
The review/merge flow is GitHub-PR-centric (merge happens via the approved PR; v0.55.0 added automerge-on-CI for PRs). No documented action to merge the workspace into the target branch locally. | | | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
Merge is offered, but the documented merge action operates on the GitHub PR via GitHub’s API rather than a local target-branch merge from the ADE. | | | | | | | | | | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
Ship step is push + open PR. No first-class local-merge-to-target action found in docs; merge only referenced as conflict resolution. Raw git merge possible via terminal escape hatch. | Docs mention reviewing 'before you commit, push, merge, or discard' but direct you to commit or push through your normal git flow. No explicit in-ADE action that merges current work locally into the configured target branch; merge wording is ambiguous. | Changelog mentions a PR merge button (merge via GitHub PR), but no documented capability to merge current work locally into a configured target branch from within the app. | | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
In-app git actions are commit, push, pull and create/open PR plus branch checkout and worktree selection — there is no merge action and no configured target branch to merge into. | Local merge to target branchMerge the current work locally into the configured target branch directly from the ADE. Proof
The GitMerge action calls workspacesApi.merge(workspaceId, { repo_id }) to merge locally into the configured target branch — distinct from the Create-PR flow, and it refuses to merge directly while an open PR exists, confirming it is a local git merge. |
| Merge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. | No dedicated UI action to merge/rebase onto a chosen branch with LLM-resolved conflicts. The agent can resolve conflicts only as an ad-hoc task; integration stays PR-centric (commit → PR → GitHub-side auto-fix/auto-merge). | | | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
Conductor has a merge-conflict-resolution UI (v0.58.0: conflicted files sorted to top of the git panel, accept buttons in the diff view) but it is a manual accept-hunks surface, not LLM/agent-driven conflict resolution. Rebase support is detection/preference only. | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
Conductor has a merge-conflict-resolution UI (v0.58.0: conflicted files sorted to top of the git panel, accept buttons in the diff view) but it is a manual accept-hunks surface, not LLM/agent-driven conflict resolution. Rebase support is detection/preference only. | | | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
No LLM-assisted conflict resolution; merge is a GitHub-API PR merge. | | | Agent Merge addresses review comments, fixes failing checks, and merges. | | | | | | | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
Homepage lets you "resolve conflicts ... all in-app" — but framed as human review/triage within the UI, not an LLM-assisted merge/rebase onto a target branch where the agent resolves collisions. | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
Configurable agent-routed action prompts include 'Resolve conflicts' and 'Fix blocked merge', so conflict resolution can be handed to the LLM. Initiating a merge/rebase onto a chosen branch as an ADE operation is not documented. | No public evidence of merge/rebase onto a branch with LLM conflict resolution. Changelog has no rebase or AI-assisted conflict-resolution entries; the diff viewer documents no merge/rebase features. | | T3 Code's GitManager only exposes status, checkout (switchRef), commit, push and PR creation. There is no merge/rebase operation and no LLM-assisted conflict resolution. | LLM-assisted merge/rebaseMerge or rebase onto a chosen branch, defaulting to the target branch, with conflicts resolved through the LLM. Proof
Rebase (and merge) onto the chosen/target branch is available; on conflict the ResolveConflictsDialog hands the conflicted files to the coding agent with an LLM prompt built by buildResolveConflictsInstructions. |
| Show multiple repositories at once and filter the UI to focus on selected repositories. | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
Multiple repositories are supported only in remote (cloud) sessions — add repos via the "+" next to the repo pill, each with its own branch selector. Local sessions are single-folder, and there is no consolidated always-on multi-repo browse view. | | | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
v0.35.2 lets you group workspaces by repository — workspace organisation per repo rather than a simultaneous filtered multi-repo dashboard, hence partial. | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
v0.35.2 lets you group workspaces by repository — workspace organisation per repo rather than a simultaneous filtered multi-repo dashboard, hence partial. | | | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
Emdash organizes work by project (one repo) and task; no simultaneous multi-repo view is documented. | | | | | | | | | | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
Workspace page shows issues across all connected repos in one list. Multi-repo surfacing confirmed; per-repo UI filtering to a subset not explicitly documented. | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
Experimental shared-context workspaces group multiple child repos under one parent; file search and review aggregate across child repos, so multiple repos show at once. A UI filter to focus on a selected subset is not clearly documented. | Each workspace is one git branch within a single repository's worktrees; no documented UI to show multiple repositories at once or filter by selected repos. | | The sidebar lists repositories only for switching, with one repository active at a time. Cross-clone correlation via remote-URL normalization covers clones of the same repo, not a unified multi-repository surface. | Multi-repository viewShow multiple repositories at once and filter the UI to focus on selected repositories. Proof
A workspace can contain several repositories; GitPanelContainer renders them all as RepoCards at once and the diff stream aggregates files keyed by repoName. Repos are selected at workspace-creation time and there is no dedicated per-repo filter toggle. |
| Target several repositories, such as frontend and backend, within one discussion. | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
A single remote session can target several repositories at once (e.g. a shared library and its consumers); limited to remote sessions, not local. | | | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
The data model is strictly 1 project = 1 repository, and a workspace is an isolated copy of a single repository — a workspace/discussion cannot span multiple repos (frontend + backend). | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
The data model is strictly 1 project = 1 repository, and a workspace is an isolated copy of a single repository — a workspace/discussion cannot span multiple repos (frontend + backend). | | | No documentation of targeting multiple repositories in a single conversation. | | | | | | | | | | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
Architecture is worktree-per-task (single repo each). Cross-repo is limited to browsing GitHub issues across connected repos, not multi-repo agent chat targeting. | Shared context allows a parent task that dispatches child tasks across related repos, but every chat session belongs to a single worktree; the model is parent-dispatch to separate child tasks, not one discussion explicitly targeting several repos at once. | No documented ability to target several repositories within one chat/discussion. Chat is scoped to a single workspace (one branch/one repo). | | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
Threads are single-project: each thread resolves a single workspace cwd. No mechanism lets one chat message target multiple repositories — multi-repo work requires separate threads. | Multi-repository chat targetingTarget several repositories, such as frontend and backend, within one discussion. Proof
Create-mode state holds repos: SelectedRepo[] with addRepo (dedup-guarded), each with its own target branch — a single task/session/chat operates across all selected repositories in one workspace. |
| User experience 21 features | 13 0 / 21 | 0 0 / 21 | 6 3 / 21 | 13 2 / 21 | 12 2 / 21 | 4 5 / 21 | 1 0 / 21 | 6 2 / 21 | 1 0 / 21 | 0 0 / 21 | 0 0 / 21 | 0 0 / 21 | 0 0 / 21 | 0 0 / 21 | 0 0 / 21 | 2 0 / 21 | 3 0 / 21 | 13 0 / 21 | 4 2 / 21 | 9 4 / 21 | 3 0 / 21 | 8 2 / 21 | 8 3 / 21 |
| Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
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. | | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
Threads are organized by project in a sidebar/list, not as a board-style visual surface. | 2Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style 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. | 2Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style 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. | 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. | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
Tasks are presented in a left-sidebar list (with shift-range selection), not a kanban/board surface. | | | | | | | | Kanban board for parallel session management. | Task-first workflow with a Kanban board as the main operational view. | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
Tasks page hosts a kanban-style GitHub project board; sidebar also shows inline agent status dots (yellow working / green done) for visual monitoring across agents. | Worktrees/tabs appear in a left sidebar list and via command-palette search, but no kanban or board-style task surface is documented. A flat sidebar list is not a board. | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
Tasks UI is explicitly a table-based view, not a kanban/board. Workspace cards do show status labels (In Progress, Ready for Review), but there is no board/column-style task surface. | Launch, resume, fork, and monitor sessions; no juggling terminal tabs. | No board-style visual surface; threads are surfaced through a sidebar/workspace list. | Visual task management (e.g. kanban board)Visual management of in-progress tasks — e.g. via a kanban board or another board-style surface. Proof
|
| 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. | Activity history dashboardA 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. Proof
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. | | Activity history dashboardA 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. 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. | 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. | Activity history dashboardA 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. Proof
Agents Window sidebar aggregates local + cloud + remote SSH agents across repos. Live-oriented; no dedicated historical/audit timeline of past archived activity documented. | | Activity history dashboardA 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. Proof
No historical cross-run activity dashboard; a resource/performance monitor exists for diagnosing usage but is not a run history. | | | | | | | | | | Activity history dashboardA 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. Proof
Agents feed is a live, threaded cross-worktree feed pinning running agents at top; explicitly a catch-up surface for what changed, not an archive of past runs/completed tasks. | Activity history dashboardA 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. Proof
History is documented only as a per-worktree 'History picker' scoped by workspace and worktree. No cross-worktree/cross-project historical activity dashboard or audit timeline is described. | No evidence of a historical activity dashboard, archived-session history, or past-runs aggregation across the orchestrator on homepage, docs index, or changelog. | | Sidebar groups live threads per workspace; no dedicated dashboard surfacing historical activity (past runs, archived threads) across the whole orchestrator. | Activity history dashboardA 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. Proof
Live workspace sidebar groups Needs Attention / Idle / Running across workspaces, but no dedicated historical/audit timeline of past activity is documented. |
| Browse the worktree file tree from within the app. | 1File tree browserBrowse the worktree file tree from within the app. Proof
The Files panel exposes a full project file-tree browser that lets you navigate and open any file in the project. | | File tree browserBrowse the worktree file tree from within the app. Proof
Sidebar exposes the project files with rich previews (PDF, spreadsheets, documents) since the April 2026 update. | 1File tree browserBrowse the worktree file tree from within the app. 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. | 1File tree browserBrowse the worktree file tree from within the app. 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. | File tree browserBrowse the worktree file tree from within the app. Proof
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. | | File tree browserBrowse the worktree file tree from within the app. Proof
The in-app file editor shows the worktree file tree for browsing. | | | | | | | | | | File tree browserBrowse the worktree file tree from within the app. Proof
Dedicated docs page for the file explorer; files colored by git status, per-worktree tree, real-time filesystem sync. | File tree browserBrowse the worktree file tree from within the app. Proof
Documented project file tree browsing in the app, including for non-Git projects, plus drag-and-drop onto the file tree. | File tree browserBrowse the worktree file tree from within the app. Proof
File Explorer in right sidebar with hierarchical tree view and search. | | Only the diff-scoped ChangedFilesTree was found; no general worktree file browser component identified in the web app. | File tree browserBrowse the worktree file tree from within the app. Proof
No in-app full-worktree browser. The Changes panel exposes only a changed-files tree with name filtering; arbitrary files/directories in the worktree cannot be navigated or read from the UI. |
| Edit and save files directly from the in-app file browser. | 1Inline file editingEdit and save files directly from the in-app file browser. Proof
Desktop file pane supports spot edits with Save, with stale-file detection. | | Files can be opened with rich previews from the sidebar; user-driven inline editing/save is not explicitly documented. | 1Inline file editingEdit and save files directly from the in-app file browser. Proof
Built-in file editor with full syntax highlighting and ⌘F. | 1Inline file editingEdit and save files directly from the in-app file browser. Proof
Built-in file editor with full syntax highlighting and ⌘F. | Inline file editingEdit and save files directly from the in-app file browser. Proof
Cursor is a full code editor — files can be edited and saved directly. | Agents can edit files via the filesystem toolset, but there is no in-app editor surface. | Inline file editingEdit and save files directly from the in-app file browser. Proof
Built-in editor edits files in the worktree with syntax highlighting and save to disk. | | | | | | | | | | Inline file editingEdit and save files directly from the in-app file browser. Proof
Homepage: "VS Code's editor, autosave everywhere"; docs list "Monaco editor & autosave" under Editing. Clear in-app inline editing with autosave. | Inline file editingEdit and save files directly from the in-app file browser. Proof
The file area is browse/preview only (Preview File, Copy Path, Open With) with external-editor handoff. Docs explicitly say to 'Edit files through your usual tools'; no in-app edit/save surface. | Inline file editingEdit and save files directly from the in-app file browser. Proof
Edit mode toggle with Ctrl+S to save directly from the diff; a full file editor pane was later added. | | 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. | Files are reviewed and commented on; no in-app editor documented. Open-in-IDE is the documented path to edit. |
| Open one or several terminal windows rooted in the current worktree. | 1Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Desktop app has an integrated terminal pane rooted in the session's working directory. | | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Multiple terminal tabs per thread, rooted in the thread workspace. | 2Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Multiple terminal windows can be opened simultaneously on the same worktree (Terminal 1, Terminal 2, ...). | 2Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Multiple terminal windows can be opened simultaneously on the same worktree (Terminal 1, Terminal 2, ...). | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
| cagent is itself a terminal tool — no embedded shell pane in a worktree because there is no worktree UI. | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Terminals are created per task rooted in the task workspace (⌘⇧T), with a terminal drawer (⌘J). | Supervised command line access. | | | | | | | | | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Docs confirm per-task agent terminal in its own worktree; homepage adds "Terminal Splits ... infinite splits" for multiple terminals. | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Terminals run rooted in the selected worktree directory; a task worktree owns its terminal tabs. | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
Persistent terminal sessions per workspace (git worktree), with multiple terminal tabs and a New Terminal action. | Built-in Terminal to connect to running sessions or launch new ones. | 1Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof | Terminal in worktreeOpen one or several terminal windows rooted in the current worktree. Proof
|
| Define and launch shell commands ("run configurations") directly from the UI. | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Only web preview is supported through .claude/launch.json, but specific configurations cannot be triggered directly from the UI | | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Each thread can launch "repeatable project actions" and run commands directly from the UI. | 3Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
A single run script per repo, launched from the Run button (concurrent or nonconcurrent mode). | 3Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
A single run script per repo, launched from the Run button (concurrent or nonconcurrent mode). | No user-defined "run configuration" UI; the worktree setup script is a single hook, not a launchable command catalogue. | | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Run scripts are configured in Project Settings and launched with play controls, but it is a single configured run/setup/teardown set, not arbitrary named commands. | | | | | | | | | | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Quick Commands = declarative, named, one-click run configs (dev/test/build) launchable from the tab bar. Confirmed in /docs/terminal and /docs/settings. | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Run commands are defined in project config/settings and launched from the in-UI run button. | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Terminal presets launch pre-configured shell commands from the UI via a presets bar and run button. | | 2Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof | Run configurationsDefine and launch shell commands ("run configurations") directly from the UI. Proof
Three predefined scripts (Dev Server, Setup, Cleanup); dev server toggleable from the UI, but no user-defined arbitrary run configurations. |
| 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. | | 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). Proof
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. | 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. | 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). Proof
Slash commands surface user-defined LLM prompts (.cursor/commands/*.md). No documented button surface running shell commands. | | 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). Proof
No mechanism for multiple custom UI buttons running arbitrary shell commands or LLM prompts; only fixed lifecycle scripts and a reusable prompt menu exist. | | | | | | | | | | 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). Proof
Quick Commands = multiple saved shell commands, global or per-project, with an editable list. Meets the multi-action shell-command bar; no LLM-prompt action variant found, but not required. | Run config is a single editable run script (does not qualify). Review actions (Create PR, Inline commit, Fix CI…) are a fixed built-in set whose prompts/routing are configurable, not user-declared arbitrary multiple shell/LLM actions. | 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). Proof
Multiple terminal presets, each one or more shell commands, are pinned in the presets bar for one-click launch (declarable, multiple). Shell commands only; no LLM-prompt buttons found. | | 2Custom 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). Proof | 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). Proof
Slash commands are pass-through to the agent's native CLI (Claude Code/Codex/OpenCode), not vk-authored; the command bar is a fixed built-in set. No way to declare custom UI action buttons (shell commands or LLM prompts). |
| The orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". | No in-app commit surface; committing requires an external Git client or the terminal. | | | No in-app commit surface; committing goes through the Diff Viewer → PR flow or an external Git client. | No in-app commit surface; committing goes through the Diff Viewer → PR flow or an external Git client. | | | In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof
In-app commit with file staging selection plus a commit message and optional description. | | | | | | | | | | In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof
Built-in source control: commit without leaving Orca, with per-file/hunk staging, manual message field, and optional AI-drafted message. | In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof
An 'Inline commit' action exists as a configurable review action, but no file-staging checkboxes, commit-message field or AI-generated message are documented; review docs otherwise point to your normal git flow. | In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof
Built-in commit surface with per-file staging selection and a commit message field. No AI-generated message found, but staging + message are present (AI message is optional per criteria). | | 2In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof In-app commit interface with file selection and auto-generate message. | In-app commitThe orchestrator provides a built-in commit surface — file staging checkboxes, a commit message field, and optionally an AI-generated message — so the user can commit without leaving the ADE. "Partial" when file selection or message generation is missing. A simple "commit all" one-click with no staging control does NOT qualify as "yes". Proof
The git action registry exposes only PR, merge, rebase, push, change-target and link-pr — there is no commit/staging surface or commit-message field. The coding agent commits its own work. |
| Built-in UI to display agent-produced code changes directly in-app (file-by-file). | 1In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Desktop app diff viewer shows changes file by file before creating a pull request. | | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
In-thread diff view lets the user review the agent changes and comment before committing. | 1In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Built-in Diff Viewer renders agent-produced changes file by file, with inline comment and PR actions. | 1In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Built-in Diff Viewer renders agent-produced changes file by file, with inline comment and PR actions. | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
| No built-in diff UI; file edits land directly on disk subject to tool-call approval prompts. | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Built-in diff view with unified/split layouts to review agent changes. | | | | | | | | Red/green inline diffs with block-level approval. | Built-in tools to inspect diffs and track Git state for the worktree. | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Confirmed across docs (dedicated "Diff viewer" page, line-by-line AI diff review) and GitHub README ("Review AI-generated diffs without leaving Orca"). In-app, file-by-file. | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Built-in diff view for the active worktree showing changed files, diff contents and per-file status/stats. | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
Built-in diff viewer for reviewing agent changes file-by-file, with split (side-by-side) and unified (inline) views. | Shows file diffs and opens in a side panel (IDE Emulation). | 1In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof | In-app diff viewerBuilt-in UI to display agent-produced code changes directly in-app (file-by-file). Proof
|
| 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. | 1Diff: ignore-whitespace toggleToggle to hide or show whitespace-only changes in the diff viewer. Proof
Conductor 0.54 adds an ignore-whitespace toggle to the Diff Viewer so whitespace-only changes can be hidden or shown. | Diff: ignore-whitespace toggleToggle to hide or show whitespace-only changes in the diff viewer. Proof
Ignore-whitespace toggle was not supported before Conductor 0.54. | No ignore-whitespace toggle explicitly documented in the diffs view or PR review surface. | | Diff view documents unified/split layouts but no whitespace-only toggle is mentioned. | | | | | | | | | | Diff viewer exists but no ignore-whitespace toggle evidence found across docs index, changelog, GitHub README, and web search. | The diff view is documented (files changed, diff contents, per-file status), but no ignore-whitespace toggle or whitespace handling is mentioned. | Changelog mentions hiding unchanged lines (collapsing context) to improve readability, but no evidence of an ignore-whitespace toggle that hides whitespace-only changes specifically. | | 1Diff: ignore-whitespace toggleToggle to hide or show whitespace-only changes in the diff viewer. Proof | No reachable ignore-whitespace toggle in the 0.1.44 UI: none in the diff/changes view, and the command bar exposes no Diff Options entry. (An ignoreWhitespace flag exists in source but is not surfaced.) |
| 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. | Diff: multiple scopes / viewsBeyond 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. Proof
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. | | Diff covers PR reviewing and viewing multiple files; no documented selector to switch between per-commit / per-turn / branch-vs-target scopes. | 4Diff: multiple scopes / viewsBeyond 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. Proof
Diff Viewer offers several selectable scopes: branch vs. target, uncommitted changes, per-commit, and per-turn (changes produced by a single agent discussion). | 4Diff: multiple scopes / viewsBeyond 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. Proof
Diff Viewer offers several selectable scopes: branch vs. target, uncommitted changes, per-commit, and per-turn (changes produced by a single agent discussion). | Diff: multiple scopes / viewsBeyond 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. Proof
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. | | Diff: multiple scopes / viewsBeyond 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. Proof
Diff scope spans Changed (unstaged), Staged and PR comparisons, but these are read-only sections rather than a freely switchable per-commit/uncommitted/vs-target selector. | | | | | | | | | | Diff: multiple scopes / viewsBeyond 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. Proof
Doc describes default scope (start-from ref) plus switching to any commit, branch, or base ref from the diff toolbar — multiple scopes = yes. | Diff: multiple scopes / viewsBeyond 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. Proof
The diff is a single scope: the active worktree compared against its target branch. No selectable scopes (per-commit, uncommitted…) are described; changing comparison means changing the target branch itself. | Diff: multiple scopes / viewsBeyond 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. Proof
Diff scope can be switched across several views: all changes, uncommitted only, a single commit, or a commit range. | | DiffPanel exposes two scopes: the whole-thread cumulative diff and a per-turn diff selected via the turn strip; no per-commit or branch-vs-target selectors. | Diff: multiple scopes / viewsBeyond 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. Proof
The changes panel is fed by a single workspace-branch-vs-target diff stream (git/diff/ws); the only toggles are display modes (split/inline, ignore-whitespace, wrap), not scope selectors (per-commit, uncommitted-only). |
| 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. | Per-turn diff in chatFrom 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. Proof
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. | | | 1Per-turn diff in chatFrom 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. 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. | 1Per-turn diff in chatFrom 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. 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. | | | No documentation of showing the diff produced by an individual LLM chat turn. | | | | | | | | | | Per-turn diff in chatFrom 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. Proof
Diff viewer is worktree-cumulative against a start-from ref with commit/branch scoping, not per-turn. No evidence of a per-message diff footer or chat-message click-through to a turn-scoped diff. | Diff review is a single worktree-vs-target-branch aggregate, opened separately after the agent finishes. No per-LLM-turn diff footer or per-turn diff scope in chat is described. | Per-turn diff in chatFrom 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. Proof
From a chat agent edit you can jump directly to the changes pane to review the diff, but this is a click-through to the general changes pane rather than a per-turn-scoped diff or per-turn touched-file footer. | | 1Per-turn diff in chatFrom 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. Proof | Per-turn diff in chatFrom 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. Proof
Each chat turn renders its file edits inline as expandable diff entries (no manual commit), but there is no consolidated per-turn diff view: you scroll the whole conversation, and the click-through opens the global Changes panel (file-scoped, not turn-scoped). |
| Leave comments on the diff and reference them back in the LLM discussion. | 2Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Click any line in the desktop diff to add a comment; Claude reads the comments and revises. | | Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Users can comment on the diff inside the thread; comments are surfaced back to the agent. | 2Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Comments on changed lines are sent back to the agent as precise context. | 2Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Comments on changed lines are sent back to the agent as precise context. | Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Inline comments exist on the PR Review surface (synced with GitHub). The local diffs view itself does not document standalone in-app diff comments. | | Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Line comments can be added when reviewing code changes. | | | | | | | | | | Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Changelog v1.3.18. Docs nav also lists "Annotate AI Diff" and a "Review an AI diff line-by-line" recipe, corroborating the feature. | The diff view lists 'Review comments, when present' and review actions include 'Fix comments' (forge PR comments), but no flow for authoring comments on the in-app diff and referencing them back into the LLM discussion is documented. | A Review tab reads/filters/responds to GitHub PR review comments, and diff comments gained a copy action, but no evidence of leaving comments on the local diff and referencing them back into the LLM discussion. | | No comment/annotation surface on the diff panel found in the codebase. | Comments on diff panelLeave comments on the diff and reference them back in the LLM discussion. Proof
Inline comments collected and sent to the agent in the next message. |
| 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. | 1Inline user-question tools in chatModern 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. Proof The `AskUserQuestion` tool call is rendered inline in the Desktop chat as a structured dialog with multiple-choice options and a free-text fallback. | | Codex agents can pause for clarification, but no documented inline interactive rendering of user-question tools in the app chat surface. | 1Inline user-question tools in chatModern 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. Proof
Conductor renders Claude's AskUserQuestion tool calls as an interactive, keyboard-navigable UI inline in chat; supports multi-select questions. | 1Inline user-question tools in chatModern 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. Proof
Conductor renders Claude's AskUserQuestion tool calls as an interactive, keyboard-navigable UI inline in chat; supports multi-select questions. | 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. | Agents run through their own CLIs in a terminal/conversation; no documentation of rendering AskUserQuestion tool calls inline as structured UI. | | | | | | | | | The system intercepts MCP pending permissions and pending questions to expose them to the user. | Inline user-question tools in chatModern 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. Proof
Orca is terminal/TTY-based (Ghostty-class splits), so agents render their own question TUIs in-terminal; no orchestrator-level inline question surface found in docs/changelog/README. | Inline user-question tools in chatModern 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. Proof
Structured approval/input requests from providers are surfaced in chat and can be answered there, but docs don't describe rendering AskUserQuestion as a dedicated radio/multi-choice widget vs raw markdown. | Inline user-question tools in chatModern 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. Proof
Agent question prompts (ask_user/AskUserQuestion) render as an interactive surface with scrollable option buttons and status chips, not raw markdown. | | ClaudeAdapter detects AskUserQuestion tool calls and emits a user-input.requested runtime event; the composer renders a dedicated panel with keyboard-shortcut option selection. | Inline user-question tools in chatModern 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. Proof
Agent ask_user_question tool calls render as an interactive AskUserQuestionBanner — clickable single-select buttons, multi-select with a confirm button, and a free-text/"Other" answer — instead of raw markdown. |
| 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. | 1Rewind chat to a past messageNavigate 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. Proof 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. | | Rewind chat to a past messageNavigate 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. Proof
Resume/fork picker (introduced 2026-05-07) rewinds and forks conversation history; this is documented for the TUI — equivalent app surface not explicitly described. | 2Rewind chat to a past messageNavigate 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. 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). | 2Rewind chat to a past messageNavigate 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. 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). | | | No documentation of rewinding/forking from a past chat message; agent 'Resume' continues a prior session but is not message-level rewind. | | | | | | | | | | No evidence in Orca's own docs/changelog/GitHub of message-level rewind or filesystem rollback. Rewind hits in search belong to other tools (Claude Code, Codex). | Session-history docs cover restoring/reopening past sessions and a history picker, but describe no rewind to a past message that truncates/branches history, and no filesystem rollback; provider-owned history is not rewritten. | No mention of rewinding/forking a chat to a past message, or workspace filesystem rollback, across homepage, docs, and changelog entries including the April 20 chat UX overhaul. | | 1Rewind chat to a past messageNavigate 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. Proof | Rewind chat to a past messageNavigate 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. Proof
Editing a prior chat message re-runs from that point: later processes are deleted and (by default) the worktree is git-reset to that message, so both conversation history and filesystem state roll back. |
| Queue several user messages in the chat so they are sent or applied as a stacked sequence. | Chat message stackingQueue several user messages in the chat so they are sent or applied as a stacked sequence. Proof
Messages typed while Claude is mid-turn are queued and delivered at the next pause, so follow-ups stack without interrupting the running action. The queue flushes at the next LLM pause rather than strict end-of-turn. | | | Chat message stackingQueue several user messages in the chat so they are sent or applied as a stacked sequence. Proof
v0.54.0 redesigned the message queue from the ground up (queued messages can be deleted, sent or edited); v0.50.0 added ⌘⏎ to send with the opposite of your follow-up behavior (queue vs steer). | Chat message stackingQueue several user messages in the chat so they are sent or applied as a stacked sequence. Proof
v0.54.0 redesigned the message queue from the ground up (queued messages can be deleted, sent or edited); v0.50.0 added ⌘⏎ to send with the opposite of your follow-up behavior (queue vs steer). | | | No documentation of queuing multiple user messages. | | | | | | | | | | No evidence of chat message queuing/stacking. Orca passes through to CLI agents in terminals; any stacking would belong to the underlying CLI, not Orca itself. | No documentation of queuing/stacking multiple user messages to be sent as a sequence. | No evidence of queuing/stacking multiple user chat messages while the agent is mid-turn. The only queue reference is for automation runs, not chat. | | Chat message stackingQueue several user messages in the chat so they are sent or applied as a stacked sequence. Proof
The composer has no message queue: while a session is running the send button is replaced by a stop/interrupt button (and a spinner while sending), so follow-ups cannot be stacked mid-turn. | Chat message stackingQueue several user messages in the chat so they are sent or applied as a stacked sequence. Proof
Partial: only one follow-up can be queued (queue-of-one — QueueStatus is empty|queued, one queued message per session; re-queue overwrites). The queued message is consumed at run finalization, i.e. sent only after the current turn ends — not injected mid-turn. |
| Dictate prompts or chat messages directly inside the ADE. | 1In-app voice inputDictate prompts or chat messages directly inside the ADE. Proof A microphone button sits in the Code-tab composer toolbar (next to the permission-mode and add buttons) for dictating prompts, including in local sessions. | | | 1In-app voice inputDictate prompts or chat messages directly inside the ADE. Proof A microphone button is present in the chat composer toolbar (next to the add and send buttons) for dictating prompts. Not mentioned in the changelog but present in-app. | 1In-app voice inputDictate prompts or chat messages directly inside the ADE. Proof A microphone button is present in the chat composer toolbar (next to the add and send buttons) for dictating prompts. Not mentioned in the changelog but present in-app. | | | In-app voice inputDictate prompts or chat messages directly inside the ADE. Proof
No mention of voice/dictation anywhere in docs, README, or changelog. | | | | | | | | | | Searched docs, homepage, changelog, and GitHub repo; none reference voice/dictation/microphone/speech-to-text. Orca centers on terminal-based CLI agents. | No mention of voice input, dictation, microphone or speech anywhere in the docs. Input is via typed prompts, @-mentions, paste and file attachment. | No mention of voice input or dictation in homepage, docs, or changelog. Chat prompt is a rich-text editor with slash/file chips; no speech-to-text feature described. | | In-app voice inputDictate prompts or chat messages directly inside the ADE. Proof
The web composer accepts only text, slash commands, @-mentions and image attachments — paste and drag-and-drop are guarded to image MIME types only. No voice, microphone, dictation or speech-to-text input exists in the codebase. | No getUserMedia / MediaRecorder / SpeechRecognition usage, mic icon or dictation code anywhere in packages/ui or packages/web-core. |
| 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. | 1Repo-less quick chatA 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. Proof
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. | | All Codex App threads are anchored to a project; a repo-less chat surface is not documented. | Repo-less quick chatA 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. Proof
Chats live inside a workspace, which requires a repository. | Repo-less quick chatA 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. Proof
Chats live inside a workspace, which requires a repository. | Repo-less quick chatA 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. Proof
Agents Window is workspace-scoped; community has open feature requests for empty / repo-less chats. | Repo-less quick chatA 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. Proof
A one-shot prompt can be piped to any agent file without attaching the session to a repository. | Repo-less quick chatA 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. Proof
All agent interaction requires creating a task targeting a project/repo; no repo-less quick chat is documented. | | | | | | | | | | Repo-less quick chatA 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. Proof
Docs, homepage, changelog and README frame every agent session as bound to a git worktree. No evidence of an ad-hoc, repo-less chat surface. | Repo-less quick chatA 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. Proof
Every chat session is bound to a project or worktree. No repo-less/ad-hoc quick chat surface is described. | No evidence of repo-less/standalone chat detached from a repository or worktree. Superset is built around git-worktree workspaces; chat appears tied to workspaces, but no explicit confirmation either way. | | chat.newLocal still attaches the thread to the active project; no repo-less chat surface documented. | Repo-less quick chatA 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. Proof
Chat lives inside the conversation panel of a workspace, which requires a project / repository. |
| 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. | 1Embedded web previewIn-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. Proof
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. | | Embedded web previewIn-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. Proof
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. | 1Embedded web previewIn-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. 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). | 1Embedded web previewIn-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. 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). | Embedded web previewIn-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. Proof
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. | | Embedded web previewIn-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. Proof
No embedded browser/web preview; 'preview' in docs refers to terminal-font and image-diff previews. Run-script dev servers output to the terminal drawer. | | | | | | | | | | Embedded web previewIn-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. Proof
Design Mode: embedded Chromium per worktree, dockable in split panes; each task gets its own browser tab. Meets the "yes" bar (embedded preview integrated with the ADE workflow). | Run/preview servers start as terminal/run processes; the only 'Preview File' action is a terminal context-menu file preview. No embedded in-app web preview pane rendering a local HTTP server is documented. | Embedded web previewIn-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. Proof
Embedded in-app browser integrated with the workflow: previews dev servers via detected ports (open in a browser pane), with address bar, history, and DevTools. | | No embedded web preview / iframe browser component found. | Embedded web previewIn-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. Proof
Built-in preview browser tied to the dev server script configured per repository. |
| Annotate regions of the embedded web preview and feed that visual feedback back into the discussion. | 3Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
The embedded preview pane has an "Annotate preview" mode: a drawing toolbar (freehand, line, rectangle, ellipse, text, colour palette) to mark regions over the rendered app, then an "Add to chat" button feeds the annotated screenshot back into the discussion. | | | Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
v0.55.0 added "HTML previews", which render HTML/markdown artifacts (and plan/summary previews) rather than an interactive embedded dev-server browser. No annotatable web preview is documented. | Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
v0.55.0 added "HTML previews", which render HTML/markdown artifacts (and plan/summary previews) rather than an interactive embedded dev-server browser. No annotatable web preview is documented. | | | No web preview exists, so no annotation of preview regions. | | | | | | | | | | Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
Design Mode: click a UI element in the live preview to send its HTML/CSS/cropped screenshot to the agent. Element-pick rather than free-form annotation, but the mark-and-send-back loop is present. | No embedded web preview is documented, so annotation of preview regions fed back into discussion is not covered. | The browser docs and Feb 16 changelog describe the embedded browser, DevTools, and history but make no mention of annotating regions of the preview or feeding visual feedback into the discussion. | | Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
T3 Code has no embedded web preview pane — its UI is chat, terminal, git/worktree and diff viewer only — so there is no preview to annotate. | Web preview annotationAnnotate regions of the embedded web preview and feed that visual feedback back into the discussion. Proof
The embedded preview supports element inspection and Eruda DevTools, but there is no region/freehand annotation tool; the only "feed to chat" path is click-to-component element selection (tracked by web-preview-element-inspector). |
| Inspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. | 3Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
The preview pane has a "Select an element" action (Cmd+Shift+S): hovering shows an inspector overlay (selector, dimensions, accessibility role) and selecting attaches the DOM node as a context chip in the chat composer. Claude also inspects the DOM during auto-verify. | | | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
The "HTML previews" feature renders artifacts, not a live interactive browser; no DOM element inspector/selector is documented. | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
The "HTML previews" feature renders artifacts, not a live interactive browser; no DOM element inspector/selector is documented. | | | No web preview exists, so no DOM element inspector. | | | | | | | | | | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
Design Mode is a pointer-to-code inspector in the embedded browser: clicking an element captures its HTML/CSS/screenshot (and source file/line via dev source maps) and sends it to the agent. | No embedded web preview is documented, so DOM element inspection/selection within a preview is not covered. | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
Embedded browser exposes a DevTools pane to inspect/debug the page, and the agent (via MCP) can inspect the DOM. But no user-facing element-picker that feeds a selected DOM node into the chat discussion is documented. | | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
T3 Code has no embedded web preview pane — its UI is chat, terminal, git/worktree and diff viewer only — so there is no preview in which to inspect DOM elements. | Web preview element inspectorInspect or select DOM elements in the embedded web preview so the discussion can target exact UI nodes. Proof
The embedded PreviewBrowser iframe has an inspect toggle ("Select element as context"): toggling posts click-to-component to the iframe, and a selected element is injected into the chat as a vk-component markdown block. |
| Integrations 7 features | 5 1 / 7 | 1 0 / 7 | 1 4 / 7 | 5 2 / 7 | 5 2 / 7 | 4 2 / 7 | 1 0 / 7 | 4 1 / 7 | 1 0 / 7 | 1 0 / 7 | 2 0 / 7 | 1 0 / 7 | 1 0 / 7 | 1 0 / 7 | 1 0 / 7 | 1 0 / 7 | 2 0 / 7 | 1 2 / 7 | 6 1 / 7 | 3 3 / 7 | 0 0 / 7 | 5 1 / 7 | 5 2 / 7 |
| 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. | 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. Proof
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. | Supports Claude Code, Codex, Grok, OpenCode, Pi, Amp, Cursor CLI, Gemini, Copilot, etc. | 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. Proof
Single vendor: OpenAI models only (GPT-5.5 default, GPT-5.4 with reasoning levels). No third-party model families; ChatGPT login required. | 1Multiple 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. 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". | 1Multiple 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. 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". | 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. Proof
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). | 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. Proof
BYOK across multiple vendors: OpenAI, Anthropic, Gemini, AWS Bedrock, Mistral, xAI, Docker Model Runner, and more — direct provider SDKs. | 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. Proof
Provider-agnostic: 28 CLI agents spanning Anthropic (Claude Code), OpenAI (Codex), Google (Gemini), and many others; model choice is per-CLI. | 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. | 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. Proof
Homepage and README list multi-vendor agents (Claude Code/Anthropic, Codex/OpenAI, Gemini/Google, Grok/xAI, Copilot/GitHub) plus "any CLI agent". Clear multi-vendor support. | 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. Proof
Drives CLIs from several distinct vendors: Claude Code (Anthropic), Codex (OpenAI), Gemini CLI (Google), Grok (xAI), plus others — far beyond the two-vendor partial threshold. | 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. Proof
Agent-agnostic: drives external CLI agents from multiple vendors (Claude Code/Anthropic, Codex/OpenAI, Gemini/Google, Cursor, Copilot, OpenCode). A multi-provider model picker also spans providers. | Exclusively a front-end for Claude Code CLI sessions. | 1Multiple 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. Proof | 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. 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. |
| Tune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). | 1Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
Effort menu reachable via Cmd+Shift+E lets the user pick adaptive reasoning levels (`low`, `medium`, `high`, `xhigh`, `max`). | | Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
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. | 1Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
Fast Mode + reasoning-effort levels exposed when the model supports it. | 1Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
Fast Mode + reasoning-effort levels exposed when the model supports it. | Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
Reasoning effort variants exposed for OpenAI models (e.g. gpt-5-high, gpt-5.2-high) and Max Mode for Anthropic / Gemini. | | Emdash launches external agent CLIs; no in-app reasoning/thinking-effort control is documented (such settings would live inside each CLI). | | | | | | | | | | Docs, changelog, and README contain no reference to reasoning effort, thinking budget, or extended thinking. Orca wraps CLI agents rather than exposing model params directly. | Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
Reasoning levels are selectable per provider when supported, in settings and via CLI (sc chat new --reasoning medium). | No mention of reasoning/thinking effort control across homepage, docs, or changelog. Underlying CLI agents may expose it, but Superset surfaces no such control. | | 1Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof | Reasoning effort controlTune reasoning/thinking effort for models that expose it (e.g. Anthropic extended thinking). Proof
reasoning_effort exposed for Codex (low/medium/high) and Droid (off/low/medium/high) agent configurations. |
| 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. | 1Switch model mid-sessionPick 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. Proof
Model dropdown next to the send button (Cmd+Shift+I) swaps the Anthropic model mid-session; the selection persists. | | 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. | 1Switch model mid-sessionPick 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. Proof
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. | 1Switch model mid-sessionPick 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. Proof
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. | Each tab carries its own model selection; documentation does not explicitly confirm mid-conversation switch on the same tab. | Switch model mid-sessionPick 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. Proof
The model is pinned in the agent YAML config; switching requires editing the file and re-running. | Switch model mid-sessionPick 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. Proof
Provider is chosen at task creation; resume continues with the same provider, and no mid-session model/provider switch is documented. | | | | | | | | | | Orca delegates to host CLI agents in their own terminals; no Orca-native model selector documented. Changelog only covers account switching, not models. | Switch model mid-sessionPick 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. Proof
Live chat sessions receive model/reasoning changes directly when the provider supports mid-session updates; otherwise the change applies to future sessions. | Switch model mid-sessionPick 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. Proof
A multi-provider model picker lets you choose between providers and models, and Superset lets you switch between agents seamlessly. No explicit confirmation of changing the model mid-conversation within a running session. | | 2Switch model mid-sessionPick 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. Proof Models can be switched mid-thread, but only within the same vendor; switching to a different vendor's model requires starting a new thread. | Switch model mid-sessionPick 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. 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. |
| 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. | 1Open in IDE / external appLaunch 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. Proof
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. | | Open in IDE / external appLaunch 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. Proof
Codex IDE Extension syncs context with the app (Auto Context); no documented "Open in <editor>" picker for arbitrary external apps. | 1Open in IDE / external appLaunch 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. 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. | 1Open in IDE / external appLaunch 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. 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. | Open in IDE / external appLaunch 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. Proof
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. | | Open in IDE / external appLaunch 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. Proof
Open In supports many editors/terminals (VSCodium, Xcode, Windsurf, RubyMine, Android Studio, Kitty, Alacritty…), but no documented custom-app definition. | | | | | | | | | | Docs, homepage, changelog and README show no "Open in editor/IDE" launcher or custom external-app configuration. Orca positions itself as the IDE; worktrees are real git dirs you can cd into manually. | Open in IDE / external appLaunch 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. Proof
Opens the active worktree in a broad set of built-in detected macOS apps (VS Code, Cursor, Zed, Xcode, JetBrains IDEs, terminals, Finder). Detection-based; arbitrary custom-app configuration is not documented. | Open in IDE / external appLaunch 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. Proof
One-click open of the worktree in a configurable external editor (VS Code, Cursor, Xcode, JetBrains IDEs, or any terminal). | | 1Open in IDE / external appLaunch 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. Proof | Open in IDE / external appLaunch 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. Proof
VS Code, Cursor, Windsurf, Zed, Antigravity, Neovim, Emacs, Sublime Text, plus custom editor command. |
| The agent opens a GitHub/GitLab PR when a task completes. | 3Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
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. | | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
Built-in review pane stages files, commits and pushes; PR creation and PR-feedback addressing are first-class. | 2Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. 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). | 2Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. 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). | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
| No built-in GitHub/GitLab PR action; an agent could shell out to `gh`, but nothing is shipped. | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
Create/publish a PR (including draft) from the diff/changes panel, e.g. Commit & Create PR. | | | 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). | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
In-app PR creation tied to each worktree, but framed as a manual user-initiated UI action. No evidence the agent automatically opens a PR on task completion. | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
PR creation is a first-class forge-aware action (GitHub/GitLab via local gh/glab CLI) exposed as a configurable 'Create PR' action prompt rather than fully unattended on task completion. | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
Integrated PR workflow (merge button, PR status, gh CLI builds compare URLs and checks for an existing PR before creating). Whether the agent auto-opens a PR on task completion is not clearly documented. | | 2Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof | Automatic PR creationThe agent opens a GitHub/GitLab PR when a task completes. Proof
|
| Track linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. | 2GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
Desktop CI status bar tracks PR checks; auto-archive setting closes the session when the PR merges or closes. | | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
App reviews PRs and addresses feedback inline; no documented auto-archive of the thread/worktree when the PR merges. | 4GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. 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). | 4GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. 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). | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
PR Review surfaces PR state and allows merge from inside Cursor; no documented auto-archival of the worktree on merge. | | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
Syncs PR state including merge state and auto-detects open PRs for a worktree, but no documented auto-archive of the worktree on merge. | | | Agent Merge addresses review comments. | | | | | | | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
PRs/checks linked per worktree; homepage adds "review and approve PRs". No evidence of merge detection, merging from the ADE, or auto-archive on merge. | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
PR/MR state (draft/open/merged/closed) and mergeability is tracked and polled, and manual merge is supported. But worktree removal after merge is a manual cleanup step, not documented as automatic auto-archive on merge. | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
Linked PR state is tracked and shown (color-coded icon/number in Changes view, links to GitHub) and a merge button allows manual merge. No evidence of automatic worktree archive on merge. | | 2GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof | GitHub PR status sync & auto-closeTrack linked PR state, detect merge, allow manual merge, auto-archive the worktree on merge. Proof
PR-status badge on the workspace sidebar; no auto-archive on merge documented (archive is manual). |
| 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. | 1One-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. Proof GitHub PR review comments are synced and displayed inline in the Desktop diff viewer alongside the code changes. | | 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. Proof
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. | 1One-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. Proof
One-way: GitHub review comments are surfaced in Conductor and resolving them updates the Checks tab. | 1One-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. Proof
One-way: GitHub review comments are surfaced in Conductor and resolving them updates the Checks tab. | 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. Proof
PR Review experience reads GitHub review threads inside Cursor (one-way ingestion fully covered; bidirectional sync also documented but not required by this row). | | 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. Proof
GitHub PR comments are pulled in and shown in the diff/checks panel alongside CI status. | | | | | | | | | | Sources only mention writing in-app diff comments to send to the agent (Annotate AI Diff) plus browsing PRs/issues. None confirm ingesting reviewer PR comments into the diff panel. | 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. Proof
PR review comments are pulled into the in-app diff/review surface (one-way), and GitHub unresolved review-thread counts surface alongside the worktree. | 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. Proof
A dedicated Review tab in the changes sidebar surfaces PR review comments in-app (read/filter/respond — exceeds the one-way scope, but ingestion is present). | | Source-control docs cover PR creation and listing, not comment sync. | 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. Proof
One-way PR→in-app ingestion fully works: when the workspace is linked to a PR, submitted review comments appear inline in the Changes panel (per-file count badge), toggled via the GitHub icon in the toolbar. The reverse direction is out of scope for this row. |
| Observability 4 features | 2 0 / 4 | 0 0 / 4 | 1 0 / 4 | 4 0 / 4 | 4 0 / 4 | 2 1 / 4 | 1 0 / 4 | 2 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 0 0 / 4 | 2 0 / 4 | 2 1 / 4 | 0 3 / 4 | 0 0 / 4 | 2 0 / 4 | 3 0 / 4 |
| Streaming logs/output for each agent in real time. | 1Live logsStreaming logs/output for each agent in real time. Proof
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>/`. | | Live logsStreaming logs/output for each agent in real time. Proof
Each thread streams the agent output in real time, including tool calls and terminal commands. | Live logsStreaming logs/output for each agent in real time. Proof
| Live logsStreaming logs/output for each agent in real time. Proof
| Live logsStreaming logs/output for each agent in real time. Proof
| Live logsStreaming logs/output for each agent in real time. Proof
Streaming agent output rendered in the built-in TUI. | Live logsStreaming logs/output for each agent in real time. Proof
Agent output and run/setup script logs stream live into the terminal drawer. | | | | | | | | | | Live logsStreaming logs/output for each agent in real time. Proof
Each agent runs in its own live terminal (panes/tabs/search) streaming the CLI agent's output in real time, with at-a-glance active-state visibility. | Live logsStreaming logs/output for each agent in real time. Proof
Terminal-backed agents run as local processes in the GPU terminal with scrollback, streaming their stdout live; chat sessions also stream via sc chat send --watch and sc chat events. | Live logsStreaming logs/output for each agent in real time. Proof
Chat UI streams agent messages and tool I/O in real time (progressive typing, collapsible tool output panels) and auto-scrolls live, but there is no dedicated raw log/tail view. | | Provider runtime events stream from codex app-server to the browser via ordered WebSocket pushes. | Live logsStreaming logs/output for each agent in real time. Proof
|
| Visualize the current context window fill ratio in the ongoing discussion. | 1Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
Prompt box shows context-window usage; `/compact` and auto-compaction kick in when full. | | Remote compaction and `/compact`-style flows exist in the CLI; an explicit context-window indicator in the app UI is not documented. | 1Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
| 1Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
| Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
"Context ring" with click-through breakdown across rules / skills / MCPs / subagents (since 3.3). | | No documentation of a context-window fill indicator (would live in the underlying agent CLI). | | | | | | | | | | Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
"Usage status bar" tracks API consumption + rate-limit resets, not context-window fill of the current discussion. No context/token/compaction indicator found. | Docs mention a structured 'usage' event in the sc chat events automation stream, but no UI element visualizing context-window fill ratio in the ongoing chat is documented. | No mention of a context-window fill ratio, token usage, or context indicator in the homepage, docs overview, or changelog. | | 1Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof | Context usage indicatorVisualize the current context window fill ratio in the ongoing discussion. Proof
|
| Configure sound alerts for key agent events (idle, awaiting input, task done…). | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
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. | | No mention of configurable sound alerts in public docs; OS-level notifications exist (e.g. action-required terminal titles in the CLI). | 1Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Multiple themed completion sounds (SNCF jingle, Paris Métro chime, SF Muni, NYC MTA…) selectable from General settings with a Test button. | 1Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Multiple themed completion sounds (SNCF jingle, Paris Métro chime, SF Muni, NYC MTA…) selectable from General settings with a Test button. | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Sound played when an agent finishes; configuration is binary (on/off), not per-event. Custom audio achievable via plugin hooks. | | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Configurable notification sound setting, including a custom sound. | | | | | | | | | | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Per-category sound config (built-in or custom audio file) with volume control; agent-finished idle transition fires system notification + sound + chip. | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Agent lifecycle events (idle, working, ready-for-review, waiting for permission/input, completion) produce notifications, and app-level settings expose sounds. | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
Settings include a notification sound volume dropdown, so sound alerts exist and volume is configurable. No evidence of configuring distinct sounds per event type (idle/awaiting input/done). | | No audio/sound notification system found in the codebase or docs. | Configurable sound notificationsConfigure sound alerts for key agent events (idle, awaiting input, task done…). Proof
|
| Expose a frictionless way to extract a complete, machine-readable transcript of a discussion — including user messages, assistant turns, tool calls and their results — through a copy/export action, a file on disk, or a dedicated API. Useful to fork the conversation in another tool, run meta analyses on agent behavior, identify recurring failure modes, or build prompts/skills from past sessions. "Partial" when only the visible chat text can be copied piecemeal; "yes" when a structured export covering the full session (including tool I/O) is available. | No desktop-specific transcript export. The /export command and the JSONL session files under ~/.claude/projects belong to the Claude Code CLI substrate (available to any ADE wrapping it), not a capability owned by the desktop app. | | | 1Chat transcript exportExpose a frictionless way to extract a complete, machine-readable transcript of a discussion — including user messages, assistant turns, tool calls and their results — through a copy/export action, a file on disk, or a dedicated API. Useful to fork the conversation in another tool, run meta analyses on agent behavior, identify recurring failure modes, or build prompts/skills from past sessions. "Partial" when only the visible chat text can be copied piecemeal; "yes" when a structured export covering the full session (including tool I/O) is available. Proof
Right-click a chat to copy it as markdown (⌘⌥C). Past chat transcripts can also be attached to a new chat as a "Transcript of <name>.md" file, letting you fork or analyse a previous session. | 1Chat transcript exportExpose a frictionless way to extract a complete, machine-readable transcript of a discussion — including user messages, assistant turns, tool calls and their results — through a copy/export action, a file on disk, or a dedicated API. Useful to fork the conversation in another tool, run meta analyses on agent behavior, identify recurring failure modes, or build prompts/skills from past sessions. "Partial" when only the visible chat text can be copied piecemeal; "yes" when a structured export covering the full session (including tool I/O) is available. Proof
Right-click a chat to copy it as markdown (⌘⌥C). Past chat transcripts can also be attached to a new chat as a "Transcript of <name>.md" file, letting you fork or analyse a previous session. | | | No documented export of a structured chat transcript (including tool I/O). | | | | | | | | | | No evidence of structured transcript export across docs, changelog, README, releases. Terminal-based agents leave text copyable but no deliberate export feature is documented. | Chat transcript exportExpose a frictionless way to extract a complete, machine-readable transcript of a discussion — including user messages, assistant turns, tool calls and their results — through a copy/export action, a file on disk, or a dedicated API. Useful to fork the conversation in another tool, run meta analyses on agent behavior, identify recurring failure modes, or build prompts/skills from past sessions. "Partial" when only the visible chat text can be copied piecemeal; "yes" when a structured export covering the full session (including tool I/O) is available. Proof
sc chat events emits structured events incl. messages and tool activity, and the terminal supports output selection/copy. But this is a live, in-memory, process-local event stream — not a documented complete full-session structured export-to-file. | Chat transcript exportExpose a frictionless way to extract a complete, machine-readable transcript of a discussion — including user messages, assistant turns, tool calls and their results — through a copy/export action, a file on disk, or a dedicated API. Useful to fork the conversation in another tool, run meta analyses on agent behavior, identify recurring failure modes, or build prompts/skills from past sessions. "Partial" when only the visible chat text can be copied piecemeal; "yes" when a structured export covering the full session (including tool I/O) is available. Proof
Only piecemeal copying surfaced: expand/collapse and copy on every code block for tool output. No structured full-session export including all tool I/O found in docs/changelog. | | No chat export or transcript download feature found. | No full-session transcript export. Only a per-process "Copy Raw Logs" action (Y L) copying the current Logs panel of a single process/tool. The cloud "Export" covers project/issue data, not the agent conversation. |
| Collaboration 3 features | 0 1 / 3 | 0 0 / 3 | 1 1 / 3 | 1 0 / 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 | 1 0 / 3 | 1 0 / 3 | 0 1 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 |
| 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 documentation of sharing planning artifacts remotely for async review. | | | | | | | | | | Remote plan collaborationA 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. Proof
Mobile app is a "read-mostly view of running agents" for the owner only. Diff comments feed the agent, not a shared review surface. No share-link/async-review/annotation-for-teammates feature found. | Remote plan collaborationA 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. Proof
Superconductor is a single-user, local-first macOS app; plans are local session artifacts. No surface publishes/shares a plan or session for remote teammate review/annotation. Collaboration happens only via git forges (PRs). | No planning artifacts or remote plan review/annotation feature found. Plan/planning-mode searches returned only chat tool-call rendering, not shareable plan collaboration. | | No external plan-collaboration feature documented. | No remote plan-collaboration feature documented. |
| 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. | Shared configuration with teammatesAs 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. Proof
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. | | Shared configuration with teammatesAs 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. 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. | 2Shared configuration with teammatesAs 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. 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. | 2Shared configuration with teammatesAs 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. 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. | Shared configuration with teammatesAs 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. Proof
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. | Shared configuration with teammatesAs 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. 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. | Shared configuration with teammatesAs 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. Proof
Preserve patterns, shell setup and lifecycle scripts can be committed to .emdash.json and shared with teammates. | | | | | | | | | | Shared configuration with teammatesAs 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. Proof
Skills registry installable from internal/company repos = teammate-shareable config/capabilities. Per-repo overrides (hooks, auto-run) corroborate. No committed orca.yaml quote, hence medium confidence. | Shared configuration with teammatesAs 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. Proof
Repository-owned setup/run/teardown scripts live in a committed .superconductor/config.json at the project root, so the config ships with the repo to all teammates. No org-tier/registry, but a committed config file satisfies the threshold. | Shared configuration with teammatesAs 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. Proof
Project-level presets/config are scoped to a project; the Slack bot pulls from the team's Linear/Superset setup, implying org/team-shared context. No explicit committed-config-file or registry mechanism confirmed. | | No dedicated feature to package or share T3 Code configuration with teammates (no shareable config bundle, registry or marketplace). | No way to share the tool configuration with teammates: settings are per-machine/per-user and there is no committed, project-level config file (hooks, scripts, custom actions) that teammates can pick up from the repo. |
| 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. | | Share discussion workflows with teammatesDistribute 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. Proof
Plugins and skills can be shared via workspace sharing, share-access controls, and the plugin marketplace; not a dedicated "workflow registry". | No discussion-workflow authoring, so no sharing surface. | No discussion-workflow authoring, so no sharing surface. | | | Share discussion workflows with teammatesDistribute 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. Proof
No custom discussion workflows to share; shareable config is limited to scripts/preserve-patterns/shell-setup in .emdash.json. | | | | | | | | | | No "discussion workflow" concept or workflow-sharing (export/import/registry/git-tracked) feature found. Team features are limited to PR review, Linear issues, and the companion app. | Docs cover sharing committed setup/run/teardown scripts and CLI automation recipes, but never an authored 'discussion workflow'/playbook concept, nor an in-app registry or import/export for distributing such playbooks to teammates. | Presets and slash-commands exist, but no evidence of distributing/importing-exporting authored discussion workflows to teammates via shared repo or registry. | | No discussion-workflow concept to share. | No discussion-workflow concept to share. |
| Platform 3 features | 1 0 / 3 | 0 0 / 3 | 2 1 / 3 | 0 0 / 3 | 0 0 / 3 | 3 0 / 3 | 1 0 / 3 | 1 1 / 3 | 2 0 / 3 | 0 0 / 3 | 0 0 / 3 | 0 0 / 3 | 1 0 / 3 | 2 0 / 3 | 2 0 / 3 | 1 0 / 3 | 1 0 / 3 | 2 0 / 3 | 0 0 / 3 | 2 0 / 3 | 0 0 / 3 | 2 0 / 3 | 1 0 / 3 |
| The orchestrator runs agents in a remote environment, not locally. | 1Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
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. | | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
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. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. 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. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. 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. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
| Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
Executes locally as a CLI / standalone binary; no managed cloud runtime is offered. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
Agents can run on remote machines over SSH (Remote Projects) or in per-task provisioned remote workspaces (Remote Tasks). | 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. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
Remote execution is SSH-based to machines you own (not a managed cloud), but agents clearly run off the local machine, satisfying the feature. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
Docs repeatedly state agents run as local processes on the user's Mac, not in any remote environment. No remote execution is offered. | Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof
Workspaces can run on a remote Superset device (beefier box, cloud VM, teammate's host); the host-service can also run on a remote server/CI/cloud VM via the CLI tarball without the desktop app. | Local desktop application. | 2Remote agent executionThe orchestrator runs agents in a remote environment, not locally. Proof Remote environments can be paired (one-time link or SSH) so the orchestrator drives agents on another host rather than the local machine. | |
| 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. | | Plugin systemExtend the orchestrator with third-party or user-authored plugins. Proof
First-class plugin system: 90+ plugins (Atlassian Rovo, CircleCI, CodeRabbit, GitLab, Microsoft Suite, Neon, Render…), plus skills and MCP servers, distributed via a marketplace. | No plugin / extension mechanism documented. | No plugin / extension mechanism documented. | Plugin systemExtend the orchestrator with third-party or user-authored plugins. Proof
Marketplace bundling rules, skills, agents, commands, MCP servers and hooks. /add-plugin from the editor. | Plugin systemExtend the orchestrator with third-party or user-authored plugins. Proof
External tools are added by wiring MCP servers (local, remote or Docker-based) into the agent YAML. | Plugin systemExtend the orchestrator with third-party or user-authored plugins. Proof
No third-party app-plugin API, but agents are extensible via a Library of MCP servers and Agent Skills (incl. custom skills) synced into agent configs. | | | | | 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 plugin system found. Extensibility is limited to adding arbitrary CLI agents and agent-level MCP/skills, not an addressable orchestrator plugin/extension API. | No documentation of a plugin/extension system for third-party or user-authored plugins. The docs describe provider adapters and an sc CLI/local API for automation, but no user-authorable plugin mechanism. | There are integrations (Linear, MCP Server, hooks) and presets, but no evidence of a third-party/user-authored plugin extension system. MCP support exists but is not clearly a plugin framework. | | No third-party plugin/extension API for the orchestrator itself. Forking the repo is the documented extensibility path. | No plugin / extension mechanism documented. |
| 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. | | Remote ADE controlRemote 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. Proof
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. | No mobile / remote-access surface documented; Conductor is a local macOS app. | No mobile / remote-access surface documented; Conductor is a local macOS app. | Remote ADE controlRemote 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. Proof
Cursor exposes its Cloud Agent ADE surface from web, iOS PWA, Slack, GitHub, Linear, and API, so sessions can be started and managed remotely. | Remote ADE controlRemote 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. 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. | Remote ADE controlRemote 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. Proof
The Emdash UI runs locally; no documented way to drive the ADE itself from another device such as a phone (remote refers to where agents run, not controlling the UI remotely). | Works across Web, Slack/Teams, Linear/Jira and Mobile. | | | | | | Mobile responsive UI via server mode. | | | Remote ADE controlRemote 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. Proof
Mobile companion is a true remote control of the ADE (worktrees, sessions, prompts, approvals/replies, push notifications), not just an embedded agent's surface. | Remote ADE controlRemote 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. Proof
The local API binds to the user account via a local Unix socket and requires the app running on the same Mac; it is not a remote surface. No phone/cross-device control of the ADE is documented. | Remote ADE controlRemote 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. Proof
The Slack bot acts as an agent that can create tasks, spin up cloud workspaces, and launch coding agents from Slack on any device — driving the ADE remotely, beyond an embedded coding agent. | | 4Remote ADE controlRemote 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. Proof Another device (mobile or desktop) pairs with the local backend over a one-time link or QR code and then drives the ADE; paired clients are listed and individually revocable. | Remote ADE controlRemote 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. Proof
Remote Access (Settings → Remote Access, paired via cloud.vibekanban.com) lets you drive a locally-running host from another device — prompt/control agents on your Mac from your phone. Opt-in: requires pairing, so an unconfigured instance looks non-controllable. |
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
-
Emdash
- Docs Emdash documentation
- Changelog Emdash changelog Lags slightly behind GitHub Releases (site changelog newest entry trailed the latest tag at research time).
- Blog Emdash blog
- RSS feed Emdash blog RSS feed
- GitHub releases generalaction/emdash GitHub releases Authoritative source for the latest version — ahead of the website changelog.
- GitHub commits generalaction/emdash commits (main)
- RSS feed GitHub releases Atom feed
- Twitter / X X / @emdashsh Correct handle is 'emdashsh'; 'x.com/emdash' is an unrelated account.
- Discord Emdash Discord
- Other Show HN: Emdash announcement thread
- Other Y Combinator company page (W26)
-
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)
-
Orca
- Docs Orca documentation Install + per-agent setup (Claude Code, Codex, Cursor CLI…).
- Changelog Orca changelog Web changelog lags GitHub releases (trailed at 1.3.41 at research time).
- GitHub releases stablyai/orca GitHub releases Authoritative source for the latest version — ahead of the website changelog.
- GitHub commits stablyai/orca commits (main)
- RSS feed GitHub releases Atom feed
- RSS feed GitHub commits Atom feed
- Twitter / X X / @orca_build
- Discord Orca Discord
- Other stablyai/orca repository
- Other Stably (vendor site)
-
Superconductor
- Other Superconductor homepage
- Docs Superconductor documentation (Astro Starlight)
- Discord Superconductor community Discord
- Twitter / X X / @superdoteng Official handle is 'superdoteng' (display name super.engineering). 'x.com/_Superconductor' is an unrelated account.
-
Superset
- Other Superset homepage
- Docs Superset documentation
- Changelog Superset changelog
- Blog Superset blog
- GitHub releases Superset GitHub releases
- GitHub commits superset-sh/superset repository
- RSS feed GitHub releases Atom feed Most reliable automatable release-tracking source; no first-party RSS feed found.
- Discord Superset Discord
- Twitter / X X @superset_sh
- YouTube YouTube @superset-sh
-
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
- Docs t3code DeepWiki
-
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.