Gemini CLI vs Conductor

Agent access

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

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   No evidence Gemini CLI has any documented feature for consuming llms.txt or agent-oriented doc manifests; the only related probe shows llms.txt returning 404 on Google's own docs site, and none of the GitHub feature list or docs mention llms.txt support. GEMINI.md context files are a different, project-local mechanism, not agent-oriented web docs discovery.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”

   proof ↗⚑ flag

   Conductor✓fullprobed9/10

   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 …”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Gemini CLI
   Gemini CLI✓fullclaimed9/10

   Gemini CLI explicitly documents non-interactive scripting mode, structured/streaming JSON output flags for programmatic parsing, and GitHub Actions-based automation (PR reviews, issue triage, on-demand assistance), which together cover headless/CI use cases well. Missing for 10: independent hands-on confirmation specifically of CI pipeline reliability (community evidence focuses more on interactive agentic quality than CI usage).

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”

   proof ↗⚑ flag

   Conductor~partialprobed6/10

   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”

   proof ↗⚑ flag

3. ai-native userPlug MCP servers into this product so it can use their tools

   weight 3 · round to Gemini CLI
   Gemini CLI✓fullclaimed8/10

   Gemini CLI documents first-party MCP server support: configuring servers in ~/.gemini/settings.json to add custom tools, a dedicated /mcp command, and explicit mention of connecting media-generation tools like Imagen/Veo/Lyria via MCP. This is corroborated by official docs listing /mcp among CLI commands. Missing for 10: independent hands-on verification of MCP tool usage specifically (community evidence covers general agentic reliability but not MCP integration itself), and more detail on server management/discovery UX.

   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [github] “Use MCP servers to connect new capabilities, including media generation with Imagen, Veo or Lyria”
   • [claimed-docs] “Comandos de Gemini CLI: /memory, /stats, /tools y /mcp”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence 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”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Gemini CLI
   Gemini CLI✓fullprobed9/10

   Gemini CLI is itself an official, first-party CLI product by Google with extensive documentation of its features (scripting, JSON output, MCP support, context files, non-interactive mode) and independent corroboration of active use, confirming it exists and functions as an official CLI tool for AI-native workflows. missing for 10: no fully independent third-party audit of CLI completeness beyond community anecdotes.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “gemini --include-directories ../lib,../docs”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [probe] “official CLI documented at https://developers.google.com/gemini-code-assist/docs/gemini-cli”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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.”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Conductor
   Gemini CLI~partialprobed5/10

   Gemini CLI documents CLI-level automation hooks — non-interactive scripting mode, `--output-format json`/`stream-json` for structured output, and MCP server configuration — which let an AI-native user drive it programmatically (gemini-cli-gh-6, gh-17, gh-18, gh-19). However, explicit probes for a formal public API/SDK (llms.txt, openapi.json) all returned 404, showing no dedicated documented API surface beyond the CLI itself. Missing for 10: a first-party REST/SDK API spec, official API reference docs, and independent confirmation of programmatic (non-CLI) usage.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor✓fullprobed7/10

   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…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Evidence shows Gemini CLI abstracts away API key management entirely (sign in with Google account) rather than offering scoped or least-privilege credential issuance for agents; no docs mention credential scoping, permission boundaries, or token minting for agent use.

   • [github] “No API key management - just sign in with your Google account”

   proof ↗⚑ flag

   Conductor~partialcommunity4/10

   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”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   The evidence pack documents CLI flags, MCP server extensibility, scripting output formats, and GitHub Actions integration, but contains no mention of an official SDK (e.g., a Node/Python/Go library) for programmatically building on Gemini CLI itself. Probes for API/OpenAPI specs also returned 404s, reinforcing the absence of such artifacts.

   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   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…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence of webhook subscription or event-push capability; Gemini CLI supports non-interactive scripting, MCP tool servers, and structured JSON output, but nothing about outbound webhooks or event subscriptions. Missing for 10: any webhook registration mechanism, event subscription API, or documentation of push notifications.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”

   proof ↗⚑ flag

   Conductor—none0/10

   The 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.”

   proof ↗⚑ flag

Agentic features

1. ai-native userGet AI-generated insights and suggestions from my data inside the product

   weight 2 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI ships features that clearly aim at generating insights from a user's own data/codebase — querying and editing large codebases, natural-language debugging, automated PR review with contextual feedback, and issue triage (gemini-cli-gh-1, gh-3, gh-10, gh-11), and one community report praises its code review as catching bugs missed by humans (gemini-cli-comm-20). However, multiple hands-on reports directly contradict this, describing it as 'terrible at agentic stuff', getting stuck in loops, failing to edit/read files, and being 'useless as a coding assistant' that produces spaghetti code (gemini-cli-comm-10, comm-14, comm-15). missing for 10: independent benchmark confirming consistent quality of generated insights, resolution of the loop/failure reports, and evidence the insight-generation works reliably across data types beyond code.

   • [github] “Query and edit large codebases”
   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [community] “We have tried out Gemini code review vs Copilot code review and Gemini is consistently offering better code review tips. It has officially c…”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “I love the model, hate the tool. Anthropic has the killer app with Claude Code. I tried Gemini cli for about 5 seconds and was so frustrated…”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   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”

   proof ↗⚑ flag

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

   weight 2 · round to Conductor
   Gemini CLI~partialcommunity6/10

   Gemini CLI documents non-interactive scripting mode and a GitHub Action integration that runs autonomously in the background (automated PR reviews, issue triage, on-demand @gemini-cli responses), which directly supports background automations. However, independent community reports describe agentic reliability problems (getting stuck in loops, failing simple file operations, ignoring GEMINI.md context) that undercut confidence in unattended/background runs actually completing correctly. Missing for 10: independent hands-on validation that scheduled/background automations run reliably end-to-end, and more detail on failure/retry handling in autonomous mode.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “@github List my open pull requests”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

