Definitions
What each feature means
Every tool records the same 20 features. A flag is
yes, no, or
not verified yet — and some questions do not apply to
every kind of tool, shown as a dash.
✓ yes ✗ no ? not verified yet – does not apply
A feature is credited to the layer that provides or surfaces
it. An orchestrator does not inherit a harness's capability
merely because it can run that harness: it earns the flag only when it
provides the capability itself, manages it, or makes it work uniformly
across the harnesses it drives.
Values must be backed by an official source listed on the tool page.
Unchecked stays unknown rather than being guessed.
Compare tools in the matrix or read the
full JSON data.
Agents
Multi-provider multiProvider
Runs agents from several providers side by side?
- Yes if
- the product has first-class, documented support for at least two distinct agent runtimes or model vendors, selectable per session/thread. For an orchestrator: it can drive two or more different harnesses (Claude Code, Codex, Cursor, OpenCode, Gemini CLI, Pi, Muse, ACP agents…) and the user can pick per thread without leaving the app. For a harness: it can run models from two or more vendors natively (provider/aggregator config shipped with the tool).
- No if
- single-vendor harness (Claude Code, Codex CLI, Gemini CLI, Qwen Code); orchestrator that only runs one harness; add-on that extends one harness.
Boundary cases
- Two accounts from the same vendor, or several models from one vendor → no.
- "Any OpenAI-compatible endpoint" alone → no; two genuinely different vendors through built-in provider config → yes.
- Running several harnesses, but only one per install/workspace type → still yes if all are supported by the product.
- ACP/registry support is evidence for an orchestrator, not a separate feature.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
ACP acp
Speaks the Agent Client Protocol?
- Yes if
- the product officially implements the Agent Client Protocol (agentclientprotocol.com) in either direction: as an ACP agent that editors/clients such as Zed, JetBrains or T3 Code can drive, or as an ACP client that can run any ACP agent (e.g. via the ACP Registry). Built-in, documented support — including an official adapter maintained by the vendor — counts.
- No if
- only a community adapter exists; "compatible with" claims without docs; MCP support alone (MCP ≠ ACP).
Boundary cases
- An official *-acp adapter package published by the vendor → yes.
- An orchestrator that lists ACP agents in its provider picker → yes (it is an ACP client).
- Third-party adapters (e.g. a community claude-code-acp) do not make the wrapped tool true; record them in notes only.
Applies to: Harnesses, Orchestrators and Add-ons.
See tools with this feature
Parallel agents parallelAgents
Runs several agent sessions at the same time?
- Yes if
- Two or more agent sessions can run concurrently, and the product shows and manages them as separate sessions or workspaces.
- No if
- A queue that runs one session at a time; multiple tabs attached to the same session; subagents inside one session (that is `subagents`).
Boundary cases
- Parallel sessions may share one checkout or each get their own worktree; both count.
- A cap on concurrent sessions still counts.
Applies to: Harnesses, Orchestrators, Cloud agents and Add-ons.
See tools with this feature
Subagents subagents
Can an agent delegate work to child agents?
- Yes if
- An agent can spawn or delegate to child agents and collect their results within a session, using built-in delegation rather than the user starting separate sessions.
- No if
- The user starting additional top-level sessions; a fixed helper function that is not an agent; a workflow that only prompts the same agent again.
Boundary cases
- User-authored subagent definitions count here and also support `customAgents`.
- Delegation that only works through a third-party MCP server does not count as a built-in feature.
Applies to: Harnesses, Orchestrators, Cloud agents and Add-ons.
See tools with this feature
Custom agents customAgents
Can you define your own agent roles?
- Yes if
- the user can define named agent roles/personas — instructions/system prompt, tool access, model — as reusable configuration, and select them for a session or delegation.
- No if
- built-in subagents; a single project instruction file; saved prompts/slash commands; provider instances or accounts; vendor-shipped modes/personalities the user cannot author.
Boundary cases
- User-authored subagent definitions with frontmatter count.
- "Agent profiles" count.
- Per-session model/effort presets do not count.
- A custom agent that can only be used as a subagent still counts.
Applies to: Harnesses, Orchestrators and Add-ons.
See tools with this feature
Workflow
Plan mode planMode
Has an explicit plan / approve-before-edit step?
- Yes if
- A product mode that produces a plan or proposed changes and waits for approval before editing files, or a read-only planning mode the agent can enter.
- No if
- Per-command permission prompts; a summary written after the edits; a system-prompt instruction to plan first with no enforced step.
Boundary cases
- The approval step may be optional as long as the product provides it.
- Plan mode that still runs read-only commands counts.
Applies to: Harnesses, Orchestrators, Cloud agents and Add-ons.
See tools with this feature
Worktrees worktrees
Keeps parallel work in separate git worktrees?
- Yes if
- The product creates and manages a separate git worktree per session or workspace, so parallel work is isolated without manual git commands.
- No if
- Switching branches in one working tree; asking the user to run `git worktree`; isolation through copied directories or containers instead of git worktrees.
Boundary cases
- The worktree may be created by an orchestrator for the harness it runs.
- Automatic cleanup of worktrees is a quality signal, not a separate feature.
Applies to: Harnesses, Orchestrators and Add-ons.
See tools with this feature
Checkpoints checkpoints
Can you rewind code and chat to an earlier turn?
- Yes if
- a first-party snapshot/restore action returns both the workspace files and the conversation to a chosen earlier turn, in one operation, without manual git.
- No if
- manual git commit/reset; per-file undo; "revert last edit" only; automatic per-turn commits that leave the conversation intact; conversation branching without file restore.
Boundary cases
- Restoring files but not the chat → no (the question promises both).
- A cap (e.g. 100 checkpoints or a retention window) still counts.
- Cloud snapshots count.
- A manual "restore to here" that only works in one surface still counts for the tool.
Applies to: Harnesses and Orchestrators.
See tools with this feature
Diff review diffReview
Includes a built-in diff or review screen?
- Yes if
- A first-party UI shows the changes an agent made as diffs and lets the user review, accept, reject, or comment on them.
- No if
- Raw `git diff` in a terminal; a diff the user opens in an editor; diffs printed as text with no review action.
Boundary cases
- A review screen that only shows the final file contents does not count; a diff view is required.
- Review may happen per file or per turn.
Applies to: Harnesses, Orchestrators, Cloud agents and Add-ons.
See tools with this feature
PR integration prIntegration
Opens and tracks pull requests from the session?
- Yes if
- a first-class PR workflow in the product: create/open a PR from a session and see or act on its state (checks, reviews, comments), including link/watch behavior where the agent responds to review feedback or CI.
- No if
- only shell access to gh/glab; generic git commit/branch/push without PR awareness; issue tracker only.
Boundary cases
- Opening a PR with no way to see its checks/reviews → no (that is the "tracks" half).
- Cloud agents that always deliver a PR count.
- A GitHub App that reviews PRs and shows results counts if it starts/feeds agent work and surfaces PR state.
- Multiple hosts (GitHub, GitLab, Bitbucket, Azure DevOps, Forgejo) are a quality signal, not a separate feature.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Automations automations
Can it start agent runs on a schedule or event?
- Yes if
- the product itself can start an agent run with no human present, either on a recurring time/cron schedule or from an inbound event (webhook URL, GitHub/GitLab/Slack event), configured inside the product.
- No if
- a GitHub Actions/CI recipe in the docs; an external cron job calling the CLI; a "loop" or "goal" that keeps working inside an already-started session; a webhook that only posts a message into a chat; a PR review bot that only comments without starting an agent run.
Boundary cases
- Schedule only on mobile or desktop still counts (it is the product's feature).
- Event-only with no cron counts; cron-only counts.
- Cloud-only automations count for a tool that also has a local product.
- GitHub/GitLab triggers that run the vendor's cloud agent count; third-party wiring does not.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Integrations
MCP mcp
Connects to MCP servers and their tools?
- Yes if
- Documented, first-party support for connecting Model Context Protocol servers and giving their tools to the agent.
- No if
- A single hardcoded integration; support that requires patching the product; an MCP mention without documentation.
Boundary cases
- Support may be shipped as a built-in client or a documented plugin.
- Being callable from another MCP client is not the same as supporting MCP servers itself.
Applies to: Harnesses, Orchestrators, Cloud agents and Add-ons.
See tools with this feature
Skills skills
Can you add reusable skills or commands?
- Yes if
- first-party support for reusable, user-authored capability packages (Agent Skills SKILL.md or an equivalent command/skill bundle) that the agent discovers and invokes explicitly or automatically, and the product lets the user add, list, or manage them.
- No if
- a single AGENTS.md/CLAUDE.md/rules file; one-off saved prompts; vendor-hardcoded slash commands; MCP servers (tools, not procedures).
Boundary cases
- An orchestrator that only passes through whatever skills the underlying harness has → no.
- An orchestrator that installs, lists, copies, or deletes skills across environments → yes.
- An add-on that ships new skills/commands for its base → yes.
- Reusable command bundles with no model-invoked discovery (e.g. recipes) → yes if the product documents them as the equivalent reusable-workflow mechanism.
Applies to: Harnesses, Orchestrators and Add-ons.
See tools with this feature
Hooks hooks
Can your own scripts run on agent events?
- Yes if
- documented, user-authored scripts/commands (or plugin code) bound to agent lifecycle events — session start/stop, before/after tool use, file edit, prompt submit, subagent start/stop — that can observe, block, or modify behavior.
- No if
- MCP tools the agent chooses to call; skills/slash commands invoked by the user or agent (not event-driven); git hooks; setup scripts; chat notification webhooks.
Boundary cases
- A plugin API with event handlers counts (e.g. OpenCode plugins).
- Observation-only hooks count; they need not block.
- An orchestrator that merely displays or forwards the harness's hooks does not count under the layer rule; it counts only if it runs its own hook system.
- Cloud-execution hooks count if documented.
Applies to: Harnesses, Orchestrators and Add-ons.
See tools with this feature
Issue tracker issueTracker
Can it pull work from GitHub or Linear issues?
- Yes if
- first-party integration with an issue tracker (GitHub Issues, GitLab, Linear, Jira, Azure DevOps) that lets the user browse issues, start a session/workspace from one, and link the session or resulting PR back to it.
- No if
- an MCP server for Linear/Jira the user installs; gh issue through the shell; PR integration only.
Boundary cases
- Read-only issue browsing with no start/link path → no.
- Multiple trackers are a quality signal, not a separate feature.
- A cloud agent that accepts a GitHub issue URL and opens a PR counts.
- Issue sync that only displays a link in the PR body does not count.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Browser preview browserPreview
Can the agent open and drive a web browser?
- Yes if
- built-in browser automation: the agent can navigate real pages, click/type/scroll, take screenshots, and read console or network output — or a built-in live app preview the agent can inspect and interact with. It must work without the user installing a browser MCP server.
- No if
- an MCP Playwright/Puppeteer server the user configures; a screenshot-only tool; opening a URL in the user's own browser; rendering markdown/HTML artifacts with no interaction.
Boundary cases
- Desktop-only control counts; mobile-only does not (agents do not drive a browser there).
- A built-in "browser subagent" counts.
- Mobile simulator/emulator control is not a browser — do not count it here.
- "Computer use" that can control any app, including a browser, counts.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Access & safety
Remote access remoteAccess
Can you follow or control sessions from another device?
- Yes if
- Sessions can be followed or controlled from a different device or browser through a first-party path, such as a web app, mobile app, or remote connection.
- No if
- SSH or tmux the user sets up; a desktop-only local UI; a read-only screenshot or log feed.
Boundary cases
- Same-machine browser access counts only when the product provides it, not when it exposes a local port for the user to tunnel.
- Watch-only mobile access counts as following; control is not required.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Cloud sandbox cloudSandbox
Runs work in a hosted sandbox rather than on your machine?
- Yes if
- The vendor runs agent work in its own hosted, sandboxed compute, and the user does not need local resources for that run.
- No if
- Local sandboxing; a container or VM the user hosts; a cloud API that only serves model inference.
Boundary cases
- A cloud agent that always runs remotely counts.
- A product with both local and cloud execution counts if hosted sandbox runs are a first-party option.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature
Local sandbox sandboxing
Does it sandbox what agents can do locally?
- Yes if
- a built-in, enforced local execution boundary: OS-level sandbox (seatbelt, landlock, bubblewrap), container/VM isolation, or a permission engine that can pre-deny classes of tool actions with persistent allow/ask/deny rules rather than prompting on every call.
- No if
- cloud sandbox only (that is cloudSandbox); plain per-command approval prompts with no enforceable policy; running the tool inside Docker yourself; a read-only/plan toggle used as the only restriction.
Boundary cases
- Filesystem and/or network limits count.
- Approval modes with persistent allowlists/denylists count; one-off prompts do not.
- A local sandbox that is optional but documented counts.
- Platform-limited support (e.g. macOS only) still counts.
Applies to: Harnesses and Orchestrators.
See tools with this feature
Headless / API headlessApi
Can you run it from scripts, CI, or your own code?
- Yes if
- a documented, first-party non-interactive path: a CLI flag/mode (-p, exec, run) that returns output/exit code, a local or remote server with an HTTP/OpenAPI API, an SDK, or an MCP control surface that can start runs and read results.
- No if
- only an interactive TUI/desktop app; CI recipes that wrap an interactive CLI with expect; a CLI that only installs/authenticates.
Boundary cases
- --print/exec modes count even if file edits need an extra flag.
- Control through a first-party MCP server counts (an outside program drives the tool).
- A cloud-only API counts for tools that also ship a local product.
- An add-on that only configures its base does not inherit this flag.
Applies to: Harnesses, Orchestrators and Cloud agents.
See tools with this feature