OpenCode vs Conductor
open-source · usage-based
·free-tier · subscription-flat · subscription-per-seat · enterprise-custom
OpenCode wins · 31–21 (17 drawn)
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to ConductorOpenCode's own llms.txt file returns 404, so there is no dedicated llms.txt for agents, but probes show that docs pages are available in machine-readable Markdown form (.md suffix returns 200), which serves an analogous agent-oriented documentation function. There's no first-party statement about llms.txt support or explicit agent-doc pointing workflow. Missing for 10: an actual llms.txt endpoint, documentation instructing users to point agents at machine-readable docs, and confirmation that agents can consume the .md docs as intended.
Direct probe confirms llms.txt is live and served at https://www.conductor.build/llms.txt with agent-oriented summary, plus a full docs.md markdown mirror for agent consumption. missing for 10: no independent/community confirmation that external agents actually consume these files successfully.
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
- [probe] “PROBE docs-md: HTTP 200 at https://www.conductor.build/docs.md --- title: "Introduction" url: "/docs" description: "Learn what Conductor is …”
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to OpenCodeOpenCode explicitly supports headless/CI use via `opencode run` for non-interactive execution, `opencode serve` for a headless HTTP server with OpenAPI, `--auto` for unattended permission approval, a JS/TS SDK for programmatic control, and a first-party GitHub Actions integration triggered by PR comments. This covers CLI scripting, server automation, and CI pipelines with concrete docs and an OpenAPI endpoint confirmed live. missing for 10: independent third-party validation of CI reliability at scale (community evidence mostly covers interactive TUI use, not CI-specific automation).
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
Conductor supports scheduled/CI-like automation via 'routines' that run on a schedule or GitHub Action, plus a programmatic API and hosted MCP server for managing cloud workspaces headlessly, and cloud agents can run builds/tests without confirmation. However, it is fundamentally a Mac GUI app, and there's no evidence of a standalone CLI or true headless binary for arbitrary CI pipelines outside GitHub Actions. missing for 10: dedicated CLI/headless binary for generic CI systems, independent evidence of routines/GitHub Action working reliably in production, clarity on full non-interactive operation outside the Mac app.
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · round to OpenCodeOpenCode has first-party documentation dedicated to adding external tools via MCP, supporting both local and remote servers, directly matching the story. This is corroborated indirectly by community discussion of OpenCode's tool/agent ecosystem, though no hands-on account specifically tests MCP server plugging. Missing for 10: independent/hands-on confirmation specifically of MCP server usage (community evidence discusses agents/tools generally but not MCP specifically).
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
Conductornone0/10Evidence only shows Conductor exposing its OWN hosted MCP server so external MCP clients (ChatGPT, Claude, Codex) can manage Conductor's cloud workspaces (conductor-docs-14, conductor-probe-4) — the reverse direction of what the story asks. There is no documentation or community mention of a user being able to add/configure external MCP servers inside Conductor so its hosted coding agents (Claude Code, Codex, Cursor, OpenCode) can consume their tools.
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
ai-native userUse an official CLI
weight 2 · round to OpenCodeOpenCode ships an official CLI with documented commands (opencode run, opencode serve, init, install via curl/npm) and dedicated CLI docs, corroborated by community users who actively use it as their primary daily-driver harness. Missing for 10: independent benchmarking of CLI completeness/stability beyond anecdotal community reports (some bug complaints noted but not disputing existence of an official CLI).
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “npm install -g opencode-ai”
- [probe] “official CLI documented at https://opencode.ai/docs/cli/”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
Conductornone0/10Conductor is documented as a Mac GUI app with a programmatic API and hosted MCP server, but no evidence pack item describes an official Conductor CLI tool; the only CLI mention is a user leveraging their own 'local GitHub CLI auth', which is unrelated.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
ai-native userDrive the product through a documented public API
weight 3 · round to OpenCodeOpenCode ships a documented headless server (`opencode serve`) exposing an OpenAPI endpoint, confirmed live via probe (opencode-probe-3), plus a type-safe JS/TS SDK for programmatic control, and its CLI supports non-interactive scripted use (`opencode run`). missing for 10: independent third-party corroboration of SDK/API usage in production, and no evidence of versioning/stability guarantees or broader language SDK support beyond JS/TS.
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”
- [claimed-docs] “Use it to build integrations and control opencode programmatically.”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
- [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”
Conductor documents a public API for programmatically managing cloud workspaces (create workspaces, send prompts, read agent replies) plus a hosted MCP server for AI clients like ChatGPT/Claude/Codex to drive it. Missing for 10: a published OpenAPI/reference spec (probe found only 404s for schema files) and independent/hands-on developer corroboration of API usage.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round to ConductorOpenCode's permission config lets you restrict which actions (edit, bash, etc.) an agent may auto-run, prompt for, or block, and enterprise SSO integration centralizes access to an internal AI gateway — both are adjacent to least-privilege agent control, but neither is a mechanism for issuing scoped API credentials/keys specifically to an agent. missing for 10: explicit scoped API-key/credential issuance for agents, credential expiry/rotation, per-agent key scoping documentation, independent verification of this capability.
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
Community threads document that Conductor originally required full read/write GitHub access with no fine-grained scoping, which users flagged as risky; the developers later added a GitHub App integration for fine-grained repo access (or use of local GitHub CLI auth) as a fix, showing partial progress toward least-privilege credentials but not a documented, general mechanism for issuing scoped API credentials for agents beyond GitHub repo access. Missing for 10: no documentation of scoped/least-privilege credentials for the Conductor API/MCP server itself, no explicit policy on token scoping for non-GitHub integrations, and no independent verification that the new GitHub App permissions are truly minimal in practice.
- [community] “Any way to have it not require full write access to your entire GitHub account?”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
- [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
- [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
- [claimed-docs] “Bring your own subscriptions and keys”
ai-native userBuild against official SDKs
weight 2 · round to OpenCodeOpenCode documents a dedicated JS/TS SDK ('type-safe client for interacting with the server... use it to build integrations and control opencode programmatically') plus a headless server mode (`opencode serve`) exposing an OpenAPI endpoint, confirmed live by probe (openapi.json returns valid schema). This gives AI-native users official, documented programmatic access beyond the CLI/TUI. Missing for 10: independent hands-on developer reports of building against the SDK, and broader multi-language SDK coverage beyond JS/TS.
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “Use it to build integrations and control opencode programmatically.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
Conductor documents an official REST-style API for managing cloud workspaces and sending/reading agent prompts, plus a hosted MCP server for AI clients, which supports building AI-native integrations. However, no dedicated client SDK packages (e.g., npm/python libraries) are evidenced, and a probe for an OpenAPI spec returned 404s, suggesting the 'SDK' is really just a raw API/MCP interface rather than a polished, language-specific SDK. missing for 10: official language SDK packages, OpenAPI/schema-based codegen support, independent hands-on confirmation of SDK usage.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnOpenCodenone0/10Evidence shows OpenCode has a headless server (`opencode serve`) exposing an OpenAPI/HTTP endpoint and an SDK for programmatic control, but there is no mention anywhere of webhook subscriptions or event-push notifications that clients could register for.
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”
Conductornone0/10The evidence pack documents a programmatic API and an MCP server for managing cloud workspaces, but nowhere mentions webhooks or any event-subscription mechanism for AI-native users to receive push notifications on workspace/task events.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
Agentic features
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · round to OpenCodeOpenCode's plan/explore agents let users get AI-generated code analysis and suggested changes without modifying the codebase, directly matching the story of AI-generated insights over the user's data (their code) (opencode-docs-7, opencode-docs-60, opencode-docs-61). Community mentions confirm active use of the agent for analysis/harness work (opencode-comm-1, opencode-comm-3). Missing for 10: independent examples of insight quality/output, and no evidence of insights beyond code (e.g., broader data analytics).
- [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
Conductor orchestrates third-party coding agents (Claude Code, Codex, Cursor) that analyze the codebase and produce diffs, suggested changes, and PR reviews, which can be seen as data-driven suggestions, but Conductor itself does not document any native analytics/insights engine — the 'insight' generation is delegated entirely to the underlying agents. Missing for 10: no first-party insight/analytics feature, no evidence of Conductor synthesizing patterns or trends from user data beyond agent chat/diff output, no independent corroboration of this specific capability.
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
ai-native userSet up automations that run autonomously in the background
weight 2 · round to ConductorOpenCode ships a documented GitHub Actions integration where mentioning /opencode or /oc in a comment triggers it to autonomously work in a new branch and submit a PR, plus a headless `serve` mode and `--auto` permission flag that let it run unattended, supporting background automations. However there's no dedicated scheduling/cron mechanism, and community evidence flags reliability issues (stuck sessions, tool-call failures) that undercut confidence in unattended runs. missing for 10: scheduled/triggered automation beyond GitHub comment mentions, independent evidence of long-running unattended background jobs succeeding reliably.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
- [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
Conductor's "routines" feature explicitly lets users run agents on a schedule or via GitHub Action, and cloud workspaces continue running autonomously ("agents keep working after you close your laptop") without requiring step-by-step confirmation. This directly matches background, autonomous automation for an AI-native user. Missing for 10: independent/hands-on confirmation that routines work reliably in practice, and more detail on scheduling configuration options beyond the changelog mention.
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · round to OpenCodeOpenCode's core function is exactly this: an AI coding agent you delegate tasks to via CLI/TUI/IDE/desktop ('opencode run "Explain how closures work..."'), with multiple agent personas (build, plan, explore) and multi-session parallel delegation, richly documented and corroborated by extensive hands-on community use as a daily coding harness. Missing for 10: no independent benchmark of delegation reliability across all model backends (some community reports of failed tool calls/edits with local models).
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [claimed-docs] “You can use the **Tab** key to switch between primary agents during a session.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
- [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”
Conductor lets users delegate coding tasks to agents (Claude Code, Codex, Cursor, OpenCode) that run inside its own workspaces, autonomously testing repos, running builds, and continuing work unattended, with checkpoints and review flow built into the product (conductor-docs-1, -17, -20, -29, -32). Community reports confirm the agent runs live inside the app during real use (conductor-comm-7, conductor-comm-15). Missing for 10: independent benchmarking of assistant quality/reliability beyond docs and mixed anecdotal UX feedback (conductor-comm-9).
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
- [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”
ai-native userOperate the product with natural-language commands
weight 2 · round to OpenCodeOpenCode's core interface is natural-language driven: the CLI example `opencode run "Explain how closures work in JavaScript"` and TUI/desktop/IDE modes are all built around conversational prompts to an AI agent that then edits code, opens branches, and submits PRs. Community usage (comm-1, comm-3, comm-4, comm-11) confirms this is how real users operate it day-to-day as their primary coding harness. Missing for 10: no independent benchmark specifically validating breadth of natural-language command coverage beyond docs/anecdotes.
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
- [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”
Conductor's entire interaction model is natural-language chat with coding agents (Claude Code, Codex, Cursor, OpenCode) that can autonomously test, build, and edit without step confirmation, and it exposes a hosted MCP server so ChatGPT/Claude/Codex or other AI clients can manage workspaces via natural language, plus an API to send prompts and read agent replies. missing for 10: independent/hands-on validation of natural-language command reliability beyond vendor docs.
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to OpenCodeOpenCode exposes a raw OpenAPI spec via `opencode serve` and openapi.json, and offers an SDK for programmatic use, but there is no evidence of an actual interactive API reference UI (e.g., Swagger/Redoc-style docs) with runnable/try-it examples. Missing for 10: dedicated interactive API explorer page, runnable code examples, independent confirmation of such a UI existing.
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
Conductornone0/10Conductor has documented API endpoints and an MCP server, so an interactive API reference with runnable examples is a plausible feature, but the evidence pack shows no such reference exists — the docs page is static markdown and probes for OpenAPI/Swagger specs all returned 404.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to OpenCodeThe docs explicitly state that `opencode serve` runs a headless HTTP server exposing an OpenAPI endpoint, and a live probe confirms a downloadable machine-readable OpenAPI spec at https://opencode.ai/openapi.json. This directly satisfies the story of downloading a machine-readable API spec. Missing for 10: independent/community corroboration of using this OpenAPI spec in practice.
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
Conductornone0/10Conductor documents a REST-like API and an MCP server, but a direct probe for machine-readable OpenAPI/Swagger specs at standard locations returned 404 on all candidate paths, and no evidence pack item links to a downloadable spec file.
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to ConductorOpenCodenone0/10OpenCode's docs describe permission controls, --auto approval, and external_directory restrictions, but there is no evidence of a dedicated sandbox/staging environment or mechanism to test against non-production data separate from the user's actual working directory/production files. Community reports even flag security gaps in the local server (opencode-comm-18) rather than any sandboxing feature for safe testing.
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
- [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”
Conductor's core architecture creates isolated workspaces (separate git worktrees, branches, cloud sandboxes) so each agent task runs independently without touching the main/production branch (conductor-docs-2, conductor-docs-20, conductor-docs-27, conductor-docs-29), and community users confirm the git-worktree-based isolation (conductor-comm-1, conductor-comm-17). However, this isolation is code/branch-level, not explicitly a data-layer sandbox (e.g., staging DB, mock services), and one community report notes full GitHub write-access requirements that undercut a clean 'no touching production' guarantee (conductor-comm-5, conductor-comm-6). Missing for 10: explicit handling/isolation of production data stores or environment variables, and confirmation that sandbox workspaces cannot inadvertently write to production systems.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
- [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnOpenCodenone0/10OpenCode does expose programmatic surfaces (the JS/TS SDK, `opencode serve` HTTP server, and an OpenAPI spec at openapi.json), so an API-versioning/deprecation-policy axis is applicable. However, none of the evidence mentions API version numbers, backward-compatibility guarantees, or any documented deprecation policy/process for the SDK or server API.
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
Conductornone0/10There's an API and MCP server documented, but no evidence of API versioning scheme or a deprecation policy; probes show no OpenAPI spec found and no changelog/policy on version deprecation.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to ConductorOpenCode's CLI (`opencode run`), SDK, and headless `opencode serve` provide programmatic hooks that could be scripted to loop over many files/tasks, and 'multi-session' lets multiple agents run in parallel on a project — but there is no documented first-class 'bulk operation' feature (e.g. batch refactor, mass file edit) or example of applying one command across many items at once. Missing for 10: explicit bulk/batch operation feature, documentation or examples of running the same task across many files/repos, independent evidence of successful large-scale batch use.
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “Use it to build integrations and control opencode programmatically.”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
Conductor supports running many coding agents in parallel across isolated workspaces, and exposes a programmatic API plus scheduled/CI-triggered 'routines' that can create workspaces and send prompts at scale — a reasonable basis for bulk, automation-driven operations across many items. However, there's no documented UI for batch-selecting and acting on many existing workspaces at once (e.g., bulk archive/merge), and no independent evidence of large-scale parallel runs in practice. Missing for 10: explicit multi-item batch actions in the UI, evidence of scale/limits on parallel agents, and third-party corroboration of bulk automation workflows via the API or routines.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnOpenCode supports some automatic rule-triggered behavior: GitHub integration lets a PR/issue comment mention (`/opencode` or `/oc`) automatically trigger the agent to execute tasks in a GitHub Actions runner, and the `permission` config lets you define rules for auto-approving, prompting, or blocking specific tool actions. This covers event-triggered automation in a narrow sense, but there's no general-purpose, user-defined event/rule engine (e.g., file-change hooks, cron-like triggers, custom event listeners) described in the docs. Missing for 10: a general automation/hooks system beyond GitHub comment mentions and permission gating, and independent evidence confirming reliability of these triggers in practice.
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “OpenCode uses the permission config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “For most permissions, you can use an object to apply different actions based on the tool input.”
Conductor's 'routines' feature lets agents run on a schedule or via GitHub Action trigger, which is a limited form of event-driven automation, but there's no evidence of a general rules engine supporting arbitrary event types (e.g., webhooks, file changes, custom conditions) or complex trigger-action definitions. Missing for 10: broader event-type support, custom rule/condition definitions, and hands-on evidence that routines fire reliably on GitHub events.
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
ai-native userSchedule recurring jobs or workflows
weight 2 · round to ConductorOpenCodenone0/10No evidence of any scheduling, cron-like, or recurring workflow trigger capability; OpenCode's docs cover CLI, agents, MCP, permissions, SDK, GitHub Actions triggers, and server mode but none describe scheduling or recurring automation. missing for 10: any scheduler/cron feature, recurring job configuration, or workflow trigger on a schedule.
Conductor's changelog explicitly introduces 'routines' that let agents run on a schedule or via GitHub Action, directly matching the recurring-jobs/workflows story. However, this is a single brief changelog mention with no dedicated documentation page, configuration details, or community corroboration of the feature in practice. Missing for 10: dedicated docs on routine/schedule configuration, independent/hands-on confirmation, details on failure handling or monitoring of scheduled runs.
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
ai-native userVersion, review, and roll back my automations
weight 1 · round to ConductorOpenCodenone0/10Evidence covers agent creation, permissions, sessions, and sharing, but there is no documentation or community mention of versioning automations, reviewing change history, or rolling back agent/workflow configurations — session share links are for reference/debugging, not version control or rollback.
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “Share links Share a link to any session for reference or to debug”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “This command will guide you through creating a new agent with a custom system prompt and permission configuration.”
Conductor provides git-based versioning (separate branches/worktrees per workspace), diff review before merge/PR, and 'Checkpoints' to revert code and chat state to an earlier turn—covering version, review, and rollback at the workspace/agent-session level. However, the newer 'Routines' (scheduled/GitHub-Action automations) feature has no documented versioning, review, or rollback mechanism specific to the automation definitions themselves. Missing for 10: explicit version history/rollback for Routines/scheduled automations, independent hands-on confirmation of checkpoint reliability.
- [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
Autonomy agents — stories about autonomy agents in this arenaAutonomy agents
Stories about autonomy agents in this arena
Background execution
ai-native userHave a cloud agent build, test, and demo a feature end-to-end for my review
weight 2 · round to ConductorOpenCode's GitHub integration lets it work in a new branch and submit a PR autonomously when mentioned via `/opencode` in GitHub Actions, and its share-links/session feature lets a reviewer inspect the agent's work — together covering 'build' and 'demo for review' in a cloud context. However, there is no explicit documentation of an automated testing step as part of this workflow, and the 'cloud agent' aspect relies on self-hosted GitHub Actions runners rather than a dedicated managed cloud agent service. Missing for 10: explicit test-execution/validation step in the PR workflow, and a first-party fully-hosted cloud agent (not just Actions-runner based) with demo artifacts.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “Share links Share a link to any session for reference or to debug”
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
Conductor's cloud agents can autonomously test repos, update setup scripts, and run builds without step-by-step confirmation (conductor-docs-17, conductor-docs-32), continue working after the laptop closes (conductor-docs-20), and then help the user review the diff, open a PR, and merge (conductor-docs-21) — covering build, test, and review end-to-end for a feature. Missing for 10: no explicit 'demo' artifact (e.g., preview links/screenshots) beyond diff/PR review, and no independent/hands-on account confirming a full autonomous build-test-review cycle worked as described.
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
developerDelegate longer-running coding tasks to run in the background in an isolated cloud environment
weight 3 · round to ConductorOpenCode documents GitHub integration where mentioning /opencode or /oc triggers it to work in a new branch and submit a PR, executing tasks inside the GitHub Actions runner (an isolated cloud environment), which supports background delegation of coding tasks. However, there's no dedicated general-purpose 'cloud agent' product, persistent cloud session management, or evidence of handling arbitrarily long-running tasks outside the GitHub Actions context. missing for 10: a dedicated hosted/cloud sandbox environment independent of GitHub Actions, evidence of long-running task monitoring/resumption in the cloud, and independent hands-on confirmation of this workflow succeeding.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
Docs describe a dedicated 'cloud workspace' feature where agents run in isolated sandboxes that 'spin up in seconds' and 'keep working after you close your laptop,' can test repos/run builds unattended, and continue processing PR checks while 'asleep' (conductor-docs-20, conductor-docs-17, conductor-docs-11, conductor-docs-13). However, community reports describe the core product as creating an isolated git worktree locally rather than a cloud container, contrasting it with Codex's cloud sandbox (conductor-comm-17, conductor-comm-6), suggesting the cloud-isolation capability may be a newer/optional layer rather than the default experience. Missing for 10: independent hands-on verification that background cloud tasks are fully isolated/persistent, and clarity on whether cloud workspaces are the default vs. opt-in given local-worktree-first community accounts.
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
- [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
developerConfigure a reproducible cloud environment with the dependencies and setup steps my repository needs
weight 2 · round to ConductorOpenCodenone0/10The evidence shows OpenCode as a terminal/IDE agent with GitHub PR automation and a headless `serve` mode, but nothing describes a mechanism for developers to declare a reproducible cloud environment (base image, dependencies, setup scripts) that the agent provisions before running. Missing for 10: any devcontainer/config-file spec for cloud sandbox provisioning, dependency installation steps, or documented cloud execution environment configuration.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
Docs show Conductor's cloud workspaces spin up sandboxes, check for needed tools/credentials, and let agents edit install/setup scripts and run builds automatically, which supports configuring an environment with the right dependencies (conductor-docs-17, conductor-docs-20, conductor-docs-32, conductor-docs-33). However there's no explicit first-party description of a declarative, versioned environment-config file (e.g., a devcontainer-style spec) guaranteeing reproducibility across runs/teammates, and no independent confirmation that these setup scripts persist reliably across sessions. missing for 10: explicit reproducible-config artifact/spec, independent verification that environment setup is consistent across workspace recreations.
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [claimed-docs] “When you open Conductor, it checks for the tools and credentials it needs. If anything is missing, Conductor walks you through setup.”
Parallel agents
ai-native userLaunch fleets of autonomous agents that work in parallel on different tasks for hours or days
weight 2 · round to ConductorOpenCode documents multi-session support ('Start multiple agents in parallel on the same project'), subagents with per-agent model choice, and GitHub Actions integration where mentioning /opencode lets it execute unattended tasks and open PRs — all pointing toward parallel, semi-autonomous agent operation. However, there is no explicit documentation or evidence of orchestrating large 'fleets' of agents or of sustained autonomous operation over hours/days, and community reports note agents 'randomly stuck, especially for long/nested sessions,' undercutting long-horizon reliability. Missing for 10: dedicated fleet-management/orchestration tooling, explicit hours/days-long autonomous run support, and independent confirmation of stable long-running parallel agent execution.
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
Docs show Conductor explicitly designed for running multiple agents (Claude Code, Codex, Cursor, OpenCode) in parallel across isolated workspaces/worktrees, with cloud workspaces that 'keep working after you close your laptop' and 'routines' to run agents on a schedule or via GitHub Action, supporting long-running autonomous fleets. Community feedback focuses on GitHub permission/privacy concerns rather than disputing the parallel-autonomy capability itself. Missing for 10: independent/hands-on confirmation of agents actually running unattended for multi-day spans and evidence of fleet scale (e.g., dozens of simultaneous agents).
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Run multiple agents in one workspace when the work belongs on the same branch and should share the same files and context.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
developerRun several task attempts in parallel and compare results before choosing one
weight 1 · round to ConductorOpenCode documents 'multi-session' support to start multiple agents in parallel on the same project (opencode-docs-17/38) and share links to sessions for reference/debugging (opencode-docs-18/37), which enables running parallel work and inspecting different sessions. However, there is no documented feature for running multiple attempts at the *same* task specifically to compare outcomes and pick a winner (e.g., no diff/compare UI or attempt-ranking workflow), and community threads discuss general session-state bugs rather than this comparison workflow. Missing for 10: explicit same-task multi-attempt spawning, a built-in comparison/diff view across attempts, and evidence of choosing/merging the best result.
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “Share links Share a link to any session for reference or to debug”
- [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
Conductor's core design is running multiple coding agents in parallel, each in its own isolated workspace/git worktree with its own branch, files, and diff/review path, letting a developer inspect and choose before merging (docs-2, docs-27, docs-29, docs-21, probe-1). Community hands-on comments corroborate the git-worktree-based parallel workspace model (conductor-comm-1, conductor-comm-17). missing for 10: explicit first-party description of a side-by-side comparison UI across multiple simultaneous attempts (evidence shows parallel isolated workspaces and per-workspace diff/review, but not an explicit 'compare attempts' feature or independent review confirming the comparison workflow).
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
- [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
Scheduled automation
ai-native userSet up always-on agents that run on schedules or triggers to maintain and fix my software autonomously
weight 2 · round to ConductorOpenCodenone0/10OpenCode documents CLI/TUI/desktop agents, permission automation, GitHub Actions integration triggered by comments, and a headless server/SDK, but there is no evidence of scheduling (cron-like) or event-trigger-based always-on autonomous agents that proactively maintain/fix software without a user or PR-comment invocation. The GitHub integration is triggered by manual mentions, not autonomous scheduled monitoring. Missing for 10: scheduled/cron-based agent runs, event-driven triggers beyond manual mentions, autonomous 'always-on' background maintenance capability.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
Conductor documents 'routines' that run agents on a schedule or via GitHub Action, plus cloud agents that keep working after you close your laptop and can autonomously test, fix, and rebuild repos without step-by-step confirmation — directly supporting always-on autonomous maintenance. However, the routines feature is only briefly mentioned in a changelog entry with no deep documentation of trigger types, monitoring, or failure-handling, and no independent/hands-on evidence confirms long-running unattended reliability. Missing for 10: detailed docs on trigger configuration (webhooks, cron specifics), evidence of long-term unattended reliability, and community confirmation of the scheduling/autonomy feature working in practice.
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
Code generation — quality of generated code — correctness, style, fit to the codebaseCode generation
Quality of generated code — correctness, style, fit to the codebase
Debugging
developerDebug issues and troubleshoot using natural-language queries
weight 2 · round to OpenCodeOpenCode is a terminal/IDE-based coding agent that takes natural-language queries (e.g. `opencode run "Explain how closures work..."`), can explore/read codebases via a dedicated read-only agent, and auto-loads LSPs so it can surface diagnostics/errors while chatting, all of which supports NL-driven debugging and troubleshooting; community users confirm using it as a daily 'harness' with good LSP integration for real work. missing for 10: no dedicated 'debug' or troubleshooting workflow docs, and community reports of failed tool calls/unreliable file edits with some models introduce real-world friction.
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “A fast, read-only agent for exploring codebases.”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
Conductor orchestrates coding agents (Claude Code, Codex, Cursor) that support natural-language chat, and each workspace has its own terminal, diff, and chat interface, implying a developer could ask an agent to debug/troubleshoot via NL queries. However, there's no Conductor-specific documentation describing a dedicated debugging/troubleshooting NL workflow, error-log analysis, or diagnostic features beyond generic agent chat and build/test execution. Missing for 10: explicit docs on NL-driven debugging workflows, log/error analysis features, or examples of troubleshooting via chat distinct from general coding tasks.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
Feature implementation
developerTurn a tracked issue into a complete pull request end-to-end
weight 3 · round drawnDocs explicitly state OpenCode can be asked to fix an issue or implement a feature, working in a new branch and submitting a PR with all changes, and it integrates with GitHub Actions via /opencode mentions to run tasks end-to-end. This directly covers issue-to-PR automation, though evidence is vendor-documented only without independent hands-on confirmation of the full issue-to-PR flow succeeding. Missing for 10: independent/community verification of a successful end-to-end issue-to-PR run, and detail on how issue tracking (e.g., linking to GitHub issues specifically) is handled beyond the GitHub Actions integration.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
Docs show workspaces can be created directly from a GitHub issue (conductor-docs-12), agents run autonomously to implement, test, and build (conductor-docs-17, conductor-docs-20), and Conductor then helps review the diff, open a PR, merge, and archive the workspace (conductor-docs-21) — covering the full issue-to-PR loop. Missing for 10: independent/hands-on confirmation of the complete issue→PR flow (community evidence covers worktree/permissions concerns but not this specific workflow), and no example of a merged PR originating from an issue.
- [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
developerDescribe a feature or bug in plain language and have the agent implement or fix it across multiple files
weight 3 · round to OpenCodeOpenCode is explicitly a coding agent that takes plain-language instructions and edits code, with docs describing it fixing issues/implementing features and submitting PRs (opencode-docs-12), a CLI for prompting tasks (opencode-docs-22), and permission/auto-approve config for autonomous multi-file changes (opencode-docs-13/14). Community reports corroborate real-world multi-file coding use, with several users calling it their primary harness replacing Aider/Claude Code (opencode-comm-1, opencode-comm-3, opencode-comm-4, opencode-comm-11, opencode-comm-14), though some report unreliable file edits with certain local models and failed tool calls in general (opencode-comm-10, opencode-comm-12). Missing for 10: independent benchmark data on multi-file edit accuracy, and resolution of the reported local-model editing reliability issues.
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
- [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”
- [community] “OpenCode is awesome. Claude Code is nothing special at all. Last month I switched to just using OpenCode with a Codex $200/mo subscription, …”
- [community] “I haven't been able to successfully get their CLI to reliably edit files when using local models, anybody else having the same problem?”
- [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
Conductor orchestrates underlying coding agents (Claude Code, Codex, Cursor, OpenCode) that implement plain-language feature requests across files, with workspaces, diffs, and PR flows supporting this, and community feedback confirms it works as a Claude Code-like workflow wrapper. However, the actual code-generation quality depends entirely on the underlying agent, not Conductor itself, and no hands-on example of a multi-file feature/bug fix is shown in the evidence. missing for 10: a concrete hands-on example of Conductor implementing a described feature/bug across multiple files, and clarity on Conductor's own contribution versus the wrapped agent's capability.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
Maintenance automation
developerHave the agent write tests, fix lint errors, resolve merge conflicts, and update dependencies for me
weight 3 · round to OpenCodeOpenCode is documented as a general-purpose coding agent that can edit files, run shell commands, and even autonomously fix issues and submit PRs (opencode-docs-12, opencode-docs-58), which implies it can perform tasks like writing tests, fixing lint, resolving conflicts, and updating deps as generic coding actions. However, none of the docs explicitly call out test-writing, lint-fixing, merge-conflict resolution, or dependency updates as named capabilities, and community reports note reliability gaps such as failed tool calls and unreliable file edits especially with local models (opencode-comm-10, opencode-comm-12). Missing for 10: explicit documentation or hands-on evidence of test generation, lint-fix workflows, merge-conflict resolution, and dependency-update automation.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
- [community] “I haven't been able to successfully get their CLI to reliably edit files when using local models, anybody else having the same problem?”
- [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
Docs confirm the underlying agents can test repositories, edit setup/install scripts, and run builds autonomously (conductor-docs-17, conductor-docs-32), which covers test-writing/fixing to some degree, but there is no explicit documentation or community evidence of lint-error fixing, merge-conflict resolution, or dependency updates as distinct capabilities. Missing for 10: explicit evidence of lint fixing, merge conflict resolution, and dependency-update automation.
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
Codebase understanding — how deeply the tool maps your repo — cross-file context, architecture awareness, historyCodebase understanding
How deeply the tool maps your repo — cross-file context, architecture awareness, history
Codebase mapping
developerUnderstand how a codebase fits together to find where to start making changes
weight 3 · round to OpenCodeOpenCode ships a dedicated read-only 'explore' agent for scanning codebases and a 'plan' agent that analyzes code and proposes changes without modifying files, backed by automatic LSP loading for the right language context and skills that surface repo-specific instructions; community notes call the LSP integration 'great' for understanding code. Missing for 10: no dedicated codebase-mapping/visualization feature, no independent benchmark of comprehension quality, and no first-hand user account describing successful architecture-level onboarding via these agents.
- [claimed-docs] “A fast, read-only agent for exploring codebases.”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
- [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
Conductornone0/10Conductor's evidence focuses on orchestrating parallel coding agents, worktrees, and workspace management, not on codebase comprehension features; the only related item is a basic file-content search (⌘⇧F), which does not constitute understanding how a codebase fits together or where to start making changes.
- [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”
developerHave the agent map and explain an entire unfamiliar codebase without manually selecting context files
weight 3 · round to OpenCodeOpenCode ships a dedicated read-only 'explore' agent explicitly for exploring codebases and a plan agent for analyzing code without edits, plus automatic LSP loading that gives it broader code awareness without manual file picking. However there's no documented feature for generating a full repo map/summary or explicit 'explain this whole codebase' workflow beyond agent tool use (e.g. grep/glob/read), and no independent hands-on evidence confirming it successfully maps a large unfamiliar codebase end-to-end. Missing for 10: explicit repo-map/codebase-summary feature, hands-on/independent confirmation of whole-codebase explanation without manual context selection.
- [claimed-docs] “A fast, read-only agent for exploring codebases.”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
Conductornone0/10Conductor's evidence focuses on orchestrating parallel agent workspaces, worktrees, git branches, and collaboration—not on any built-in whole-codebase mapping or explanation capability. The closest feature is manual file-content search (⌘⇧F), which requires the developer to search rather than having the agent autonomously map/explain the codebase.
- [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
Context management
developerHave the agent build and recall memory automatically across sessions
weight 2 · round drawnOpenCodenone0/10No evidence in the pack describes any persistent memory feature that automatically builds or recalls context/knowledge across separate sessions; docs cover sessions, sharing, agents, MCP, skills, and permissions, but nothing about automatic cross-session memory persistence or recall.
Conductornone0/10Evidence covers checkpoints (revert to earlier turn), static 'general preferences' for repo-wide instructions, and parallel workspace/session management, but nothing describes the agent automatically building or recalling memory across sessions (e.g., persistent knowledge base, learned context reuse). This is a fair axis for a coding-agent orchestration tool, so absence of evidence yields none.
- [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
- [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
developerInclude multiple project directories in a single session for broader context
weight 2 · round drawnOpenCodenone0/10The evidence shows a permission flag (`external_directory`) that lets tool calls touch paths outside the working directory, but there is no documentation or community report describing a way to add multiple project directories into a single session for combined context. Multi-session and multi-agent features are about running parallel sessions, not merging directories into one context.
- [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
Conductornone0/10Conductor's workspace model is built on git worktrees scoped to a single repository/branch per workspace (conductor-docs-27, conductor-docs-29), and there's no documentation of combining multiple project directories into one session. A community member explicitly requested multi-repo task support, implying it isn't currently available (conductor-comm-12).
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “I've been looking for a tool like this, that lets Claude operate on multiple repos... but all the tools for background/multiplexing are alwa…”
developerAdd a project instructions file to set coding standards and conventions the agent follows
weight 3 · round to OpenCodeOpenCode's docs mention an `opencode init` step to set up a project (docs-21/39/56) and 'Agent skills' that let OpenCode discover reusable instructions from a repo or home directory (docs-8/28), which suggests some mechanism for project-level guidance, but no evidence explicitly describes a dedicated instructions/config file (e.g., AGENTS.md) for coding standards and conventions. Missing for 10: explicit documentation of a project instructions file format, guidance on writing coding-standards content into it, and independent/hands-on confirmation that the agent actually follows such a file.
- [claimed-docs] “initialize OpenCode for the project by running the following command.”
- [claimed-docs] “Next, initialize OpenCode for the project by running the following command.”
- [claimed-docs] “initialize OpenCode for the project by running the following command”
- [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
- [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory.”
Docs mention 'General preferences' that 'apply broad instructions to agents in a repository,' which is the closest match to a project instructions/conventions file, but there is no detail on file format, location, or how it maps to underlying agents' native instruction files (e.g., CLAUDE.md). Missing for 10: documentation of the actual file/config mechanism, examples of setting coding standards, and independent confirmation it works across all supported agents (Claude Code, Codex, Cursor, OpenCode).
- [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
Issue diagnosis
developerReproduce issues, narrow down root causes, and verify fixes
weight 3 · round to ConductorOpenCode's general coding-agent capabilities (shell/tool execution, LSP integration, a read-only 'explore' agent, and a 'plan' agent for analysis without changes) imply support for investigating bugs and iterating on fixes, and community feedback confirms strong LSP-based codebase navigation. However, there is no explicit documentation of a reproduce/debug/verify workflow, test running, or root-cause tooling, and community reports cite failed tool calls and agents getting stuck on long sessions, undermining reliability for this exact workflow. Missing for 10: explicit debugging/test-execution documentation, first-party guidance on reproducing bugs or verifying fixes, and independent hands-on confirmation of successful root-cause workflows.
- [claimed-docs] “A fast, read-only agent for exploring codebases.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
Conductor provides isolated worktrees/workspaces where agents can run builds, tests, and setup scripts (conductor-docs-17, conductor-docs-32, conductor-docs-29), diff/PR review paths to verify fixes (conductor-docs-2, conductor-docs-21), and checkpoints to revert code/chat state when narrowing down a bad change (conductor-docs-18). These features support the reproduce→diagnose→verify loop, but the evidence is all first-party docs describing environment/orchestration features rather than direct debugging tooling (log inspection, stack traces, targeted bisection) or independent hands-on accounts of successfully reproducing/root-causing a bug. missing for 10: dedicated debugging/log-inspection features, independent user reports of using Conductor to isolate root causes or verify fixes end-to-end.
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Checkpoints | Session/workspace | Revert code and chat state to an earlier turn”
- [claimed-docs] “Search file contents in your current local project or cloud workspace with ⌘⇧F.”
Ecosystem — integrations, plugins, and third-party ecosystem storiesEcosystem
Integrations, plugins, and third-party ecosystem stories
Marketplace
developerEquip the agent with custom skills to perform specialized tasks
weight 1 · round to OpenCodeOpenCode has a dedicated 'Agent Skills' feature that lets it discover reusable, on-demand instructions from repo or home directory via a native `skill` tool, directly matching the custom-skills story, and this is corroborated by community praise for its subagents/customizability. Missing for 10: no independent hands-on report specifically testing custom skill authoring/loading, and no detail on skill packaging/sharing ecosystem.
- [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
- [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory.”
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
Conductornone0/10Conductor orchestrates existing coding agents (Claude Code, Codex, Cursor, OpenCode) and offers 'general preferences' for broad instructions, but there's no evidence of a custom skills/plugin/tool system for equipping agents with specialized capabilities; a community request even notes the lack of 'custom tools' in its menu (conductor-comm-2).
- [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
- [community] “It'd be great to change the default branch used for creating new workspaces. I'd like the ability to add custom tools to the 'Open in...' me…”
engineering-leadIntegrate third-party partner-built agent apps into my workflows
weight 1 · round to ConductorOpenCode supports MCP (local/remote servers) to add external tools, has an SDK/headless server for programmatic integrations, and GitHub Actions integration—these enable connecting third-party agent apps/tools into workflows. However, there's no evidence of a curated partner marketplace or vendor-vetted third-party 'agent apps' ecosystem beyond generic MCP/tool integration. missing for 10: a documented partner/marketplace ecosystem of pre-built third-party agent apps, case studies of integrating named partner agents, and independent verification of such integrations working smoothly.
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
Conductor natively integrates several third-party agent apps (Claude Code, Codex, Cursor, OpenCode) into its parallel-workspace workflow, with per-org connection configuration and subscription/API-key support, and even exposes its own MCP server so other agent clients can manage workspaces. However, community feedback shows requests for additional partners (Gemini CLI, Amazon Q) that aren't yet supported, indicating a fixed rather than open/extensible partner ecosystem. Missing for 10: an open plugin/marketplace model for arbitrary partner agents, and independent confirmation of seamless integration beyond the listed agents.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
- [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
- [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”
Team knowledge
engineering-leadCreate a shared workspace from my docs and repos as a common source of truth for the team
weight 1 · round to ConductorOpenCodenone0/10OpenCode offers session share links, repo-based 'agent skills', and enterprise SSO/config, but there is no evidence of a dedicated shared workspace feature that ingests both docs and repos into a common, persistent team source of truth — these are separate, ad-hoc mechanisms rather than a unified workspace.
Conductor's cloud workspaces are shared with the whole organization and teammates can follow, reassign, or pick up the same workspace/chat, giving some sense of a shared team space tied to a repo (conductor-docs-24, conductor-docs-25, conductor-docs-16). However, there's no evidence of a workspace built from 'docs' (knowledge base, wiki, or design docs) alongside repos, or of any feature explicitly positioned as a team 'source of truth' beyond per-repo agent preferences. missing for 10: docs ingestion/aggregation into a workspace, explicit source-of-truth knowledge base feature, independent corroboration of team-wide shared-workspace usage.
- [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
- [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
- [claimed-docs] “Right-click the workspace and choose **Reassign to** to make a teammate responsible for it.”
- [claimed-docs] “`General preferences` apply broad instructions to agents in a repository.”
Tool integration
developerConnect the agent to workflow tools like Jira, Slack, and Google Drive to extend its context
weight 3 · round to OpenCodeOpenCode supports MCP for adding external tools (local and remote servers), which is the generic mechanism by which one could connect Jira/Slack/Google Drive-type integrations, but there is no direct first-party or community evidence of specific Jira, Slack, or Google Drive connectors or integrations. missing for 10: named first-party or community-verified MCP servers/integrations for Jira, Slack, or Google Drive specifically, and any evidence of workflow-tool context extension beyond generic MCP support.
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”
developerKick off agent tasks directly from GitHub, GitLab, Linear, or Slack
weight 2 · round to ConductorOpenCode has documented GitHub integration where mentioning /opencode or /oc in a comment triggers tasks in GitHub Actions, including issue-to-PR workflows, but there is no evidence of native GitLab, Linear, or Slack integrations for kicking off agent tasks. missing for 10: GitLab integration, Linear integration, Slack integration, independent hands-on confirmation of the GitHub Actions flow working reliably.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
Conductor lets you create a workspace (kick off an agent task) from a GitHub branch, pull request, GitHub issue, or Linear issue, and can trigger agent runs via GitHub Actions/scheduled routines, but there is no evidence of GitLab or Slack integration for starting tasks. missing for 10: GitLab task-kickoff support, Slack task-kickoff support, and independent confirmation of these triggers working in practice.
- [claimed-docs] “Use Command + Shift + N or the `...` button next to `New workspace` to create a workspace from a branch, pull request, GitHub issue, or Line…”
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
Ide terminal integration — meeting you in the IDE and terminal — extensions, inline flows, contextIde terminal integration
Meeting you in the IDE and terminal — extensions, inline flows, context
Cross device continuity
developerStart a task on one device and continue it later from another device or browser
weight 2 · round drawnOpenCode supports remote/headless usage via `opencode serve` plus a TUI that can connect to a remote backend, share links for sessions, and a WebUI that can connect to multiple backends from anywhere (including mobile), which enables cross-device continuation of a session. However, this requires manual server setup rather than seamless native cloud sync, and community reports note bugs restoring session state and provider/model selection issues across sessions. missing for 10: first-party seamless cross-device sync without self-hosting a server, official mobile app, and clear documentation/evidence of resuming full task state (not just session sharing) across devices.
- [claimed-docs] “This allows using the TUI with a remote OpenCode backend.”
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
Cloud workspaces are shared with the organization and support handoff via 'Reassign to' and shared links, so a teammate (or the same developer on another device) can open a workspace and pick up where they left off, and cloud agents keep working after the laptop closes. However, evidence is framed around team collaboration/handoff rather than explicit single-user cross-device continuity, and local (non-cloud) workspaces are tied to the machine's worktree. missing for 10: explicit documentation of the same developer resuming a *local* task from a different device, confirmation of seamless single-user cross-browser/device session continuity, and independent hands-on confirmation of this specific workflow.
- [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
- [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
- [claimed-docs] “The link opens the workspace in Conductor for any member of the organization.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “Following is useful when someone else is assigned to the workspace but you want to keep it in your workflow.”
Ide integration
developerView interactive diffs and share selected code as context from within my JetBrains IDE
weight 1 · round drawnOpenCodenone0/10Evidence only shows OpenCode integrating with VS Code, Cursor, or 'any IDE that supports a terminal' via keyboard shortcuts for split-terminal view and inserting file references; there is no mention of a JetBrains-specific plugin, interactive diff viewer, or JetBrains context-sharing UI. missing for 10: JetBrains plugin/extension documentation, interactive diff rendering inside JetBrains, JetBrains-specific 'share selected code' mechanism.
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
- [claimed-docs] “Use Cmd+Esc (Mac) or Ctrl+Esc (Windows/Linux) to open OpenCode in a split terminal view”
- [claimed-docs] “Use Cmd+Option+K (Mac) or Alt+Ctrl+K (Linux/Windows) to insert file references.”
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal.”
- [claimed-docs] “Use `Cmd+Esc` (Mac) or `Ctrl+Esc` (Windows/Linux) to open OpenCode in a split terminal view”
- [claimed-docs] “Use `Cmd+Option+K` (Mac) or `Alt+Ctrl+K` (Linux/Windows) to insert file references.”
Conductornone0/10Conductor is presented as a standalone Mac app with its own workspace/diff/terminal UI (conductor-docs-2, conductor-probe-1), not a JetBrains IDE plugin; none of the docs, changelog, or community threads mention any JetBrains integration, extension, or plugin for viewing diffs or sharing context from within a JetBrains IDE.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
developerChat with the coding assistant directly inside my IDE for contextual help
weight 3 · round to OpenCodeOpenCode ships an IDE extension and integrates directly in VS Code/Cursor with in-editor shortcuts (split terminal view, file-reference insertion) for contextual chat, and community users confirm using it as their daily coding harness with LSP integration inside editors. Missing for 10: independent hands-on review specifically of the IDE-extension chat UX (most community feedback is TUI/CLI-focused) and no screenshots/deep detail on in-IDE chat UI beyond shortcuts.
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
- [claimed-docs] “Any editor Available as a terminal interface, desktop app, and IDE extension”
- [claimed-docs] “Use Cmd+Esc (Mac) or Ctrl+Esc (Windows/Linux) to open OpenCode in a split terminal view”
- [claimed-docs] “Use Cmd+Option+K (Mac) or Alt+Ctrl+K (Linux/Windows) to insert file references.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
Conductor provides each task/workspace its own chat, terminal, diff and review path directly alongside the running coding agent (Claude Code, Codex, Cursor, OpenCode), letting a developer converse with the assistant in context of their code (conductor-docs-2, conductor-docs-27). Community reports confirm the chat works locally against Claude Code with no meaningful complaint about chat context/quality beyond stylistic preference (conductor-comm-9, conductor-comm-15). Missing for 10: no evidence of a native plugin embedding this chat inside third-party IDEs like VS Code/JetBrains (it's a separate Mac app), and no independent hands-on review of contextual-help quality beyond one HN thread.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
- [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”
Session management
developerReview diffs visually and run multiple sessions side by side in a desktop app
weight 2 · round to ConductorOpenCode has a documented desktop app with tabs (opencode-docs-19) and multi-session support to run multiple agents in parallel (opencode-docs-17/38), plus session share links; existence of the desktop app is also confirmed on GitHub (opencode-gh-1). However, there is no evidence describing a visual diff-review UI in the desktop app specifically — docs focus on TUI/terminal split views and file references rather than a diff viewer. Missing for 10: explicit documentation or screenshots of a visual diff/code-review interface in the desktop app, and independent/hands-on confirmation of side-by-side session usage in that app.
- [claimed-docs] “Introducing tabs for desktop. Available on macOS, Windows, and Linux.”
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [github] “OpenCode is also available as a desktop application.”
- [claimed-docs] “Any editor Available as a terminal interface, desktop app, and IDE extension”
Conductor is a native desktop (Mac) app that runs multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each in its own workspace/branch/worktree with a dedicated diff and review path before opening a PR, and community users independently confirm the git-worktree-based parallel session model. Missing for 10: independent hands-on evaluation specifically praising the visual diff-review UI's quality/UX (only vendor docs describe the diff view) and no screenshots/video corroboration.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
- [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
engineering-leadManage multiple agent-driven coding sessions from one unified workspace
weight 2 · round drawnOpenCode explicitly supports multi-session workflows ('Start multiple agents in parallel on the same project'), tabs for desktop, share links for sessions, and a headless server that a WebUI can connect to across multiple backends, which community evidence corroborates ('WebUI... can connect to multiple OpenCode backends at once'). This directly matches an engineering-lead managing multiple agent sessions from one unified workspace. Missing for 10: no first-party documentation of team/organization-level oversight (e.g., viewing/managing sessions started by other engineers) and some reported bugs in session state restoration temper reliability.
- [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
- [claimed-docs] “Introducing tabs for desktop. Available on macOS, Windows, and Linux.”
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
- [claimed-docs] “Share links Share a link to any session for reference or to debug”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
Conductor is explicitly built as a unified workspace for running multiple coding agents (Claude Code, Codex, Cursor, OpenCode) in parallel, each with its own workspace/branch/terminal/diff, plus team collaboration features (reassign, follow, shared workspaces) that support engineering-lead oversight. Community hands-on posts corroborate the parallel-agent workflow, though some raised concerns about permissions/data practices unrelated to the core multi-session management claim. missing for 10: independent lead-level testimony specifically on cross-team oversight at scale, and clearer evidence of a dashboard view aggregating all sessions' status for a lead.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “Workspaces and chats are shared with your organization, so a teammate can open the same workspace, follow the same conversation, and pick up…”
- [claimed-docs] “browse everyone's work in **Home**, contribute to a teammate's chat, follow workspaces you care about, and hand work off with **Reassign to*…”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “I have been imagining something like this would be perfect for working with Claude Code... This feels like just a nice clean simple extensio…”
- [community] “Oh cool, I was already doing this with git worktrees but a ui for it would be handy.”
Terminal workflow
developerRun a coding agent locally from my terminal
weight 3 · round to OpenCodeOpenCode is explicitly a terminal-based coding agent, installable via curl/npm, run with `opencode` command in any terminal, with rich CLI docs and confirmed hands-on community usage as a daily local terminal harness. Missing for 10: no independent benchmark/security audit fully vetting the terminal experience beyond anecdotal reports (some report TUI compatibility bugs on specific setups).
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
- [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal.”
- [probe] “official CLI documented at https://opencode.ai/docs/cli/”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
Conductor documents running local coding agents (Claude Code, Codex, Cursor, OpenCode) with per-task local git worktrees and a dedicated terminal per workspace, and community confirms it runs the agent locally via the local CLI/SDK install (conductor-comm-15, conductor-comm-17). However, hands-on reports show it isn't a pure lightweight local terminal wrapper—it requires GitHub OAuth/cloning rather than just running an existing local repo, and some users complain the local CLI 'feel' (e.g., Claude Code's native terminal UX) is lost inside Conductor's GUI (conductor-comm-6, conductor-comm-9). Missing for 10: independent confirmation that pure terminal-only (non-GUI) workflows are fully supported, and clearer first-party disclosure addressing the community concerns about local vs. cloud/GitHub dependency.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “Your messages are just between you and Claude Code — it all runs on your local Claude Code installation via the SDK.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
- [community] “I was really excited to try this but this does NOT work the way I expected. I wanted a simple git worktree manager for my existing, already-…”
- [community] “There's a 'feel' to the way Claude Code outputs the text. And for input as well. Sadly, this is lost with conductor. I just don't feel as jo…”
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
developerRun the agent non-interactively in scripts for workflow automation
weight 2 · round to OpenCodeThe `opencode run` CLI command explicitly supports non-interactive one-shot execution (e.g. `opencode run "Explain how closures work"`), and `--auto` flag auto-approves permissions for unattended runs, plus `opencode serve` exposes a headless HTTP/OpenAPI server and JS/TS SDK for scripted/programmatic control, all fitting workflow automation. Missing for 10: independent hands-on evidence of non-interactive scripting reliability/CI use, and no dedicated exit-code/output-format docs for pipeline integration.
- [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”
Conductor exposes a programmatic API to create workspaces, send prompts and read agent replies, and supports 'routines' to run agents on a schedule or via GitHub Action, which enables non-interactive, scripted automation of the agent outside the GUI. However, this is all first-party documentation with no independent/hands-on confirmation, and Conductor is fundamentally a GUI-first Mac app rather than a CLI tool built for scripting. Missing for 10: independent verification that the API/routines work reliably in real automation pipelines, and clearer CLI-style invocation/flags for non-interactive use.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [claimed-docs] “Introducing routines! You can now run your agents on a schedule or via GitHub action.”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round to OpenCodeOpenCode ships a headless server (`opencode serve`) exposing a documented OpenAPI spec (confirmed live at openapi.json) plus a JS/TS SDK explicitly for 'building integrations and controlling opencode programmatically,' and the TUI/WebUI can drive a remote backend — community confirms this works day-to-day including from mobile. However, no evidence explicitly enumerates full feature parity (e.g., agent skill management, permission config, enterprise SSO settings) as exposed via the API/SDK, and there's no independent audit confirming 1:1 UI/API parity. missing for 10: explicit parity documentation covering all UI-only features (skills, permission prompts, enterprise SSO), independent verification of full API coverage.
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [claimed-docs] “Use it to build integrations and control opencode programmatically.”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
- [claimed-docs] “This allows using the TUI with a remote OpenCode backend.”
- [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
Conductor documents a programmatic API and a hosted MCP server that let you create cloud workspaces, send prompts, and read agent replies, giving genuine API access to core agent workflows (conductor-docs-13, conductor-docs-14, conductor-docs-30, conductor-probe-4). However, the API is explicitly scoped to 'cloud workspaces' only, with no evidence it exposes local workspace/worktree management, collaboration features (reassign, follow, sharing), settings like port forwarding, or UI-specific conveniences (loadouts, sections, checkpoints) — and no OpenAPI spec is discoverable (conductor-probe-3), suggesting the API surface is narrower than the full UI. missing for 10: full parity coverage of local workspace/git-worktree operations via API, coverage of collaboration/organization features via API, and a public OpenAPI spec or independent confirmation of API completeness.
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically. Use it to do things like: Create workspaces, send prompts to the coding…”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
- [probe] “PROBE openapi: all candidate paths 404 (https://www.conductor.build/openapi.json, https://www.conductor.build/swagger.json, https://www.cond…”
ai-native userExport all of my data in open formats and leave
weight 3 · round drawnOpenCodenone0/10No evidence describes an explicit data-export feature or open-format portability guarantee for OpenCode; while it is open-source and stores config/sessions locally, there's no documented 'export all my data and leave' capability, and community threads even note telemetry sent to OpenCode's own servers with no way to disable it (opencode-comm-2), undercutting a clean data-portability story.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
- [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
- [claimed-docs] “Share links Share a link to any session for reference or to debug”
Conductornone0/10Conductor stores workspace state, chat history, and cloud workspace data, but no evidence in the pack shows an explicit data-export feature or open-format export guarantee; while code lives in git worktrees (inherently portable), there's no documentation of exporting chats, settings, or cloud workspace metadata. Community threads even raise unresolved concerns about data practices and lack of transparency (conductor-comm-3, conductor-comm-5), reinforcing the absence of an export/leave story.
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
ai-native userRead the product's source under an open license
weight 2 · round to OpenCodeOpenCode's docs explicitly describe it as "open source" and a public GitHub repo exists (opencode-gh-1), and community members confirm they read and learned from the actual source code (opencode-comm-6), corroborating that the source is genuinely accessible. missing for 10: explicit citation of the license name/type (e.g., MIT/Apache) in the evidence pack, and a first-party statement pointing to the license file itself.
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
- [github] “OpenCode is also available as a desktop application.”
- [community] “OpenCode source code is even more awesome. I have learned so much from the way they have organized tools, agents, settings and prompts. mode…”
Conductornone0/10There is no evidence Conductor's source is available under any open license; it is distributed as a compiled Mac app with docs/API only, and a community comment explicitly contrasts it with an open-source alternative ('Crystal... unlike Conductor is open source'), indicating Conductor's source is not open.
- [community] “Crystal can do all of this and more, and unlike Conductor is open source.”
ai-native userSelf-host the core product
weight 3 · round to OpenCodeOpenCode is open source and installable via CLI, with a documented `opencode serve` headless HTTP server exposing an OpenAPI endpoint, plus SDK and remote/TUI client support, enabling full self-hosting of the core agent; community evidence confirms real-world self-hosted use ('opencode serve' accessible remotely) though also flags security hardening gaps around the server. missing for 10: independent audit confirming production-grade self-hosted security, and clearer official self-hosting/deployment guide beyond the serve command docs.
- [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”
- [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
- [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
- [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
- [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”
Conductornone0/10Conductor is a proprietary Mac app with a hosted cloud service and API/MCP server; there is no evidence of a self-hostable core product—no open-source repo, on-prem deployment option, or self-hosting docs are mentioned. Community even contrasts it unfavorably with 'Crystal,' which is explicitly noted as open source unlike Conductor, reinforcing that self-hosting isn't offered.
- [community] “Crystal can do all of this and more, and unlike Conductor is open source.”
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Authentication
developerAuthenticate with an API key instead of an account login
weight 2 · round to OpenCodeOpenCode explicitly supports configuring API keys for any LLM provider as an alternative to logging in via account-based options like GitHub Copilot or ChatGPT Plus/Pro, giving developers a direct API-key auth path rather than requiring account login. Missing for 10: independent hands-on confirmation of the API key setup flow itself and details on key storage/security beyond docs claims.
- [claimed-docs] “With OpenCode you can use any LLM provider by configuring their API keys.”
- [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
- [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [claimed-docs] “OpenCode Zen is a list of tested and verified models provided by the OpenCode team.”
Conductor explicitly supports 'bring your own subscriptions and keys' and lets you configure Claude Code, Codex, and Cursor connections to use an API key instead of a subscription/account login per organization. This directly satisfies the developer's need to authenticate via API key rather than an account login flow. missing for 10: independent/hands-on confirmation that API-key auth works end-to-end without any account sign-in step, and detail on whether Conductor's own app access also supports API-key-only login (vs. GitHub OAuth).
- [claimed-docs] “Bring your own subscriptions and keys”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
engineering-leadAuthenticate through an enterprise identity or cloud platform for compliance and scalability
weight 2 · round to OpenCodeOpenCode has a documented enterprise config that integrates with SSO and enforces a centralized internal AI gateway, directly addressing enterprise identity/compliance needs, and supports login via GitHub Copilot/OpenAI accounts. However, there's no independent corroboration of this enterprise SSO feature in practice, no detail on supported identity providers (SAML/OIDC specifics), and community discussion focuses on telemetry/security concerns rather than confirming enterprise auth workflows. Missing for 10: independent/hands-on validation of SSO integration, details on supported IdPs, and evidence of enterprise customers actually using this for compliance/scalability.
- [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
- [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
- [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
Conductornone0/10Evidence shows only GitHub OAuth/GitHub App authentication and per-organization agent connection settings (conductor-comm-13, conductor-comm-14, conductor-docs-23); there is no mention of SSO, SAML, OIDC, or enterprise identity provider integration for compliance/scale. missing for 10: SSO/SAML/OIDC support, enterprise IdP integration, admin/compliance controls tied to identity.
- [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
developerSign in with my existing product subscription plan to use the coding agent
weight 2 · round drawnOpenCode docs explicitly support signing in with existing subscriptions—GitHub Copilot and ChatGPT Plus/Pro—rather than requiring separate API keys, and community comments confirm using subscriptions (e.g., Codex $200/mo) inside OpenCode. Missing for 10: independent hands-on verification of the Copilot/ChatGPT login flow itself and broader coverage of other subscription providers beyond these two.
- [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
- [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [claimed-docs] “GitHub Copilot Log in with GitHub to use your Copilot account”
- [claimed-docs] “ChatGPT Plus/Pro Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [community] “OpenCode is awesome. Claude Code is nothing special at all. Last month I switched to just using OpenCode with a Codex $200/mo subscription, …”
Docs explicitly state you can 'bring your own subscriptions and keys' and sign in with existing Cursor, Claude Code, or Codex subscriptions rather than requiring a separate Conductor-specific plan, with per-organization control over subscription vs API key. Missing for 10: independent hands-on confirmation that subscription sign-in works smoothly across all supported agents (only vendor changelog/docs evidence).
- [claimed-docs] “Bring your own subscriptions and keys”
- [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
developerSign in with a personal account to get free-tier access without managing API keys
weight 1 · round to OpenCodeOpenCode's docs explicitly offer 'Log in with GitHub to use your Copilot account' and 'Log in with OpenAI to use your ChatGPT Plus or Pro account,' letting a developer authenticate with an existing personal subscription instead of managing provider API keys, and OpenCode Zen is noted to include a free coding model. Missing for 10: independent/hands-on user reports specifically confirming this login flow (community comments focus on API keys/local models, not the Copilot/ChatGPT login path), and clarity on any usage limits tied to the free tier.
- [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
- [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [claimed-docs] “GitHub Copilot Log in with GitHub to use your Copilot account”
- [claimed-docs] “ChatGPT Plus/Pro Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [community] “OpenCode source code is even more awesome. I have learned so much from the way they have organized tools, agents, settings and prompts. mode…”
Conductornone0/10Conductor's docs describe a 'bring your own subscriptions and keys' model where users must sign in to their own Claude Code, Codex, or Cursor subscription or supply an API key (conductor-docs-19, conductor-docs-23, conductor-docs-7); there is no mention of a free tier accessible purely via personal account sign-in without managing credentials. Community discussion also focuses on GitHub OAuth/permissions issues, not a free-tier access model.
- [claimed-docs] “Bring your own subscriptions and keys”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
- [claimed-docs] “Sign in to your Cursor subscription for cloud workspaces.”
Model choice
developerLet the tool automatically pick the best model for each task
weight 1 · round drawnOpenCodenone0/10Evidence shows OpenCode supports many providers/models and lets users manually assign a model per agent or switch via Tab, but nothing indicates the tool automatically selects the optimal model for a given task — community feedback even confirms model/provider choice is manual and sometimes annoying to manage across sessions.
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
- [claimed-docs] “You can use the Tab key to switch between primary agents during a session.”
- [claimed-docs] “75+ LLM providers through Models.dev, including local models”
Conductornone0/10Conductor documents manual model selection via 'loadouts' and keyboard shortcuts to switch between chosen models, but there is no evidence of an automatic mechanism that picks the best model per task based on cost/performance tradeoffs.
- [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
developerChoose which underlying AI model powers my session from multiple providers
weight 2 · round to OpenCodeOpenCode explicitly supports configuring any LLM provider via API keys, lists 75+ providers through Models.dev including local models, offers a curated OpenCode Zen model list, and supports logging in with GitHub Copilot or ChatGPT Plus/Pro accounts. Community evidence corroborates real-world use with multiple providers (Claude, Gemini, local llama.cpp, Qwen) and per-agent model selection. Missing for 10: some community reports note model/provider switching across sessions can be buggy or annoying, a minor UX caveat.
- [claimed-docs] “With OpenCode you can use any LLM provider by configuring their API keys.”
- [claimed-docs] “OpenCode Zen is a list of tested and verified models provided by the OpenCode team.”
- [claimed-docs] “75+ LLM providers through Models.dev, including local models”
- [claimed-docs] “Any model 75+ LLM providers through Models.dev, including local models”
- [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
- [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
- [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
- [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
- [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
- [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
Conductor explicitly supports running Claude Code, Codex, Cursor, and OpenCode as interchangeable providers, with a 'loadout' UI and keyboard shortcuts to switch models per session, plus per-organization configuration of API key vs subscription for each provider. Community comments confirm interest in and some support for multi-agent/provider use, though no independent hands-on review specifically validates seamless mid-session switching. Missing for 10: independent/hands-on verification of the model-switching UX and confirmation across all listed providers beyond vendor docs.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Pick a loadout of your favorite models to quickly switch between. It’s keyboard accessible too: change models (⌃⌘ 1-5), effort (⌘⇧/), speed …”
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
- [community] “Love the design. does it build on electron? and will it support other code agents, like gemini cli, codex, opencode ext.”
- [community] “Would be cool if I can use this with opencode, Amazon Q or whatever. I reckon the logic would be quite similar. Seen a few of these tools bu…”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round drawnOpenCodenone0/10No evidence anywhere in the pack of a region/residency selection feature for data storage; OpenCode's docs focus on provider choice, self-hosting, and enterprise SSO, none of which address data residency. In fact, community reports indicate telemetry is always sent to OpenCode's own servers with no way to disable it, further suggesting the user lacks control over where certain data goes.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
Conductornone0/10No evidence anywhere in the pack addresses data residency, region selection, or storage location controls for cloud workspaces; community comments even highlight lack of disclosure about where data is sent.
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
ai-native userPrevent my data from being used to train AI models
weight 3 · round drawnOpenCodenone0/10The evidence pack contains no documentation of any setting, policy, or opt-out mechanism for preventing user data/code from being used to train AI models (OpenCode's docs focus on providers, agents, permissions, IDE integration, etc., none addressing training-data usage). Community evidence actually suggests the opposite direction of concern: telemetry is sent to OpenCode's own servers even with locally-hosted models with no way to disable it, which further undermines confidence that user data is protected from being retained/used.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
Conductornone0/10No documentation or policy statement anywhere in the evidence pack addresses training-data opt-out or data-usage controls; in fact community reports explicitly note 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' underscoring the absence of any such privacy control.
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
ai-native userControl data retention and deletion
weight 2 · round drawnOpenCodenone0/10No documentation describes any data retention or deletion controls, and community evidence indicates the opposite: OpenCode sends telemetry to its own servers even with local models, with no environment variables or flags to disable it, suggesting no user-facing data controls exist.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
Conductornone0/10No documentation describes retention periods, data-deletion controls, or export/purge mechanisms for cloud workspace data; community feedback explicitly flags 'zero disclosure of data practices' and no way to verify what is sent to Conductor's servers.
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
- [claimed-docs] “The Conductor API lets you manage cloud workspaces programmatically.”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round to OpenCodeOpenCodedisputedcontradicted2/10OpenCode's docs make no mention of a telemetry opt-out setting, and a community report explicitly states OpenCode sends telemetry to its own servers even with locally hosted models, with no environment variables, flags, or config options to disable it. This is a first-party-vs-hands-on-evidence conflict: no documented opt-out mechanism exists, and independent evidence claims none is available. missing for 10: any official docs describing a telemetry toggle/opt-out, first-party acknowledgment of telemetry collection, and any evidence the reported issue was fixed.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
Conductornone0/10No documentation or changelog entry describes any telemetry/usage-tracking settings or an opt-out mechanism; community commenters explicitly note there is 'no way to find out if there's any data sent to your servers' and 'zero disclosure of data practices,' confirming the absence of any documented privacy control for telemetry.
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
Review safety — keeping generated changes safe — diffs, approvals, guardrailsReview safety
Keeping generated changes safe — diffs, approvals, guardrails
Data governance
engineering-leadOpt out of having my code and prompts used for AI model training
weight 1 · round drawnOpenCodenone0/10No documentation exists describing a training-data opt-out or data-use policy for prompts/code; in fact community evidence indicates OpenCode sends telemetry to its own servers with no way to disable it, even when using local models, suggesting the opposite of user control over data usage.
- [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
Conductornone0/10No evidence anywhere in the pack of a data-usage/training opt-out policy or setting; in fact community reports explicitly complain about 'zero disclosure of data practices' and no way to find out what is sent to Conductor's servers, reinforcing the absence of any documented opt-out mechanism.
- [community] “Love it! Even just simply freeing my main branch would be a big win so I can keep working as well. But no way to find out if there's any dat…”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
Pr review
developerHave the agent stage changes, write commit messages, create branches, and open pull requests
weight 3 · round to ConductorDocs explicitly describe GitHub integration where OpenCode 'will work in a new branch and submits a PR with all the changes' and can execute tasks via mentions in GitHub Actions, covering branch creation and PR opening; permission config also governs whether actions like git operations auto-run or prompt. However, there's no explicit mention of staging changes or generating commit messages as a distinct capability, and no independent/community evidence corroborates the PR-creation workflow in practice. missing for 10: explicit documentation of commit message generation/staging step, independent hands-on verification of the branch+PR workflow.
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
Docs explicitly state each task gets its own branch/worktree, agents can be given autonomy to test/build without confirmation, and Conductor 'helps you review the diff, open a pull request, merge, and archive the workspace' — covering branch creation, staging/commits (implied by agent workflow), diffs, and PR creation. Community evidence corroborates git worktree branch isolation and GitHub integration for PR workflows. Missing for 10: explicit first-party mention of 'commit message writing' as a distinct feature and independent hands-on confirmation of the full stage→commit→branch→PR pipeline working end-to-end.
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “Create a new workspace with Command + N when work should have its own branch, files, running environment, and review path.”
- [claimed-docs] “Conductor creates a separate working tree for each workspace. That lets agents work in parallel without editing the same files on disk.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
developerGet automatic code review with contextual feedback on every pull request
weight 3 · round to OpenCodeOpenCode has a GitHub Actions integration (mention /opencode or /oc in a comment) and a read-only 'plan' agent that can review/suggest changes without modifying code, which can be used for PR feedback, but this requires an explicit manual mention rather than automatically triggering contextual review on every PR. Missing for 10: documented automatic/triggerless review on every new PR, evidence of inline contextual comments on diffs, and independent confirmation of this review workflow in practice.
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
- [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
Conductornone0/10Conductor's evidence describes parallel agent orchestration, diffs, and human-facing review workflows (e.g., 'Conductor helps you review the diff, open a pull request' and PR comments loading from GitHub) but no automated code-review bot that posts contextual feedback on pull requests. No evidence of an AI reviewer analyzing PR diffs and commenting automatically.
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
developerInspect diffs and run checks to catch problems before merging
weight 3 · round to ConductorOpenCode offers a read-only 'plan' agent for reviewing suggested changes without applying them and a permission system that can prompt before actions run, plus GitHub PR/Actions integration for submitting changes — these provide some review-safety scaffolding. However there is no documented diff-viewing UI or built-in test/lint/check-running capability before merge. Missing for 10: explicit diff inspection tooling, integrated test/lint/CI check execution, and independent evidence that these safety mechanisms actually prevent bad merges.
- [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
- [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
- [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
- [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
Docs show each workspace has its own diff and review path, and Conductor explicitly helps you 'review the diff, open a pull request, merge' before finishing work, plus it surfaces PR comments and failing-check logs even while a cloud workspace sleeps, and agents can run builds/tests as part of setup. However, there's no detailed description of built-in linting/test-runner integration beyond agent-run builds, and no independent/hands-on confirmation that this catches real problems pre-merge. Missing for 10: dedicated CI/check-running feature docs, independent verification of diff/check accuracy, and coverage of how failing checks block or warn before merge.
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [claimed-docs] “When the work is ready, Conductor helps you review the diff, open a pull request, merge, and archive the workspace.”
- [claimed-docs] “PR comments and failing-check logs now load while a cloud workspace is asleep.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [claimed-docs] “You can also have an agent configure the computer for you: it can test your repositories, edit setup scripts, and run builds.”
Safe execution
engineering-leadControl which external tools and integrations the agent is allowed to access
weight 2 · round to OpenCodeOpenCode's permission system lets leads set actions to auto-run, prompt, or block per tool/input, and MCP servers (external tools) are explicitly added/configured (docs-4/23/41). Enterprise config also lets orgs force use of an internal AI gateway and SSO, further restricting what integrations agents can reach (docs-33/50). Missing for 10: independent/hands-on confirmation that permission rules reliably block disallowed MCP tool calls in practice, and finer detail on allow/deny lists for specific external tool names beyond the general permission object.
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “OpenCode uses the permission config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “For most permissions, you can use an object to apply different actions based on the tool input.”
- [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”
- [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
- [claimed-docs] “Through the central config, OpenCode can integrate with your organization’s SSO provider for authentication.”
Conductor lets an org configure agent connections per organization (choosing API-key vs subscription per agent) and, after community pushback over full GitHub OAuth access, added fine-grained GitHub repository permissions or local GitHub CLI auth as an alternative [conductor-docs-23, conductor-comm-13, conductor-comm-14]. However there's no documented allow-list/deny-list for arbitrary external tools, MCP servers, or third-party integrations beyond GitHub scopes and model provider choice, and the initial full-write-access design (comm-4, comm-5, comm-6) shows the control was originally coarse and only partially remedied. missing for 10: granular per-tool/integration allow-listing beyond GitHub and model provider, admin-level policy enforcement across the org, and independent verification that fine-grained access covers all agent-invoked external services (e.g., MCP servers).
- [claimed-docs] “Configure cloud agent connections separately for each organization, and choose whether Claude Code, Codex, and Cursor use an API key or subs…”
- [community] “Any way to have it not require full write access to your entire GitHub account?”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
- [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
engineering-leadHave the agent operate inside a sandbox when interacting with code, tools, and network resources
weight 2 · round to ConductorOpenCodenone0/10OpenCode's documentation only describes a permission system (auto-approve/prompt/block) and an 'external_directory' toggle for path access — not an isolated sandbox for code execution, tool calls, or network access. Community evidence (opencode-comm-18) even flags that the local server mode allows any local process or webpage to execute code without authentication, the opposite of sandboxed isolation, and there is no first-party claim of container/VM-based sandboxing to dispute.
- [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
- [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
- [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
- [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”
Conductor's cloud workspaces are explicitly described as spinning up in "sandboxes" and the agent can run builds/tests without step-by-step confirmation, suggesting isolated execution for cloud mode. However, the local mode (the primary use case per community feedback) uses plain git worktrees on the user's own machine with no described network/tool sandboxing, and early versions required full read-write GitHub account access with no disclosed data practices, which is the opposite of a hardened sandbox model (though later mitigated with fine-grained GitHub App permissions). Missing for 10: explicit sandbox isolation details (container/VM boundaries, network egress controls) for local workspaces, and independent confirmation that cloud sandboxes restrict network/tool access beyond marketing language.
- [claimed-docs] “Sandboxes spin up in seconds, and agents keep working after you close your laptop.”
- [claimed-docs] “The agent can test your repositories, update install and setup scripts, and run builds — without asking you to confirm each step.”
- [community] “We create an isolated git worktree locally on your machine — whereas Codex (I believe) is running a container on the cloud.”
- [community] “Any way to have it not require full write access to your entire GitHub account?”
- [community] “Full read-write access required to all your Github account's repos. Not just code. Settings, deploy keys. The works... Zero disclosure of da…”
- [community] “Right now the app uses GitHub's OAuth sign in which unfortunately doesn't allow for fine-grained permissions... We're switching our sign-in …”
- [community] “Fixed! You can now give Conductor fine-grained GitHub repository access. Or, skip the integration and use your local GitHub CLI auth.”
Security checks
engineering-leadSee license and public-code matching references for AI-suggested code
weight 1 · round drawnOpenCodenone0/10No evidence of any license or public-code matching/attribution feature for AI-suggested code in OpenCode's docs or community reports; the product focuses on agent workflows, permissions, and MCP integration but nothing about code provenance or license scanning.
Conductornone0/10No evidence anywhere in the pack of license compliance checks, public-code/plagiarism matching, or provenance references for AI-suggested code; Conductor's documentation focuses on orchestration, workspaces, and diffs/PRs but never mentions license or code-provenance scanning.
Not comparable on these axes
ai-native userConnect an agent via an official MCP server
weight 3 · not comparableOpenCoden/aOpenCode is itself a coding agent (client role), and the evidence only shows it consuming external MCP servers as tools (opencode-docs-4, opencode-docs-23) plus a separate headless OpenAPI/HTTP server (opencode-docs-30, opencode-docs-45) — not an official MCP server mode for OpenCode itself. Per the agent-role rule, this axis does not apply.
- [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
- [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
- [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
- [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
Conductor documents a hosted MCP server that lets ChatGPT, Claude, Codex, and other MCP clients manage cloud workspaces, corroborated by a dedicated probe hit confirming the docs page exists. Missing for 10: independent/hands-on community confirmation of actually connecting an external agent via this MCP server (all community evidence discusses other features, not MCP usage).
- [claimed-docs] “Conductor's hosted Model Context Protocol (MCP) server lets ChatGPT, Claude, Codex, and other MCP clients manage your cloud workspaces.”
- [probe] “official MCP server documented at https://www.conductor.build/docs/api/mcp”
developerReceive inline code completions and next-edit suggestions as I type
weight 3 · not comparableOpenCodenone0/10OpenCode is presented as an agent-driven terminal/desktop/IDE-extension tool that responds to explicit prompts, runs agents, and edits files via chat-like sessions — there is no mention of inline ghost-text completions or next-edit suggestions as the developer types. The IDE integration docs describe opening a terminal split and inserting file references, not autocomplete.
- [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
- [claimed-docs] “Use Cmd+Esc (Mac) or Ctrl+Esc (Windows/Linux) to open OpenCode in a split terminal view”
- [claimed-docs] “Use Cmd+Option+K (Mac) or Alt+Ctrl+K (Linux/Windows) to insert file references.”
- [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
Conductorn/aConductor is a orchestration/workspace manager that runs external coding agents (Claude Code, Codex, Cursor) in parallel git worktrees; it is not itself a code editor or IDE providing inline completions or next-edit suggestions as you type. That capability, if present, belongs to the underlying agents/editors it wraps, not to Conductor's own product surface.
- [claimed-docs] “Conductor lets you run Claude Code, Codex, Cursor, and OpenCode in parallel.”
- [claimed-docs] “Each task gets its own workspace, branch, files, terminal, diff, and review path.”
- [probe] “PROBE llms.txt: HTTP 200 at https://www.conductor.build/llms.txt # Conductor > Conductor is a Mac app that lets you run many coding agents …”
developerDebug a live running web application directly from my coding assistant
weight 1 · not comparableOpenCoden/aOpenCode is a terminal/IDE coding agent focused on code generation, editing, and repo tasks; there is no evidence of live application debugging capability such as attaching to a running process, browser/runtime debugging, or breakpoint inspection. This is a category mismatch for a CLI/TUI coding assistant rather than an applicable-but-missing feature.
Conductorn/aConductor is an orchestration layer for running coding agents (Claude Code, Codex, etc.) in parallel workspaces with git worktrees, PR review, and cloud sandboxes—it is not a runtime debugger or live-application inspector. Debugging a live running web app (breakpoints, stack inspection, request tracing) is outside its product category; no evidence pack item addresses this axis.
ai-native userGenerate a working app from a sketch, image, or PDF design
weight 2 · not comparableOpenCodenone0/10OpenCode's evidence pack shows a terminal/IDE-based coding agent with text prompts, MCP, agents, and CLI/SDK, but there is no mention anywhere of image, sketch, or PDF design input being converted into a working app — no vision/multimodal input capability is documented.
Conductorn/aConductor is an orchestration layer for running coding agents (Claude Code, Codex, Cursor, etc.) in parallel workspaces; it does not itself offer sketch/image/PDF-to-app generation as a product capability. This is a category error—image/design-to-code generation is a feature of the underlying agents or dedicated design-to-code tools, not of Conductor's orchestration UI.
developerGet contextual explanations and automatic fixes for security vulnerabilities
weight 2 · not comparableOpenCodenone0/10OpenCode is a general coding agent with plan/explore/build agents and permission controls, but no evidence describes any security-vulnerability scanning, contextual vulnerability explanations, or automatic security fix generation as a feature. Community evidence even highlights unresolved security reports and vulnerabilities in OpenCode itself, not a capability to detect/fix vulnerabilities in user code.