3. ai-native userDelegate tasks to a built-in AI assistant inside the product

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI is itself billed as an agentic assistant with extensive task-delegation features (codebase queries, debugging, PR review/issue triage, operational automation via @gemini-cli mentions) per gemini-cli-gh-3/4/10/11/12/22. However, hands-on community reports concretely contradict reliable delegation: users report it is 'really really terrible at agentic stuff,' gets stuck in permanent loops, ignores GEMINI.md context, and in one case catastrophically deleted user files while apologizing for the failure.

   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   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.”

   proof ↗⚑ flag

4. ai-native userOperate the product with natural-language commands

   weight 2 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI's entire premise is natural-language driven coding/agentic actions (querying codebases, debugging, automating PR/rebase tasks, custom GEMINI.md context) per gemini-cli-gh-1/3/4/9. However, multiple hands-on reports describe the NL-agent behavior failing badly in practice — getting stuck in error loops, botching file edits, ignoring GEMINI.md instructions, and in one case catastrophically deleting user data via misinterpreted commands.

   • [github] “Query and edit large codebases”
   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor✓fullprobed8/10

   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”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence of an interactive API reference with runnable examples; probes explicitly show no llms.txt or OpenAPI spec found, and no docs describe an interactive reference tool.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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…”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round drawn
   Gemini CLI—none0/10

   Probes explicitly show no OpenAPI/llms.txt spec is published (404s at all candidate paths), and no other evidence mentions a machine-readable API spec for Gemini CLI.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Conductor
   Gemini CLI—none0/10

   No evidence pack items describe a sandbox/test environment isolated from production data for Gemini CLI; the only mention of 'sandbox' appears in an unrelated community comment describing another tool's architecture, not Gemini CLI's own testing environment. missing for 10: dedicated sandbox mode/documentation, evidence of isolation from production data, any hands-on confirmation of safe test environments.

   ⚑ flag

   Conductor~partialcommunity6/10

   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-…”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence of versioned APIs or a documented deprecation policy for Gemini CLI; probes for llms.txt/openapi specs 404, and there is community evidence the tool itself was abruptly deprecated with no policy discussion (gemini-cli-comm-6/7/8), but no documentation of API versioning or deprecation commitments exists.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”
   • [community] “Welcome to the Google graveyard, Gemini CLI. Not that it will be missed much. Using it was the worst experience out of any harness.”
   • [community] “Google really can't help themselves but to have some internal re-org kill off a public thing people are actively using. It's honestly impres…”

   proof ↗⚑ flag

   Conductor—none0/10

   There'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…”

   proof ↗⚑ flag

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

   weight 2 · round to Conductor
   Gemini CLI~partialcommunity6/10

   Gemini CLI supports scripting/non-interactive automation, multi-directory context inclusion, structured JSON output for pipelines, and GitHub Action integrations like automated issue triage (bulk labeling/prioritization) and PR review across a repo — all pointing to bulk/batch style operations. However there's no explicit documented 'batch process N files/items' feature or example, and community reports note the agent can get stuck in loops or fail simple multi-step tasks, raising doubts about reliability at scale. Missing for 10: explicit bulk-operation examples/documentation (e.g., batch renaming, mass refactor across many files) and independent evidence confirming reliable execution at scale.

   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “gemini --include-directories ../lib,../docs”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”

   proof ↗⚑ flag

   Conductor~partialclaimed7/10

   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…”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Gemini CLI~partialclaimed5/10

   Gemini CLI ships GitHub Action integrations that fire automatically on repo events (PR opened → automated review, issue created → automated triage, @mention → on-demand help), which is a form of event-triggered automation, plus non-interactive/scripted execution for pipelines. However there's no evidence of a general-purpose, user-defined rule/trigger engine (e.g., custom webhooks, cron-like conditions, arbitrary event types) within the CLI itself—only fixed GitHub-event integrations. Missing for 10: a generic rule-definition mechanism for arbitrary events, documentation of custom trigger conditions, and independent confirmation these automations work reliably (community notes reliability issues with agentic behavior).

   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “Run non-interactively in scripts for workflow automation”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   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.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Conductor
   Gemini CLI~partialclaimed4/10

   Gemini CLI supports non-interactive scripted runs and structured JSON output, which lets users wire it into external schedulers (cron, CI) for recurring automation, and its GitHub Action integrations (issue triage, PR review) imply repeatable, trigger-based workflows. However there is no first-party 'scheduled job' or cron feature documented within the CLI itself. Missing for 10: a native recurring-job/scheduler feature, explicit docs on scheduling cadence, and independent confirmation that scripted/CI-triggered runs work reliably for recurring automation.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”

   proof ↗⚑ flag

   Conductor✓fullclaimed6/10

   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.”

   proof ↗⚑ flag

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

   weight 1 · round to Conductor
   Gemini CLI~partialclaimed4/10

   Gemini CLI offers conversation checkpointing to save and resume sessions (gemini-cli-gh-8), which provides a rudimentary rollback/resume mechanism, but there is no evidence of versioning, diffing, or reviewing automation scripts/workflows themselves, nor a dedicated rollback command for automations. missing for 10: explicit version history for automations, review/diff tooling, and a documented rollback mechanism beyond session checkpoints.

   • [github] “Conversation checkpointing to save and resume complex sessions”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Background execution

1. ai-native userHave a cloud agent build, test, and demo a feature end-to-end for my review

   weight 2 · round to Conductor
   Gemini CLI~partialcommunity4/10

   Gemini CLI documents cloud-adjacent automation via its GitHub Actions integration (PR reviews, issue triage, @gemini-cli on-demand assistance, non-interactive scripting) which could kick off agentic work, but there is no vendor evidence of an autonomous cloud agent that builds, runs tests, and produces a demo end-to-end for review. Community reports also describe agentic mode getting stuck in error loops, failing at basic file edits, and even causing data loss, undercutting confidence in reliable autonomous execution. missing for 10: explicit end-to-end build+test+demo workflow, evidence of a hosted/cloud agent (vs local CLI or CI hooks) producing a reviewable demo, and independent confirmation that autonomous runs complete without failure loops.

   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “Run non-interactively in scripts for workflow automation”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

2. developerDelegate longer-running coding tasks to run in the background in an isolated cloud environment

   weight 3 · round to Conductor
   Gemini CLI~partialclaimed4/10

   Gemini CLI supports non-interactive scripting and GitHub Actions integration (@gemini-cli mentions for PR reviews, issue triage, on-demand assistance) which can run tasks in a cloud CI environment, and Cloud Shell offers a ready cloud runtime — but there's no dedicated 'run this long task in an isolated background cloud sandbox' feature akin to a hosted agent service. missing for 10: explicit isolated cloud sandbox/background execution product, evidence of long-running autonomous task delegation outside CI triggers, and independent confirmation it works reliably for extended background jobs.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   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-…”

   proof ↗⚑ flag

3. developerConfigure a reproducible cloud environment with the dependencies and setup steps my repository needs

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Evidence shows Gemini CLI can run in Cloud Shell without extra setup and supports GEMINI.md context files, but there is no evidence of a configurable, reproducible cloud environment (e.g., dependency/setup scripts, devcontainer-style config) that a developer can define for their repo. Missing for 10: any documented environment/setup-script configuration mechanism, evidence of reproducibility across runs, and independent confirmation it works as such.

   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Parallel agents

1. ai-native userLaunch fleets of autonomous agents that work in parallel on different tasks for hours or days

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Evidence shows single-session non-interactive scripting, GitHub Actions integration for issue triage/PR review, and MCP extensibility, but nothing about launching multiple autonomous agents working in parallel for hours or days. No fleet/orchestration/multi-agent parallelism capability is documented anywhere in the pack.

   ⚑ flag

   Conductor✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

2. developerRun several task attempts in parallel and compare results before choosing one

   weight 1 · round to Conductor
   Gemini CLI—none0/10

   No evidence in the pack describes running multiple parallel task attempts or comparing/diffing results before selecting one; features listed are single-session tools (checkpointing, MCP, scripting) with no multi-attempt/parallel comparison workflow mentioned. Missing for 10: any mention of parallel run/branching feature, a comparison UI or mechanism to pick the best of several attempts.

   ⚑ flag

   Conductor✓fullprobed8/10

   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.”

   proof ↗⚑ flag

Scheduled automation

1. ai-native userSet up always-on agents that run on schedules or triggers to maintain and fix my software autonomously

   weight 2 · round to Conductor
   Gemini CLI~partialcommunity4/10

   Gemini CLI supports non-interactive scripted runs and GitHub Actions-based triggers (PR reviews, issue triage, @mention on-demand assistance) which can approximate scheduled/triggered automation, but there is no evidence of a persistent, self-scheduling 'always-on agent' that autonomously maintains and fixes software over time. missing for 10: native scheduler/cron support, persistent agent daemon or watch-mode, evidence of autonomous multi-cycle maintenance without human triggering, and reliability data (community reports actually describe agent mode getting stuck in loops or failing tasks).

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Debugging

1. developerDebug issues and troubleshoot using natural-language queries

   weight 2 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI explicitly advertises natural-language debugging/troubleshooting (gemini-cli-gh-3, gh-12/21/23) and community reports confirm strong codebase navigation and code-review value (gemini-cli-comm-1, comm-20). However, multiple hands-on reports directly contradict reliable debugging: users describe it getting stuck in error loops, failing simple file edits, and in one case catastrophically deleting user data during a troubleshooting session (gemini-cli-comm-10, comm-11, comm-14, comm-16).

   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [community] “We have tried out Gemini code review vs Copilot code review and Gemini is consistently offering better code review tips. It has officially c…”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   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”

   proof ↗⚑ flag

Feature implementation

1. developerTurn a tracked issue into a complete pull request end-to-end

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI's GitHub integration supports @gemini-cli task delegation from issues/PRs, automated PR reviews, and issue triage, which vendor docs frame as enabling issue-to-PR workflows (gh-12, gh-21, gh-10, gh-22, gh-4). However, hands-on community reports describe the agent getting stuck in loops, failing basic file edits, lacking a plan mode, and producing 'spaghetti code' rather than completing tasks reliably — directly undermining claims of smooth end-to-end PR generation (gemini-cli-comm-10, gemini-cli-comm-11, gemini-cli-comm-14). Missing for 10: a documented full issue→PR walkthrough, evidence of successful autonomous PR creation from an issue, and independent confirmation resolving the agentic reliability complaints.

   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “@github List my open pull requests”
   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   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.”

   proof ↗⚑ flag

2. developerDescribe a feature or bug in plain language and have the agent implement or fix it across multiple files

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Vendor docs/GitHub claim strong support for describing features/bugs in plain language and having the agent edit/debug across large codebases (gemini-cli-gh-1, gemini-cli-gh-3), but multiple hands-on community reports directly contradict this: users report the agent getting stuck in error loops, failing basic file edit/read operations, ignoring GEMINI.md context files, jumping straight into 'spaghetti code' without a plan mode, and in one case catastrophically deleting user data via botched commands. missing for 10: consistent hands-on success stories on multi-file feature implementation, resolution of the reported reliability/looping failures, and independent benchmarks confirming multi-file bug-fix accuracy.

   • [github] “Query and edit large codebases”
   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor~partialcommunity6/10

   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.”

   proof ↗⚑ flag

Maintenance automation

1. developerHave the agent write tests, fix lint errors, resolve merge conflicts, and update dependencies for me

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   GitHub docs claim broad code-editing, debugging, and complex-rebase (merge conflict) automation capabilities (gemini-cli-gh-1, gemini-cli-gh-3, gemini-cli-gh-4), which would cover fixing lint issues and dependency/test work as part of general codebase editing, and PR review/issue triage features suggest lint-like feedback (gemini-cli-gh-10, gemini-cli-gh-11). However, multiple hands-on community reports concretely contradict reliable agentic code work: users report it getting stuck in error loops, failing simple file edit/read operations, ignoring GEMINI.md context files, producing 'spaghetti code' with no plan mode, and in one case catastrophically deleting user data during a file operation (gemini-cli-comm-10, gemini-cli-comm-11, gemini-cli-comm-13, gemini-cli-comm-14, gemini-cli-comm-16). No explicit evidence names test-writing, lint-fixing, or dependency-updating tasks specifically. Missing for 10: explicit documentation/examples of writing tests, fixing lint errors, or updating dependencies, and independent corroboration that these specific tasks work reliably.

   • [github] “Query and edit large codebases”
   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   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.”

   proof ↗⚑ flag

Codebase mapping

1. developerUnderstand how a codebase fits together to find where to start making changes

   weight 3 · round to Gemini CLI
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI advertises large-codebase querying/editing (gemini-cli-gh-1) with a 1M-token context window, custom GEMINI.md context files, and --include-directories flags for scoping (gemini-cli-gh-9, gemini-cli-gh-16), and one HN user praises its ability to 'navigate and learn' large codebases effortlessly (gemini-cli-comm-1). However, other hands-on users report the opposite: it is 'stupid at navigation in the codebase' taking 10x longer (gemini-cli-comm-15) and 'consistently ignores' the GEMINI.md context file despite claiming to use it (gemini-cli-comm-13), directly undercutting the codebase-understanding claim. Missing for 10: consistent independent corroboration of reliable codebase navigation, and no contradicting failure reports.

   • [github] “Query and edit large codebases”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [github] “gemini --include-directories ../lib,../docs”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [community] “I love the model, hate the tool. Anthropic has the killer app with Claude Code. I tried Gemini cli for about 5 seconds and was so frustrated…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor'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.”

   proof ↗⚑ flag

2. developerHave the agent map and explain an entire unfamiliar codebase without manually selecting context files

   weight 3 · round to Gemini CLI
   Gemini CLI!disputedcontradicted5/10

   Google claims large-codebase querying/editing (gemini-cli-gh-1) and Gemini CLI's 1M-token context lets it 'navigate and learn' huge codebases 'effortlessly' per one user (gemini-cli-comm-1), but other hands-on reports directly contradict this, calling it 'so stupid at navigation in the codebase it takes 10x as long' (gemini-cli-comm-15) and prone to getting 'stuck in spaghetti code' with no plan mode (gemini-cli-comm-14), plus it reportedly ignores its own GEMINI.md context file (gemini-cli-comm-13). Missing for 10: consistent independent benchmarks confirming autonomous whole-codebase mapping without file selection, and resolution of the navigation-quality contradiction.

   • [github] “Query and edit large codebases”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [community] “I love the model, hate the tool. Anthropic has the killer app with Claude Code. I tried Gemini cli for about 5 seconds and was so frustrated…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor'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.”

   proof ↗⚑ flag

Context management

1. developerHave the agent build and recall memory automatically across sessions

   weight 2 · round to Gemini CLI
   Gemini CLI!disputedcontradicted3/10

   Gemini CLI offers static project context via GEMINI.md files and a `/memory` command, plus manual conversation checkpointing to save/resume sessions—but these are manually configured/invoked, not automatic memory building/recall across sessions. Hands-on community evidence directly contradicts even the GEMINI.md context mechanism working reliably: a user reports it 'consistently ignores my GEMINI.md file... even though it always says 1 GEMINI.md file is being used' (gemini-cli-comm-13), undermining the claimed persistent-context capability. missing for 10: evidence of automatic memory formation/recall without user action, evidence /memory command builds persistent cross-session knowledge, independent corroboration that GEMINI.md context reliably persists.

   • [github] “Conversation checkpointing to save and resume complex sessions”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [claimed-docs] “Comandos de Gemini CLI: /memory, /stats, /tools y /mcp”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence 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.”

   proof ↗⚑ flag

2. developerInclude multiple project directories in a single session for broader context

   weight 2 · round to Gemini CLI
   Gemini CLI✓fullclaimed8/10

   The official CLI flag `--include-directories ../lib,../docs` explicitly allows adding multiple project directories into a single session for broader context, directly matching the story. Missing for 10: independent hands-on confirmation of multi-directory usage quality/behavior beyond the flag documentation.

   • [github] “gemini --include-directories ../lib,../docs”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor'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…”

   proof ↗⚑ flag

3. developerAdd a project instructions file to set coding standards and conventions the agent follows

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted5/10

   Gemini CLI documents GEMINI.md custom context files for tailoring behavior/project conventions (gemini-cli-gh-9) and docs mention /memory command for managing this context (gemini-cli-docs-3). However, hands-on community feedback reports the file being ignored despite being loaded ('it consistently ignores my GEMINI.md file, both global and local, even though it always says 1 GEMINI.md file is being used' - gemini-cli-comm-13), directly contradicting reliable adherence to project instructions. Missing for 10: independent corroboration that GEMINI.md is consistently honored, more detail on precedence/hierarchy of instruction files, and resolution of the reported ignoring behavior.

   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [claimed-docs] “Comandos de Gemini CLI: /memory, /stats, /tools y /mcp”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   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.”

   proof ↗⚑ flag

Issue diagnosis

1. developerReproduce issues, narrow down root causes, and verify fixes

   weight 3 · round to Conductor
   Gemini CLI!disputedcontradicted4/10

   Google markets debugging/troubleshooting via natural language and a /bug reporting flow (gh-3, gh-20), and one HN user praises its ability to navigate huge codebases (comm-1). However multiple hands-on reports directly contradict root-cause/verify-fix workflows: users describe it getting stuck in error loops, rewriting files empty, ignoring GEMINI.md context, being 'terrible at agentic stuff', and in one case catastrophically deleting user data during a file operation (comm-10, comm-11, comm-13, comm-14, comm-15, comm-16). missing for 10: reliable reproduction of bugs, consistent root-cause narrowing without loops, and independent verification of fix correctness.

   • [github] “Debug issues and troubleshoot with natural language”
   • [github] “Use `/bug` command to report issues directly from the CLI.”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [community] “A lot of times Gemini models will get stuck in a loop of errors, and a lot of times it fails to edit/read or other simple function calling -…”
   • [community] “I really tried to get gemini to work properly in Agent mode. Tho it way too often went crazy, started rewriting files empty, and ran into pe…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “I love the model, hate the tool. Anthropic has the killer app with Claude Code. I tried Gemini cli for about 5 seconds and was so frustrated…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Marketplace

1. developerEquip the agent with custom skills to perform specialized tasks

   weight 1 · round to Gemini CLI
   Gemini CLI~partialcommunity6/10

   Gemini CLI supports extensibility through MCP servers (custom tools, media generation) and GEMINI.md context files to tailor agent behavior for specific projects, and a community mention references a built-in 'skills runtime' as part of its architecture. However, there is no dedicated first-party 'skills' marketplace or packaging system, and community reports note GEMINI.md is sometimes ignored in practice. Missing for 10: a documented first-class 'skills' framework/marketplace, independent corroboration that custom skills work reliably, and confirmation that the skills runtime mentioned in community feedback is a stable, documented feature.

   • [github] “Use MCP servers to connect new capabilities, including media generation with Imagen, Veo or Lyria”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [community] “All in all, a 140 MB Go binary with its own browser control stack, sandbox, Git, language detector, skills runtime, and subagent system. I'm…”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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…”

   proof ↗⚑ flag

2. engineering-leadIntegrate third-party partner-built agent apps into my workflows

   weight 1 · round to Conductor
   Gemini CLI~partialclaimed5/10

   Gemini CLI supports connecting external capabilities via MCP servers (e.g., Imagen, Veo, Lyria) and integrates with GitHub via @gemini-cli mentions and Actions, showing some ecosystem extensibility for third-party tools. However, there's no evidence of a curated marketplace or directory of partner-built 'agent apps' specifically designed for cross-workflow integration, only generic MCP server configuration support. Missing for 10: a documented partner/agent-app ecosystem or marketplace, case studies of third-party agent apps being integrated, and independent confirmation of smooth interoperability.

   • [github] “Use MCP servers to connect new capabilities, including media generation with Imagen, Veo or Lyria”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [github] “@github List my open pull requests”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”

   proof ↗⚑ flag

   Conductor~partialcommunity7/10

   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…”

   proof ↗⚑ flag

Team knowledge

1. engineering-leadCreate a shared workspace from my docs and repos as a common source of truth for the team

   weight 1 · round to Conductor
   Gemini CLI—none0/10

   Gemini CLI offers per-project GEMINI.md context files and --include-directories for local context, but there is no evidence of a shared, centrally managed team workspace combining docs and repos as a common source of truth across a team.

   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”
   • [github] “gemini --include-directories ../lib,../docs”
   • [community] “Tip 1, it consistently ignores my GEMINI.md file, both global and local, even though it always says '1 GEMINI.md file is being used.'”

   proof ↗⚑ flag

   Conductor~partialclaimed4/10

   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.”

   proof ↗⚑ flag

Tool integration

1. developerConnect the agent to workflow tools like Jira, Slack, and Google Drive to extend its context

   weight 3 · round to Gemini CLI
   Gemini CLI~partialclaimed5/10

   Gemini CLI supports connecting MCP servers to add custom tools/capabilities (gh-5, gh-19), which is the generic mechanism that could extend context to third-party services, but the evidence never mentions Jira, Slack, or Google Drive specifically or any pre-built connectors for them. Missing for 10: named/official Jira, Slack, or Google Drive integrations or MCP servers, and any documented example of using these workflow tools with Gemini CLI.

   • [github] “Use MCP servers to connect new capabilities, including media generation with Imagen, Veo or Lyria”
   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence shows Conductor integrates with GitHub and Linear (issue/branch creation) and exposes an MCP server for managing cloud workspaces, but there is no mention of Jira, Slack, or Google Drive integrations anywhere in the docs or community evidence.

   ⚑ flag

2. developerKick off agent tasks directly from GitHub, GitLab, Linear, or Slack

   weight 2 · round to Conductor
   Gemini CLI~partialclaimed4/10

   Gemini CLI has a documented GitHub integration (GitHub Action/App) that lets developers trigger tasks via @gemini-cli mentions in issues/PRs, automated PR reviews, and issue triage, 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 corroboration of GitHub workflow reliability

   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “@github List my open pull requests”
   • [github] “Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”

   proof ↗⚑ flag

   Conductor~partialclaimed5/10

   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.”

   proof ↗⚑ flag

Cross device continuity

1. developerStart a task on one device and continue it later from another device or browser

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Gemini CLI offers local conversation checkpointing to save/resume sessions (gh-8) and can run in Cloud Shell (docs-1), but there is no evidence of cloud-synced session state that lets a developer start a task on one device/terminal and pick it up seamlessly on another device or browser. missing for 10: cross-device session sync, browser-based continuation of an existing CLI session, any documented mechanism to transfer checkpoint state between machines.

   • [github] “Conversation checkpointing to save and resume complex sessions”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Ide integration

1. developerView interactive diffs and share selected code as context from within my JetBrains IDE

   weight 1 · round drawn
   Gemini CLI—none0/10

   No evidence mentions JetBrains IDE integration, interactive diffs, or sharing code context from within an IDE for Gemini CLI; evidence pack only covers terminal/CLI usage, GitHub Actions, and MCP servers.

   ⚑ flag

   Conductor—none0/10

   Conductor 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 …”

   proof ↗⚑ flag

2. developerChat with the coding assistant directly inside my IDE for contextual help

   weight 3 · round to Conductor
   Gemini CLI—none0/10

   The evidence pack describes Gemini CLI as a terminal-based agent (context files, MCP servers, Cloud Shell access) but contains no mention of an IDE extension, sidebar chat, or in-editor contextual panel that would let a developer chat with it directly inside an IDE. Community threads discuss its terminal/agentic performance, not IDE integration.

   ⚑ flag

   Conductor✓fullcommunity7/10

   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.”

   proof ↗⚑ flag

Session management

1. engineering-leadManage multiple agent-driven coding sessions from one unified workspace

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Evidence shows single-session features (conversation checkpointing to save/resume one session, GEGEMINI.md context files) but nothing about running or coordinating multiple concurrent agent sessions from one unified dashboard/workspace for a lead overseeing a team's work. missing for 10: multi-session dashboard/orchestration UI, evidence of concurrent session management, any lead-oriented workspace view.

   • [github] “Conversation checkpointing to save and resume complex sessions”
   • [github] “Custom context files (GEMINI.md) to tailor behavior for your projects”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   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.”

   proof ↗⚑ flag

Terminal workflow

1. developerRun a coding agent locally from my terminal

   weight 3 · round to Gemini CLI
   Gemini CLI✓fullcommunity8/10

   Gemini CLI is a terminal-native coding agent with first-party docs (gemini-cli-gh-1 through -20, gemini-cli-docs-1/2/3) describing running locally, querying/editing codebases, non-interactive scripting, and Cloud Shell availability with no extra setup, and abundant community evidence (gemini-cli-comm-1, -9, -12) confirms real-world local terminal usage. Missing for 10: independent benchmark of reliability (several community reports of agentic failures/loops, e.g. gemini-cli-comm-10, -11, -14) and no first-party install/runtime docs beyond GitHub README excerpts.

   • [github] “Query and edit large codebases”
   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “gemini --include-directories ../lib,../docs”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”
   • [community] “I have been using this for about a month and it's a beast, mostly thanks to 2.5pro being SOTA and how it leverages that huge 1M context wind…”
   • [community] “The correct way of using Gemini CLI is: ABUSE IT! With 1M Context Window (soon 2M) and generous daily free quota are huge advantages.”

   proof ↗⚑ flag

   Conductor~partialprobed7/10

   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 …”

   proof ↗⚑ flag

2. developerRun the agent non-interactively in scripts for workflow automation

   weight 2 · round to Gemini CLI
   Gemini CLI✓fullclaimed9/10

   Gemini CLI explicitly documents non-interactive scripting support with structured output flags (--output-format json / stream-json) and lists 'Run non-interactively in scripts for workflow automation' as a core feature; GitHub Actions integration for PR review/issue triage further evidences automation use cases. Missing for 10: independent hands-on validation specifically of scripting/automation workflows (community feedback focuses on interactive agent quality, not scripted use).

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round drawn
   Gemini CLI~partialprobed5/10

   Gemini CLI supports non-interactive scripting and structured JSON/stream-JSON output (gh-6, gh-17, gh-18), suggesting most interactive capabilities can be invoked programmatically for automation. However, there's no explicit documentation confirming full feature parity between interactive sessions and scripted/API use, and probes found no formal API/OpenAPI spec (probe-1, probe-2), so completeness of parity is unverified. Missing for 10: explicit parity documentation, a formal API surface beyond CLI flags, and independent confirmation that all UI/interactive features (e.g., checkpointing, MCP tool use) are scriptable identically.

   • [github] “Run non-interactively in scripts for workflow automation”
   • [github] “use the `--output-format json` flag to get structured output”
   • [github] “use `--output-format stream-json` to get newline-delimited JSON events”
   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor~partialprobed5/10

   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…”

   proof ↗⚑ flag

2. ai-native userExport all of my data in open formats and leave

   weight 3 · round drawn
   Gemini CLI—none0/10

   No evidence of any data export feature or open-format data portability in Gemini CLI; the tool is a local coding agent that reads/writes local files but nothing indicates exporting conversation history, settings, or usage data in an open format for user-controlled exit. Probes for llms.txt/openapi also failed, showing no structured data-access surface.

   • [probe] “PROBE llms.txt: HTTP 404 at https://developers.google.com/llms.txt”
   • [probe] “PROBE openapi: all candidate paths 404 (https://developers.google.com/openapi.json, https://developers.google.com/swagger.json, https://deve…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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…”

   proof ↗⚑ flag

3. ai-native userRead the product's source under an open license

   weight 2 · round to Gemini CLI
   Gemini CLI~partialprobed5/10

   The product's source is hosted publicly at github.com/google-gemini/gemini-cli (referenced repeatedly across the evidence pack), implying open availability for reading, but no citation in the evidence pack explicitly names or confirms an open-source license (e.g., Apache/MIT) or points to a LICENSE file. Missing for 10: explicit license text/citation, confirmation of license type, and any independent corroboration of open-license terms.

   • [github] “Query and edit large codebases”
   • [github] “Use `/bug` command to report issues directly from the CLI.”
   • [probe] “official CLI documented at https://developers.google.com/gemini-code-assist/docs/gemini-cli”

   proof ↗⚑ flag

   Conductor—none0/10

   There 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.”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round drawn
   Gemini CLI—none0/10

   Gemini CLI is an open-source client, but the core product (the Gemini models/backend) is a Google-hosted cloud service accessed via Google account sign-in; no evidence anywhere in the pack describes a self-hosted or on-prem deployment option for the core model/service.

   • [github] “No API key management - just sign in with your Google account”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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.”

   proof ↗⚑ flag

Authentication

1. developerAuthenticate with an API key instead of an account login

   weight 2 · round to Conductor
   Gemini CLI~partialclaimed4/10

   The docs emphasize signing in with a Google account (gh-13) as the primary flow, but they also note that developers needing 'specific model control or paid tier access' (gh-24) have an alternative path, implying API-key-based auth exists without detailing it. There's no explicit example or setup instructions for API-key authentication itself. Missing for 10: explicit API key env-var/config documentation, first-party steps for key-based auth, and independent confirmation it works without Google login.

   • [github] “No API key management - just sign in with your Google account”
   • [github] “Developers who need specific model control or paid tier access”

   proof ↗⚑ flag

   Conductor✓fullclaimed7/10

   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…”

   proof ↗⚑ flag

2. engineering-leadAuthenticate through an enterprise identity or cloud platform for compliance and scalability

   weight 2 · round to Gemini CLI
   Gemini CLI!disputedcontradicted4/10

   Google claims 'Enterprise features: Advanced security and compliance' and frictionless Google-account sign-in without API key management, plus Cloud Shell availability, suggesting cloud/enterprise identity support. However, a hands-on community report shows authentication explicitly failing for Workspace (enterprise) accounts ('Failed to login. Ensure your Google account is not a Workspace account'), directly contradicting the enterprise-identity claim for a core scenario. Missing for 10: documented enterprise SSO/IAM integration details, confirmation Workspace login issue is resolved, and independent verification of compliance certifications.

   • [github] “No API key management - just sign in with your Google account”
   • [github] “Enterprise features: Advanced security and compliance”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”
   • [community] “'Failed to login. Ensure your Google account is not a Workspace account.' I have had a Workspace account since GSuite and now as a Workspace…”

   proof ↗⚑ flag

   Conductor—none0/10

   Evidence 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…”

   proof ↗⚑ flag

3. developerSign in with my existing product subscription plan to use the coding agent

   weight 2 · round to Conductor
   Gemini CLI!disputedcontradicted4/10

   Gemini CLI advertises frictionless Google-account sign-in with no API key management (gh-13), suggesting subscribers could just log in and go, but hands-on community reports concretely contradict this: a Gemini Pro subscriber found that paying for 'Gemini' doesn't unlock Gemini CLI usage, requiring a separate 'Gemini Code Assist Standard/Enterprise' plan, and another user explicitly asks for one unified subscription across CLI, Code Assist, Jules, etc. like Claude's Max plan. Missing for 10: evidence that an existing Google One/Gemini Advanced subscription actually raises CLI usage limits, and resolution of the reported subscription fragmentation.

   • [github] “No API key management - just sign in with your Google account”
   • [community] “I love how fragmented Google's Gemini offerings are. I'm a Pro subscriber but I learn I should be a 'Gemini Code Assist Standard or Enterpri…”
   • [community] “Again, with the complicated subscription. Please just give us a monthly subscription for developers that I can pay whatever, and then use Ge…”
   • [github] “Developers who need specific model control or paid tier access”

   proof ↗⚑ flag

   Conductor✓fullclaimed8/10

   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…”

   proof ↗⚑ flag

4. developerSign in with a personal account to get free-tier access without managing API keys

   weight 1 · round to Gemini CLI
   Gemini CLI✓fullcommunity7/10

   GitHub docs explicitly state 'No API key management - just sign in with your Google account' (gemini-cli-gh-13), directly matching the story, and Cloud Shell docs describe zero-setup access. Community reports don't dispute personal-account sign-in itself (the failure noted is specific to Workspace accounts, an edge case outside 'personal account'), though some users voice confusion over how free vs paid tiers interact. Missing for 10: independent/hands-on confirmation of the free-tier quota limits and clearer documentation distinguishing personal free-tier access from paid Code Assist tiers.

   • [github] “No API key management - just sign in with your Google account”
   • [claimed-docs] “The Gemini CLI is available without additional setup in Cloud Shell”
   • [community] “I love how fragmented Google's Gemini offerings are. I'm a Pro subscriber but I learn I should be a 'Gemini Code Assist Standard or Enterpri…”
   • [community] “'Failed to login. Ensure your Google account is not a Workspace account.' I have had a Workspace account since GSuite and now as a Workspace…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor'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.”

   proof ↗⚑ flag

Model choice

1. developerLet the tool automatically pick the best model for each task

   weight 1 · round drawn
   Gemini CLI—none0/10

   Evidence shows manual model selection ('Choose specific Gemini models' for 'developers who need specific model control') rather than automatic task-based model selection; no evidence of the CLI auto-choosing the optimal model per task.

   • [github] “Model selection: Choose specific Gemini models”
   • [github] “Developers who need specific model control or paid tier access”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor 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…”

   proof ↗⚑ flag

2. developerChoose which underlying AI model powers my session from multiple providers

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   Evidence shows Gemini CLI only supports choosing among Google's own Gemini models (gh-14, gh-24), not switching between different AI providers (e.g., OpenAI, Anthropic); community complaints (comm-2, comm-3, comm-19) reinforce that it's locked to Google's ecosystem/billing. There is no evidence of multi-provider model selection, so the story as written (choosing from multiple providers) is not delivered.

   • [github] “Model selection: Choose specific Gemini models”
   • [github] “Developers who need specific model control or paid tier access”
   • [community] “The killer feature of Claude Code is that you can just pay for Max and not worry about API billing. Until Gemini does that, I'm sticking wit…”
   • [community] “I love how fragmented Google's Gemini offerings are. I'm a Pro subscriber but I learn I should be a 'Gemini Code Assist Standard or Enterpri…”
   • [community] “Again, with the complicated subscription. Please just give us a monthly subscription for developers that I can pay whatever, and then use Ge…”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   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…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence in the pack mentions data residency, regional storage options, or configurable data location controls for Gemini CLI; only enterprise 'security and compliance' features are mentioned generically without specifics.

   ⚑ flag

   Conductor—none0/10

   No 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…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Gemini CLI—none0/10

   No evidence in the pack addresses data usage/training opt-out policies, privacy controls, or terms governing whether user data trains Google's models; only unrelated feature/community commentary is present. Missing for 10: explicit data-usage/training policy documentation, opt-out mechanism, enterprise/no-training guarantee.

   ⚑ flag

   Conductor—none0/10

   No 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…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence pack items address data retention controls, deletion mechanisms, or privacy settings for Gemini CLI; only enterprise 'security and compliance' is vaguely mentioned without specifics. Missing for 10: documentation on data retention policy, user-controlled deletion mechanism, opt-out of data collection, and any privacy settings UI/CLI flags.

   ⚑ flag

   Conductor—none0/10

   No 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.”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Gemini CLI—none0/10

   No evidence in the pack mentions telemetry settings, opt-out flags, or usage-data collection policy for Gemini CLI. Missing for 10: any documentation of a telemetry/usage-tracking toggle, privacy settings, or opt-out mechanism.

   ⚑ flag

   Conductor—none0/10

   No 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…”

   proof ↗⚑ flag

Data governance

1. engineering-leadOpt out of having my code and prompts used for AI model training

   weight 1 · round drawn
   Gemini CLI—none0/10

   No evidence in the pack addresses data usage, training opt-out policies, or privacy controls for Gemini CLI; only feature lists and general community sentiment are present. missing for 10: any documentation of data usage/training policy, opt-out settings or enterprise privacy controls, and independent confirmation of such settings working.

   ⚑ flag

   Conductor—none0/10

   No 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…”

   proof ↗⚑ flag

Pr review

1. developerHave the agent stage changes, write commit messages, create branches, and open pull requests

   weight 3 · round to Conductor
   Gemini CLI~partialclaimed4/10

   Evidence shows Gemini CLI can automate git-related operational tasks like querying pull requests and handling complex rebases, and its GitHub Action can do automated PR reviews and issue triage, but there's no explicit documentation of the agent staging changes, writing commit messages, creating branches, or opening new pull requests itself. Missing for 10: explicit commit-message generation, branch creation, and PR-opening workflow evidence, plus independent confirmation these work reliably.

   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “@github List my open pull requests”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”

   proof ↗⚑ flag

   Conductor✓fullcommunity8/10

   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.”

   proof ↗⚑ flag

2. developerGet automatic code review with contextual feedback on every pull request

   weight 3 · round to Gemini CLI
   Gemini CLI✓fullcommunity8/10

   Gemini CLI's GitHub Actions integration explicitly provides automated PR code review with contextual feedback and suggestions, plus on-demand @gemini-cli assistance in PRs, and community reports corroborate favorable code review quality compared to competitors. Missing for 10: independent hands-on verification of the PR-review workflow specifically (most community feedback covers general CLI agentic use rather than the PR-review action itself), and no detail on configurability/false-positive rates.

   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “On-demand Assistance: Mention @gemini-cli in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “On-demand Assistance: Mention `@gemini-cli` in issues and pull requests for help with debugging, explanations, or task delegation”
   • [github] “@github List my open pull requests”
   • [community] “We have tried out Gemini code review vs Copilot code review and Gemini is consistently offering better code review tips. It has officially c…”

   proof ↗⚑ flag

   Conductor—none0/10

   Conductor'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.”

   proof ↗⚑ flag

3. developerInspect diffs and run checks to catch problems before merging

   weight 3 · round drawn
   Gemini CLI~partialcommunity6/10

   Gemini CLI supports GitHub PR review automation with contextual feedback (gemini-cli-gh-10) and issue triage, plus community reports confirm it catches bugs reviewers missed (gemini-cli-comm-20), supporting diff inspection and pre-merge checks. However, there's no dedicated diff-viewing UI or built-in test/lint-running check suite documented, and community reports raise concerns about reliability, security prompts, and agentic mistakes (gemini-cli-comm-14, gemini-cli-comm-17). missing for 10: dedicated diff-inspection UI/commands, built-in CI/test-running integration, and stronger independent corroboration of reliability for pre-merge checks.

   • [github] “Pull Request Reviews: Automated code review with contextual feedback and suggestions”
   • [github] “Issue Triage: Automated labeling and prioritization of GitHub issues based on content analysis”
   • [github] “Automate operational tasks like querying pull requests or handling complex rebases”
   • [community] “We have tried out Gemini code review vs Copilot code review and Gemini is consistently offering better code review tips. It has officially c…”
   • [community] “The problem is that Gemini CLI simply doesn't work. Beside simplest tasks like creating a new release it is useless as a coding assistant. D…”
   • [community] “However, it does seem that Gemini pays less attention to security than Claude Code. Gemini will happily open in my root directory. Claude Co…”

   proof ↗⚑ flag

   Conductor~partialclaimed6/10

   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.”

   proof ↗⚑ flag

Safe execution

1. engineering-leadControl which external tools and integrations the agent is allowed to access

   weight 2 · round drawn
   Gemini CLI~partialcommunity5/10

   Gemini CLI supports configuring MCP servers via ~/.gemini/settings.json and exposes /tools and /mcp commands to inspect and manage available tools, giving engineering leads some control over which integrations are enabled. However, evidence lacks any centralized admin/policy control, allowlist/denylist enforcement, or org-wide governance mechanism for restricting tool access across a team, and community reports note weak security defaults (e.g. opening root directories without prompting). missing for 10: org-level/admin enforcement of tool allowlists, granular permission scoping per tool/integration, independent verification that access controls are robust rather than just configurable per-user.

   • [github] “Configure MCP servers in ~/.gemini/settings.json to extend Gemini CLI with custom tools”
   • [claimed-docs] “Comandos de Gemini CLI: /memory, /stats, /tools y /mcp”
   • [community] “However, it does seem that Gemini pays less attention to security than Claude Code. Gemini will happily open in my root directory. Claude Co…”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   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.”

   proof ↗⚑ flag

2. engineering-leadHave the agent operate inside a sandbox when interacting with code, tools, and network resources

   weight 2 · round to Conductor
   Gemini CLI—none0/10

   The evidence pack contains no vendor documentation of a sandboxed execution mode for code/tool/network interactions—only a vague 'Enterprise features: Advanced security and compliance' bullet with no detail. Community evidence actually points the other way: reviewers note Gemini CLI 'happily opens in my root directory' without any directory-trust prompt, unlike Claude Code, and one report describes it destructively running file-system commands, suggesting a lack of sandboxing guardrails rather than presence of them.

   • [github] “Enterprise features: Advanced security and compliance”
   • [community] “However, it does seem that Gemini pays less attention to security than Claude Code. Gemini will happily open in my root directory. Claude Co…”
   • [community] “Gemini told the user: 'I have failed you completely and catastrophically... I have lost your data. This is an unacceptable, irreversible fai…”

   proof ↗⚑ flag

   Conductor~partialcommunity5/10

   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.”

   proof ↗⚑ flag

Security checks

1. engineering-leadSee license and public-code matching references for AI-suggested code

   weight 1 · round drawn
   Gemini CLI—none0/10

   No evidence anywhere in the pack of license attribution, public-code matching, or provenance references for AI-suggested code; features listed cover code editing, review, MCP, PR automation, etc. but nothing about license/originality detection.

   ⚑ flag

   Conductor—none0/10

   No 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.

   ⚑ flag