Codex vs OpenCode

Agent access

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

   weight 2 · round drawn
   Codex~partialprobed4/10

   A dedicated llms.txt file is absent (404 at platform.openai.com/llms.txt), but Codex does publish machine-readable markdown docs (learn.chatgpt.com/docs/codex/cli.md) confirmed reachable by probe, which is an agent-friendly doc format an AI agent could be pointed at. Missing for 10: a standard llms.txt manifest, evidence of agents actually being pointed at these docs, and confirmation across all doc pages (docs/codex.md also 404s).

   • [probe] “PROBE llms.txt: HTTP 404 at https://platform.openai.com/llms.txt”
   • [probe] “PROBE docs-md: HTTP 404 at https://platform.openai.com/docs/codex.md”
   • [probe] “official CLI documented at https://learn.chatgpt.com/docs/codex/cli”

   proof ↗⚑ flag

   OpenCode~partialprobed4/10

   OpenCode's own llms.txt file returns 404, so there is no dedicated llms.txt for agents, but probes show that docs pages are available in machine-readable Markdown form (.md suffix returns 200), which serves an analogous agent-oriented documentation function. There's no first-party statement about llms.txt support or explicit agent-doc pointing workflow. Missing for 10: an actual llms.txt endpoint, documentation instructing users to point agents at machine-readable docs, and confirmation that agents can consume the .md docs as intended.

   • [probe] “PROBE llms.txt: HTTP 404 at https://opencode.ai/llms.txt”
   • [probe] “PROBE docs-md: HTTP 200 at https://opencode.ai/docs/.md import { Tabs, TabItem } from "@astrojs/starlight/components" import config from "..…”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex✓fullclaimed8/10

   Codex CLI explicitly documents non-interactive execution via `codex exec` for use in repeatable workflows, scripts, and CI/CD pipelines (codex-docs-19, codex-docs-32), and permissions/sandbox controls can be configured for unattended runs (codex-docs-17, codex-docs-39). Missing for 10: no independent case study or CI provider (e.g. GitHub Actions) integration example, and no explicit exit-code/output-format spec for CI parsing.

   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”
   • [claimed-docs] “Choose when Codex can edit files or run commands without asking, and inspect the active sandbox and writable roots before you continue.”
   • [claimed-docs] “Set the boundaries for each run — /permissions: Choose when Codex can edit files or run commands without asking, and inspect the active sand…”

   proof ↗⚑ flag

   OpenCode✓fullprobed9/10

   OpenCode explicitly supports headless/CI use via `opencode run` for non-interactive execution, `opencode serve` for a headless HTTP server with OpenAPI, `--auto` for unattended permission approval, a JS/TS SDK for programmatic control, and a first-party GitHub Actions integration triggered by PR comments. This covers CLI scripting, server automation, and CI pipelines with concrete docs and an OpenAPI endpoint confirmed live. missing for 10: independent third-party validation of CI reliability at scale (community evidence mostly covers interactive TUI use, not CI-specific automation).

   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Codex✓fullclaimed9/10

   Codex CLI explicitly supports adding local/remote MCP servers via `codex mcp add`, inspecting available tools before use, and viewing active servers via `/mcp`; this configuration is shared across ChatGPT desktop app, CLI, and IDE extension. Docs also describe using MCP to connect to third-party tools like browsers or Figma. Missing for 10: independent hands-on verification of MCP tool usage in a real session beyond first-party docs.

   • [claimed-docs] “Add local or remote MCP servers, authenticate when needed, and inspect the tools available to the current session before Codex uses them.”
   • [claimed-docs] “The ChatGPT desktop app, Codex CLI, and IDE extension share this configuration. Once you configure your MCP servers, you can switch among th…”
   • [claimed-docs] “Connect external tools with MCP — codex mcp: Add local or remote MCP servers, authenticate when needed, and inspect the tools available to t…”
   • [claimed-docs] “Model Context Protocol (MCP) connects models to tools and context. Use it to give ChatGPT or Codex access to third-party documentation, or t…”
   • [claimed-docs] “codex mcp add <server-name> --env VAR1=VALUE1 --env VAR2=VALUE2 -- <stdio server-command>”
   • [claimed-docs] “In the `codex` TUI, use `/mcp` to see your active MCP servers.”

   proof ↗⚑ flag

   OpenCode✓fullclaimed9/10

   OpenCode has first-party documentation dedicated to adding external tools via MCP, supporting both local and remote servers, directly matching the story. This is corroborated indirectly by community discussion of OpenCode's tool/agent ecosystem, though no hands-on account specifically tests MCP server plugging. Missing for 10: independent/hands-on confirmation specifically of MCP server usage (community evidence discusses agents/tools generally but not MCP specifically).

   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
   • [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Codex✓fullprobed9/10

   Codex ships an official, well-documented CLI (npm install -g @openai/codex) with rich agentic capabilities: local repo editing, exec/non-interactive scripting, MCP support, subagents, image input, sandbox/permissions control, cloud task delegation, and shell completions — all first-party documented and confirmed via GitHub repo and docs. Missing for 10: independent hands-on benchmarking specifically of CLI workflows (community evidence focuses mostly on model quality/UX rather than CLI mechanics) and some Linux-specific gaps noted by users.

   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”
   • [github] “npm install -g @openai/codex”
   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”
   • [claimed-docs] “Connect external tools with MCP — codex mcp: Add local or remote MCP servers, authenticate when needed, and inspect the tools available to t…”
   • [claimed-docs] “Split up a larger investigation — subagents: Ask Codex to delegate focused work to specialized agents, then bring their findings back into t…”
   • [claimed-docs] “Choose when Codex can edit files or run commands without asking, and inspect the active sandbox and writable roots before you continue.”
   • [claimed-docs] “Install the Codex CLI with the standalone installer for macOS and Linux.”
   • [probe] “official CLI documented at https://learn.chatgpt.com/docs/codex/cli”

   proof ↗⚑ flag

   OpenCode✓fullprobed9/10

   OpenCode ships an official CLI with documented commands (opencode run, opencode serve, init, install via curl/npm) and dedicated CLI docs, corroborated by community users who actively use it as their primary daily-driver harness. Missing for 10: independent benchmarking of CLI completeness/stability beyond anecdotal community reports (some bug complaints noted but not disputing existence of an official CLI).

   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
   • [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “npm install -g opencode-ai”
   • [probe] “official CLI documented at https://opencode.ai/docs/cli/”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”

   proof ↗⚑ flag

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

   weight 3 · round to OpenCode
   Codex~partialcommunity5/10

   Codex documents multiple programmatic entry points — an MCP server interface for JSON-RPC control (though explicitly marked deprecated/experimental in favor of an undocumented 'app server'), a non-interactive `codex exec` mode for scripts/CI, and 'API key' usage — but these come with real caveats: API-key use 'requires additional setup', the flagship gpt-5.3-codex model was reportedly not yet available via API, and the primary MCP server route is deprecated rather than a stable first-class API. missing for 10: a single stable, non-deprecated documented public API surface, confirmation that the current model is API-accessible, and independent corroboration that third parties successfully drive Codex via this API.

   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [github] “Codex MCP Server Interface [experimental]: a JSON-RPC API that runs over the Model Context Protocol (MCP) transport to control a local Codex…”
   • [claimed-docs] “codex mcp-server is deprecated. Use the Codex app server instead. ... This page documents the deprecated command for existing integrations. …”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”
   • [community] “gpt-5.3-codex isn't available on the API yet — 'We are working to safely enable API access soon.'”

   proof ↗⚑ flag

   OpenCode✓fullprobed8/10

   OpenCode ships a documented headless server (`opencode serve`) exposing an OpenAPI endpoint, confirmed live via probe (opencode-probe-3), plus a type-safe JS/TS SDK for programmatic control, and its CLI supports non-interactive scripted use (`opencode run`). missing for 10: independent third-party corroboration of SDK/API usage in production, and no evidence of versioning/stability guarantees or broader language SDK support beyond JS/TS.

   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”
   • [claimed-docs] “Use it to build integrations and control opencode programmatically.”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex~partialclaimed5/10

   OpenAI's platform docs describe RBAC and project/org-scoped API keys/custom roles, and Codex can authenticate via an API key (codex-gh-4), so scoped credentials are technically available to a Codex-using account. However, none of the evidence ties this RBAC/API-key scoping specifically to configuring or restricting a Codex agent's own permissions — missing for 10: Codex-specific docs on issuing least-privilege keys for agent sessions, guidance on scoping credentials per-task/per-repo, and independent confirmation that this RBAC applies to Codex's own execution rather than just general API access.

   • [claimed-docs] “Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashb…”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”

   proof ↗⚑ flag

   OpenCode~partialclaimed3/10

   OpenCode's permission config lets you restrict which actions (edit, bash, etc.) an agent may auto-run, prompt for, or block, and enterprise SSO integration centralizes access to an internal AI gateway — both are adjacent to least-privilege agent control, but neither is a mechanism for issuing scoped API credentials/keys specifically to an agent. missing for 10: explicit scoped API-key/credential issuance for agents, credential expiry/rotation, per-agent key scoping documentation, independent verification of this capability.

   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to OpenCode
   Codex~partialcommunity6/10

   Codex is a coding agent, but the evidence shows a genuine SDK-adjacent surface: the underlying OpenAI Responses API has an official OpenAPI spec and multi-language code samples (Python, TypeScript, Go, Ruby, Java, HTTP, CLI), and Codex integrates via CLI/MCP for programmatic extension. However, there is no evidence of an official Codex-specific SDK (as opposed to the general OpenAI API SDK), and API access for the Codex model itself is explicitly noted as not yet available. missing for 10: a dedicated Codex SDK/library distinct from the general OpenAI Responses API, confirmation that Codex agent capabilities (not just chat completions) are exposed via SDK, independent developer corroboration of building against these SDKs.

   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”
   • [github] “A machine-readable description of the OpenAI REST API, authored in OpenAPI 3.1.”
   • [community] “gpt-5.3-codex isn't available on the API yet — 'We are working to safely enable API access soon.'”
   • [claimed-docs] “Add local or remote MCP servers, authenticate when needed, and inspect the tools available to the current session before Codex uses them.”

   proof ↗⚑ flag

   OpenCode✓fullprobed8/10

   OpenCode documents a dedicated JS/TS SDK ('type-safe client for interacting with the server... use it to build integrations and control opencode programmatically') plus a headless server mode (`opencode serve`) exposing an OpenAPI endpoint, confirmed live by probe (openapi.json returns valid schema). This gives AI-native users official, documented programmatic access beyond the CLI/TUI. Missing for 10: independent hands-on developer reports of building against the SDK, and broader multi-language SDK coverage beyond JS/TS.

   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “Use it to build integrations and control opencode programmatically.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Codex—none0/10

   No evidence in the pack mentions webhooks or event subscription capabilities for Codex; the product exposes MCP servers, CLI, and cloud task integrations but nothing about outbound webhook events for AI-native consumers.

   ⚑ flag

   OpenCode—none0/10

   Evidence shows OpenCode has a headless server (`opencode serve`) exposing an OpenAPI/HTTP endpoint and an SDK for programmatic control, but there is no mention anywhere of webhook subscriptions or event-push notifications that clients could register for.

   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server.”

   proof ↗⚑ flag

Agentic features

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

   weight 2 · round to OpenCode
   Codex~partialclaimed6/10

   Codex generates AI-driven insights and suggestions specifically about code: it produces prioritized review findings, diffs, and summaries during automated reviews and delegated tasks (codex-docs-5, codex-docs-10, codex-docs-41, codex-docs-45), and can delegate to subagents for deeper investigation (codex-docs-35). However, this is scoped to code/repository data rather than general business or product data insights. Missing for 10: evidence of insight generation over non-code data sources, dashboards, or analytics-style summaries beyond code review findings.

   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Split up a larger investigation — subagents: Ask Codex to delegate focused work to specialized agents, then bring their findings back into t…”

   proof ↗⚑ flag

   OpenCode✓fullcommunity7/10

   OpenCode's plan/explore agents let users get AI-generated code analysis and suggested changes without modifying the codebase, directly matching the story of AI-generated insights over the user's data (their code) (opencode-docs-7, opencode-docs-60, opencode-docs-61). Community mentions confirm active use of the agent for analysis/harness work (opencode-comm-1, opencode-comm-3). Missing for 10: independent examples of insight quality/output, and no evidence of insights beyond code (e.g., broader data analytics).

   • [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex✓fullclaimed7/10

   Codex cloud supports delegating longer tasks that run in isolated cloud environments in parallel, triggered from GitHub, GitLab, Linear, or Slack, and returning results (diff/PR) when ready — a clear background-automation workflow, and the CLI also supports non-interactive/repeatable workflows for scripted automation. Missing for 10: no documentation of scheduled/cron-style recurring triggers, and no independent/hands-on confirmation that long unattended background runs work reliably (community commentary focuses on interactive model quality/UX rather than background automation specifically).

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”

   proof ↗⚑ flag

   OpenCode~partialcommunity6/10

   OpenCode ships a documented GitHub Actions integration where mentioning /opencode or /oc in a comment triggers it to autonomously work in a new branch and submit a PR, plus a headless `serve` mode and `--auto` permission flag that let it run unattended, supporting background automations. However there's no dedicated scheduling/cron mechanism, and community evidence flags reliability issues (stuck sessions, tool-call failures) that undercut confidence in unattended runs. missing for 10: scheduled/triggered automation beyond GitHub comment mentions, independent evidence of long-running unattended background jobs succeeding reliably.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
   • [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”

   proof ↗⚑ flag

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

   weight 3 · round to OpenCode
   Codex✓fullclaimed8/10

   Codex documents explicit task delegation to its built-in agent, both for long-running cloud tasks ('Delegate a longer task and return when it is ready') and for sub-agent delegation within a session ('Ask Codex to delegate focused work to specialized agents, then bring their findings back into the main terminal session'), backed by detailed CLI/cloud docs. Missing for 10: independent hands-on verification specifically of the subagent delegation flow (community evidence discusses general agent quality/UX but not this feature directly).

   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Ask Codex to delegate focused work to specialized agents, then bring their findings back into the main terminal session.”
   • [claimed-docs] “Split up a larger investigation — subagents: Ask Codex to delegate focused work to specialized agents, then bring their findings back into t…”
   • [claimed-docs] “Move work to Codex cloud — codex cloud: Browse active and completed chats, submit work to a configured environment, and apply the result to …”
   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity9/10

   OpenCode's core function is exactly this: an AI coding agent you delegate tasks to via CLI/TUI/IDE/desktop ('opencode run "Explain how closures work..."'), with multiple agent personas (build, plan, explore) and multi-session parallel delegation, richly documented and corroborated by extensive hands-on community use as a daily coding harness. Missing for 10: no independent benchmark of delegation reliability across all model backends (some community reports of failed tool calls/edits with local models).

   • [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [claimed-docs] “You can use the **Tab** key to switch between primary agents during a session.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
   • [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex✓fullcommunity8/10

   Codex CLI, IDE extension, cloud, and web surfaces are all operated by natural-language prompts/chats — e.g. starting tasks from prompts, resuming chats, delegating subagents, pasting images into the composer, and non-interactive `codex exec` for scripted natural-language instructions — all documented as the primary interaction mode across surfaces. Community threads corroborate heavy real-world use of this conversational/agentic workflow, even amid quality complaints about model performance. missing for 10: independent benchmarking specifically of natural-language command comprehension/robustness (community evidence is about overall agent quality/speed, not NL parsing specifically).

   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Ask Codex to delegate focused work to specialized agents, then bring their findings back into the main terminal session.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “`codex resume`: Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”
   • [claimed-docs] “Bring visual context into the prompt — codex --image: Pass an error screenshot, architecture diagram, or design reference with the first pro…”
   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”
   • [community] “Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good…”

   proof ↗⚑ flag

   OpenCode✓fullcommunity9/10

   OpenCode's core interface is natural-language driven: the CLI example `opencode run "Explain how closures work in JavaScript"` and TUI/desktop/IDE modes are all built around conversational prompts to an AI agent that then edits code, opens branches, and submits PRs. Community usage (comm-1, comm-3, comm-4, comm-11) confirms this is how real users operate it day-to-day as their primary coding harness. Missing for 10: no independent benchmark specifically validating breadth of natural-language command coverage beyond docs/anecdotes.

   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
   • [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Codex
   Codex~partialclaimed5/10

   The evidence shows OpenAI's general API reference (developers.openai.com) has runnable, per-language code samples with live examples, which an AI-native user could explore. However this is the general OpenAI Responses API reference, not a Codex-specific interactive API reference, and Codex itself is documented as a CLI/agent product rather than an API with its own dedicated reference docs. Missing for 10: a Codex-specific API reference page, evidence of interactivity beyond code-sample selection (e.g., live sandbox execution), and any Codex-specific documentation of this reference.

   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”

   proof ↗⚑ flag

   OpenCode~partialprobed3/10

   OpenCode exposes a raw OpenAPI spec via `opencode serve` and openapi.json, and offers an SDK for programmatic use, but there is no evidence of an actual interactive API reference UI (e.g., Swagger/Redoc-style docs) with runnable/try-it examples. Missing for 10: dedicated interactive API explorer page, runnable code examples, independent confirmation of such a UI existing.

   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex~partialclaimed4/10

   OpenAI publishes a machine-readable OpenAPI 3.1 spec for its REST API (codex-gh-9) and Codex can be used via that API (codex-gh-4), but the evidence never confirms this spec explicitly covers or is dedicated to Codex-specific endpoints, nor is there a direct 'download spec' link tied to Codex docs. missing for 10: a Codex-specific OpenAPI/spec file, explicit download instructions, or confirmation the general OpenAI OpenAPI spec includes Codex CLI/agent endpoints.

   • [github] “A machine-readable description of the OpenAI REST API, authored in OpenAPI 3.1.”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”

   proof ↗⚑ flag

   OpenCode✓fullprobed9/10

   The docs explicitly state that `opencode serve` runs a headless HTTP server exposing an OpenAPI endpoint, and a live probe confirms a downloadable machine-readable OpenAPI spec at https://opencode.ai/openapi.json. This directly satisfies the story of downloading a machine-readable API spec. Missing for 10: independent/community corroboration of using this OpenAPI spec in practice.

   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 1 · round to Codex
   Codex~partialcommunity6/10

   Codex offers isolated cloud task environments and CLI sandbox controls (writable roots, permission gating) that keep agent actions contained rather than acting directly on a live system, which functions as a sandbox layer for testing changes. However, there's no explicit documentation of test-vs-production data separation, and a community report raises unresolved concerns about the sandbox reading sensitive filesystem data without asking. Missing for 10: explicit production-data isolation guarantees, first-party documentation addressing the raised sandbox-safety concern, and independent verification that isolated environments never touch real prod data.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [claimed-docs] “Choose when Codex can edit files or run commands without asking, and inspect the active sandbox and writable roots before you continue.”
   • [community] “Does that version of Codex still read sensitive data on your file system without even asking? Just curious. [links to github.com/openai/code…”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode's docs describe permission controls, --auto approval, and external_directory restrictions, but there is no evidence of a dedicated sandbox/staging environment or mechanism to test against non-production data separate from the user's actual working directory/production files. Community reports even flag security gaps in the local server (opencode-comm-18) rather than any sandboxing feature for safe testing.

   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
   • [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex~partialclaimed3/10

   There is a documented OpenAPI 3.1 spec and API reference (codex-gh-9, codex-docs-29) and one concrete example of a deprecation notice (codex mcp-server deprecated in favor of the Codex app server, codex-docs-23), showing some practice of versioning and deprecation. However, there is no comprehensive, documented deprecation policy (timelines, notice periods, version numbering scheme) covering the Codex/OpenAI API generally. Missing for 10: an explicit deprecation policy document, API version numbering scheme, and independent corroboration of adherence to it.

   • [github] “A machine-readable description of the OpenAI REST API, authored in OpenAPI 3.1.”
   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”
   • [claimed-docs] “codex mcp-server is deprecated. Use the Codex app server instead. ... This page documents the deprecated command for existing integrations. …”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode does expose programmatic surfaces (the JS/TS SDK, `opencode serve` HTTP server, and an OpenAPI spec at openapi.json), so an API-versioning/deprecation-policy axis is applicable. However, none of the evidence mentions API version numbers, backward-compatibility guarantees, or any documented deprecation policy/process for the SDK or server API.

   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex~partialclaimed6/10

   Codex supports running multiple cloud tasks in parallel across repos (codex-docs-1, codex-docs-3, codex-docs-6) and delegating focused work to specialized sub-agents within a session (codex-docs-13), which gives some bulk/parallel automation capability. However, there's no explicit evidence of a bulk operation primitive (e.g., batch-apply an action across many files/items/tickets in one command) — the parallelism described is task-level (multiple independent runs) rather than a documented 'operate over N items at once' feature. Missing for 10: explicit bulk/batch API or CLI verb for acting across many items in one invocation, and independent confirmation of large-scale parallel throughput in practice.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Ask Codex to delegate focused work to specialized agents, then bring their findings back into the main terminal session.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”

   proof ↗⚑ flag

   OpenCode~partialclaimed4/10

   OpenCode's CLI (`opencode run`), SDK, and headless `opencode serve` provide programmatic hooks that could be scripted to loop over many files/tasks, and 'multi-session' lets multiple agents run in parallel on a project — but there is no documented first-class 'bulk operation' feature (e.g. batch refactor, mass file edit) or example of applying one command across many items at once. Missing for 10: explicit bulk/batch operation feature, documentation or examples of running the same task across many files/repos, independent evidence of successful large-scale batch use.

   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “Use it to build integrations and control opencode programmatically.”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”

   proof ↗⚑ flag

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

   weight 3 · round to OpenCode
   Codex—none0/10

   Codex supports triggering tasks from external events (GitHub/GitLab/Linear/Slack) and running non-interactive workflows, but there is no evidence of a user-defined rules engine that lets users specify arbitrary trigger conditions and automated actions (e.g., 'on X event, do Y') — this is closer to integration hooks than a rules/automation framework. missing for 10: evidence of a rules/trigger definition interface, conditional logic configuration, or event-to-action mapping system that users can author themselves.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”

   proof ↗⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode supports some automatic rule-triggered behavior: GitHub integration lets a PR/issue comment mention (`/opencode` or `/oc`) automatically trigger the agent to execute tasks in a GitHub Actions runner, and the `permission` config lets you define rules for auto-approving, prompting, or blocking specific tool actions. This covers event-triggered automation in a narrow sense, but there's no general-purpose, user-defined event/rule engine (e.g., file-change hooks, cron-like triggers, custom event listeners) described in the docs. Missing for 10: a general automation/hooks system beyond GitHub comment mentions and permission gating, and independent evidence confirming reliability of these triggers in practice.

   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “OpenCode uses the permission config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “For most permissions, you can use an object to apply different actions based on the tool input.”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Codex—none0/10

   The evidence shows Codex can run in CI/scripts (codex exec), be triggered from GitHub/GitLab/Slack, and run cloud tasks, but there is no mention of a native recurring/scheduled job or cron-like trigger mechanism within Codex itself. Automation is triggered by external events or manual invocation, not scheduled recurrence.

   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Move work to Codex cloud — codex cloud: Browse active and completed chats, submit work to a configured environment, and apply the result to …”

   proof ↗⚑ flag

   OpenCode—none0/10

   No evidence of any scheduling, cron-like, or recurring workflow trigger capability; OpenCode's docs cover CLI, agents, MCP, permissions, SDK, GitHub Actions triggers, and server mode but none describe scheduling or recurring automation. missing for 10: any scheduler/cron feature, recurring job configuration, or workflow trigger on a schedule.

   ⚑ flag

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

   weight 1 · round to Codex
   Codex~partialclaimed4/10

   Codex's CLI includes a dedicated review command that inspects diffs/commits without modifying the working tree (codex-docs-10, codex-doces-41/45), and it operates within git repos so changes are inherently versioned and revertible via git; skills/plugins can be packaged as reusable automations (codex-docs-20/42). However, there is no documented mechanism to version, review, or roll back the automations/skills/workflows themselves (e.g., skill version history, rollback of a plugin config, audit trail for automation changes) — only code diffs are reviewed. Missing for 10: explicit versioning of skills/automations, a rollback UI/command for automation configs, and independent evidence of this workflow in practice.

   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without leaving the CLI.”
   • [claimed-docs] “Use skills and plugins: Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without l…”

   proof ↗⚑ flag

   OpenCode—none0/10

   Evidence covers agent creation, permissions, sessions, and sharing, but there is no documentation or community mention of versioning automations, reviewing change history, or rolling back agent/workflow configurations — session share links are for reference/debugging, not version control or rollback.

   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “Share links Share a link to any session for reference or to debug”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “This command will guide you through creating a new agent with a custom system prompt and permission configuration.”

   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 Codex
   Codex✓fullcommunity8/10

   Codex cloud lets users delegate tasks that run in isolated cloud environments, inspect summaries/diffs, request follow-ups, and open pull requests for review, effectively building/testing/demoing changes end-to-end for user review (codex-docs-1,5,6,7,37). Community commentary corroborates real-world agentic task completion, though with performance/reliability caveats. Missing for 10: independent hands-on verification specifically of the cloud (not CLI) workflow's demo/test artifacts, and no explicit mention of a 'demo' step (e.g., live preview) beyond diff/PR review.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Start and review work from the web or Codex CLI.”
   • [claimed-docs] “Move work to Codex cloud — codex cloud: Browse active and completed chats, submit work to a configured environment, and apply the result to …”
   • [community] “Often Claude Code Opus 4.6, on hard enough problems, can do the impression of acting fast without really making progress. Then you spin the …”
   • [community] “Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good…”

   proof ↗⚑ flag

   OpenCode~partialclaimed6/10

   OpenCode's GitHub integration lets it work in a new branch and submit a PR autonomously when mentioned via `/opencode` in GitHub Actions, and its share-links/session feature lets a reviewer inspect the agent's work — together covering 'build' and 'demo for review' in a cloud context. However, there is no explicit documentation of an automated testing step as part of this workflow, and the 'cloud agent' aspect relies on self-hosted GitHub Actions runners rather than a dedicated managed cloud agent service. Missing for 10: explicit test-execution/validation step in the PR workflow, and a first-party fully-hosted cloud agent (not just Actions-runner based) with demo artifacts.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “Share links Share a link to any session for reference or to debug”
   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”

   proof ↗⚑ flag

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

   weight 3 · round to Codex
   Codex✓fullclaimed7/10

   OpenAI's docs describe a dedicated Codex cloud mode that runs tasks in isolated cloud environments, in parallel, triggered from web/GitHub/GitLab/Linear/Slack, with configurable repo setup and a workflow to inspect diffs/PRs on completion, plus a CLI command (`codex cloud`) to submit and later pull results locally — squarely matching the story of delegating longer background tasks to an isolated cloud environment. missing for 10: independent or hands-on community corroboration specifically validating the cloud/background execution feature (community evidence in the pack discusses CLI/app UX and model quality, not the cloud delegation flow itself).

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Move work to Codex cloud — codex cloud: Browse active and completed chats, submit work to a configured environment, and apply the result to …”
   • [github] “If you are looking for the cloud-based agent from OpenAI, Codex Web, go to chatgpt.com/codex.”
   • [github] “If you are looking for the <em>cloud-based agent</em> from OpenAI, <strong>Codex Web</strong>, go to <a href="https://chatgpt.com/codex">cha…”

   proof ↗⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode documents GitHub integration where mentioning /opencode or /oc triggers it to work in a new branch and submit a PR, executing tasks inside the GitHub Actions runner (an isolated cloud environment), which supports background delegation of coding tasks. However, there's no dedicated general-purpose 'cloud agent' product, persistent cloud session management, or evidence of handling arbitrarily long-running tasks outside the GitHub Actions context. missing for 10: a dedicated hosted/cloud sandbox environment independent of GitHub Actions, evidence of long-running task monitoring/resumption in the cloud, and independent hands-on confirmation of this workflow succeeding.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex~partialclaimed6/10

   Codex Cloud docs state you can configure the dependencies, tools, variables, and setup steps each repository needs for isolated cloud environments, directly matching the story. However, there is no detail on how reproducibility is guaranteed (e.g., container images, caching, version pinning) or independent hands-on confirmation of this setup workflow. Missing for 10: concrete configuration file/schema details, reproducibility guarantees, and independent verification of the setup working as documented.

   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”

   proof ↗⚑ flag

   OpenCode—none0/10

   The evidence shows OpenCode as a terminal/IDE agent with GitHub PR automation and a headless `serve` mode, but nothing describes a mechanism for developers to declare a reproducible cloud environment (base image, dependencies, setup scripts) that the agent provisions before running. Missing for 10: any devcontainer/config-file spec for cloud sandbox provisioning, dependency installation steps, or documented cloud execution environment configuration.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”

   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 drawn
   Codex~partialcommunity6/10

   Codex Cloud supports running multiple tasks in parallel in isolated cloud environments, triggered from GitHub/GitLab/Linear/Slack, and delegating longer tasks to return to later, which covers parallel/async agent work. However, there is no explicit evidence of orchestrating large 'fleets' of many simultaneous agents, no stated duration limits confirming multi-day autonomous runs, and community feedback highlights usage-limit throttling that would constrain sustained parallel/long-running fleets. missing for 10: evidence of fleet-scale orchestration (many concurrent agents), confirmed multi-day autonomous run duration, and independent confirmation that parallel tasks aren't throttled by usage limits.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [community] “Codex is my favorite UX for anything as it edits the files and I can use the proper tooling to adjust and test stuff... However lately the l…”
   • [community] “The main issue I have with Codex is that the best model is insanely slow, except at nights and weekends when Silicon Valley goes to bed... I…”

   proof ↗⚑ flag

   OpenCode~partialcommunity6/10

   OpenCode documents multi-session support ('Start multiple agents in parallel on the same project'), subagents with per-agent model choice, and GitHub Actions integration where mentioning /opencode lets it execute unattended tasks and open PRs — all pointing toward parallel, semi-autonomous agent operation. However, there is no explicit documentation or evidence of orchestrating large 'fleets' of agents or of sustained autonomous operation over hours/days, and community reports note agents 'randomly stuck, especially for long/nested sessions,' undercutting long-horizon reliability. Missing for 10: dedicated fleet-management/orchestration tooling, explicit hours/days-long autonomous run support, and independent confirmation of stable long-running parallel agent execution.

   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”

   proof ↗⚑ flag

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

   weight 1 · round to Codex
   Codex~partialclaimed6/10

   Docs confirm Codex cloud can run tasks in parallel in isolated cloud environments without tying up the local machine, and results can be inspected (summary/diff) before choosing to follow up or open a PR — this covers running multiple attempts and reviewing outcomes. However, there's no explicit documentation of a dedicated 'compare multiple attempts side-by-side' UI/workflow, and no independent/community evidence confirming this parallel-comparison workflow works well in practice. missing for 10: explicit side-by-side comparison UI documentation, independent hands-on confirmation of comparing parallel attempts.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”

   proof ↗⚑ flag

   OpenCode~partialcommunity4/10

   OpenCode documents 'multi-session' support to start multiple agents in parallel on the same project (opencode-docs-17/38) and share links to sessions for reference/debugging (opencode-docs-18/37), which enables running parallel work and inspecting different sessions. However, there is no documented feature for running multiple attempts at the *same* task specifically to compare outcomes and pick a winner (e.g., no diff/compare UI or attempt-ranking workflow), and community threads discuss general session-state bugs rather than this comparison workflow. Missing for 10: explicit same-task multi-attempt spawning, a built-in comparison/diff view across attempts, and evidence of choosing/merging the best result.

   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “Share links Share a link to any session for reference or to debug”
   • [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”

   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 Codex
   Codex~partialclaimed5/10

   Codex cloud supports starting tasks from external triggers (GitHub/GitLab issues & PRs, Linear issues, Slack messages) and running them in parallel isolated environments, which covers the 'triggers' half of the story, but there's no evidence of a true schedule/cron-based always-on agent that proactively maintains a repo without an external event. Missing for 10: explicit scheduled/cron execution, evidence of continuous unattended monitoring/maintenance loops, and independent confirmation these triggers reliably run autonomous fixes end-to-end.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode documents CLI/TUI/desktop agents, permission automation, GitHub Actions integration triggered by comments, and a headless server/SDK, but there is no evidence of scheduling (cron-like) or event-trigger-based always-on autonomous agents that proactively maintain/fix software without a user or PR-comment invocation. The GitHub integration is triggered by manual mentions, not autonomous scheduled monitoring. Missing for 10: scheduled/cron-based agent runs, event-driven triggers beyond manual mentions, autonomous 'always-on' background maintenance capability.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”

   proof ↗⚑ flag

Debugging

1. developerDebug issues and troubleshoot using natural-language queries

   weight 2 · round to OpenCode
   Codex~partialcommunity7/10

   Codex CLI docs show clear natural-language debugging workflows: exploring unfamiliar code, running local tools, passing error screenshots for context, and running dedicated code review that reports prioritized findings (codex-docs-8, codex-docs-9, codex-docs-10, codex-docs-12). However, community evidence shows mixed real-world reliability on agentic/coding tasks and no independent confirmation specifically validating debugging accuracy. Missing for 10: hands-on validation of debugging/troubleshooting accuracy, and independent case studies showing successful root-cause diagnosis via NL queries.

   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Pass an error screenshot, architecture diagram, or design reference with the first prompt, or paste an image into the interactive composer.”
   • [community] “Having used codex a fair bit I find it really struggles with … almost anything. However using the equivalent chat gpt model is fantastic.”
   • [community] “Often Claude Code Opus 4.6, on hard enough problems, can do the impression of acting fast without really making progress. Then you spin the …”

   proof ↗⚑ flag

   OpenCode✓fullcommunity7/10

   OpenCode is a terminal/IDE-based coding agent that takes natural-language queries (e.g. `opencode run "Explain how closures work..."`), can explore/read codebases via a dedicated read-only agent, and auto-loads LSPs so it can surface diagnostics/errors while chatting, all of which supports NL-driven debugging and troubleshooting; community users confirm using it as a daily 'harness' with good LSP integration for real work. missing for 10: no dedicated 'debug' or troubleshooting workflow docs, and community reports of failed tool calls/unreliable file edits with some models introduce real-world friction.

   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “A fast, read-only agent for exploring codebases.”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”

   proof ↗⚑ flag

Feature implementation

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

   weight 3 · round to Codex
   Codex✓fullclaimed8/10

   Codex explicitly supports starting work from a tracked issue (GitHub, GitLab, Linear) in cloud environments, running the task, inspecting the diff/summary, and opening a pull request when done, covering the full issue-to-PR loop. missing for 10: independent hands-on confirmation of a full issue-to-merged-PR workflow succeeding end-to-end, and detail on how issue context/acceptance criteria are actually parsed.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”

   proof ↗⚑ flag

   OpenCode✓fullclaimed7/10

   Docs explicitly state OpenCode can be asked to fix an issue or implement a feature, working in a new branch and submitting a PR with all changes, and it integrates with GitHub Actions via /opencode mentions to run tasks end-to-end. This directly covers issue-to-PR automation, though evidence is vendor-documented only without independent hands-on confirmation of the full issue-to-PR flow succeeding. Missing for 10: independent/community verification of a successful end-to-end issue-to-PR run, and detail on how issue tracking (e.g., linking to GitHub issues specifically) is handled beyond the GitHub Actions integration.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”

   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 drawn
   Codex✓fullcommunity8/10

   Codex CLI and cloud docs describe the core loop of natural-language task description leading to autonomous file inspection, editing, running local tools, and producing a diff/PR (codex-docs-30, codex-docs-9, codex-docs-6, codex-docs-5), and community commentary corroborates it does real multi-file edits ('it edits the files and I can use the proper tooling', 'shockingly good... no worse than average L3-L4 engs') alongside some negative UX complaints that don't dispute the core capability. Missing for 10: independent benchmark/case-study evidence specifically confirming complex multi-file refactors across large codebases, and some community reports of it 'struggling with almost anything' create mild quality tension without rising to a concrete dispute.

   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”
   • [community] “Codex is my favorite UX for anything as it edits the files and I can use the proper tooling to adjust and test stuff... However lately the l…”
   • [community] “Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good…”
   • [community] “Having used codex a fair bit I find it really struggles with … almost anything. However using the equivalent chat gpt model is fantastic.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity8/10

   OpenCode is explicitly a coding agent that takes plain-language instructions and edits code, with docs describing it fixing issues/implementing features and submitting PRs (opencode-docs-12), a CLI for prompting tasks (opencode-docs-22), and permission/auto-approve config for autonomous multi-file changes (opencode-docs-13/14). Community reports corroborate real-world multi-file coding use, with several users calling it their primary harness replacing Aider/Claude Code (opencode-comm-1, opencode-comm-3, opencode-comm-4, opencode-comm-11, opencode-comm-14), though some report unreliable file edits with certain local models and failed tool calls in general (opencode-comm-10, opencode-comm-12). Missing for 10: independent benchmark data on multi-file edit accuracy, and resolution of the reported local-model editing reliability issues.

   • [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
   • [community] “Claude is much better in OpenCode then in Claude Code, OpenCode is just better than Claude Code. Claude Code feels like a complete mess to u…”
   • [community] “OpenCode is awesome. Claude Code is nothing special at all. Last month I switched to just using OpenCode with a Codex $200/mo subscription, …”
   • [community] “I haven't been able to successfully get their CLI to reliably edit files when using local models, anybody else having the same problem?”
   • [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”

   proof ↗⚑ flag

Maintenance automation

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

   weight 3 · round drawn
   Codex~partialcommunity6/10

   Codex CLI/cloud docs describe a general-purpose coding agent that can inspect code, edit files, run local dev tools, automate repeatable work, and review diffs before PRs — capabilities broad enough to plausibly cover writing tests, fixing lint issues, resolving conflicts, and updating dependencies (codex-docs-8, codex-docs-9, codex-docs-30, codex-docs-41). However, none of the docs explicitly name test-writing, lint-fixing, merge-conflict resolution, or dependency updates as supported workflows, and community feedback is mixed on real-world reliability for complex agentic tasks (codex-comm-3, codex-comm-13). missing for 10: explicit documentation/examples of test generation, lint-fix automation, merge-conflict resolution, and dependency-update workflows, plus hands-on confirmation these specific tasks succeed.

   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [community] “Codex is my favorite UX for anything as it edits the files and I can use the proper tooling to adjust and test stuff... However lately the l…”
   • [community] “Having used codex a fair bit I find it really struggles with … almost anything. However using the equivalent chat gpt model is fantastic.”

   proof ↗⚑ flag

   OpenCode~partialcommunity6/10

   OpenCode is documented as a general-purpose coding agent that can edit files, run shell commands, and even autonomously fix issues and submit PRs (opencode-docs-12, opencode-docs-58), which implies it can perform tasks like writing tests, fixing lint, resolving conflicts, and updating deps as generic coding actions. However, none of the docs explicitly call out test-writing, lint-fixing, merge-conflict resolution, or dependency updates as named capabilities, and community reports note reliability gaps such as failed tool calls and unreliable file edits especially with local models (opencode-comm-10, opencode-comm-12). Missing for 10: explicit documentation or hands-on evidence of test generation, lint-fix workflows, merge-conflict resolution, and dependency-update automation.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
   • [community] “I haven't been able to successfully get their CLI to reliably edit files when using local models, anybody else having the same problem?”
   • [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”

   proof ↗⚑ flag

Multimodal generation

1. ai-native userGenerate a working app from a sketch, image, or PDF design

   weight 2 · round to Codex
   Codex~partialclaimed4/10

   Codex supports passing images (error screenshots, architecture diagrams, design references) into prompts, which is a partial building block for generating apps from a sketch/image, but there's no evidence of dedicated PDF-to-app workflows, multi-page design ingestion, or documented end-to-end 'sketch/image to working app' generation feature. missing for 10: explicit PDF design ingestion, dedicated image/design-to-app pipeline or template, independent hands-on demonstration of generating a full app from a design artifact.

   • [claimed-docs] “Pass an error screenshot, architecture diagram, or design reference with the first prompt, or paste an image into the interactive composer.”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode's evidence pack shows a terminal/IDE-based coding agent with text prompts, MCP, agents, and CLI/SDK, but there is no mention anywhere of image, sketch, or PDF design input being converted into a working app — no vision/multimodal input capability is documented.

   ⚑ flag

Codebase mapping

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

   weight 3 · round to OpenCode
   Codex~partialclaimed6/10

   Codex CLI docs explicitly mention exploring unfamiliar code and planning changes within a repository, and it can inspect code, run local dev tools, and review diffs/commits — supporting codebase orientation. However, there's no dedicated codebase-mapping/visualization feature, no evidence of dependency-graph or architecture-summary generation, and community feedback focuses on agentic task execution rather than comprehension aids. Missing for 10: dedicated codebase-map/architecture-overview feature, independent hands-on evidence of effectively onboarding to unfamiliar large codebases, and richer navigation/search tooling beyond terminal chat resume.

   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity7/10

   OpenCode ships a dedicated read-only 'explore' agent for scanning codebases and a 'plan' agent that analyzes code and proposes changes without modifying files, backed by automatic LSP loading for the right language context and skills that surface repo-specific instructions; community notes call the LSP integration 'great' for understanding code. Missing for 10: no dedicated codebase-mapping/visualization feature, no independent benchmark of comprehension quality, and no first-hand user account describing successful architecture-level onboarding via these agents.

   • [claimed-docs] “A fast, read-only agent for exploring codebases.”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
   • [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”

   proof ↗⚑ flag

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

   weight 3 · round to OpenCode
   Codex~partialclaimed5/10

   Codex CLI docs explicitly state it can be started in a repository 'to explore unfamiliar code, plan a change, edit files, and run your local development tools' (codex-docs-9), implying the agent autonomously navigates the codebase rather than requiring manual file selection, and codex-gh-1 confirms it runs as an autonomous coding agent locally. However, there's no detailed documentation of how it builds a whole-codebase map/summary, no explicit 'explain codebase' feature, and no independent hands-on evidence confirming this works well on large unfamiliar repos. Missing for 10: dedicated codebase-mapping/summarization feature documentation, evidence of handling very large repos, and independent user reports validating this specific capability.

   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”

   proof ↗⚑ flag

   OpenCode~partialcommunity6/10

   OpenCode ships a dedicated read-only 'explore' agent explicitly for exploring codebases and a plan agent for analyzing code without edits, plus automatic LSP loading that gives it broader code awareness without manual file picking. However there's no documented feature for generating a full repo map/summary or explicit 'explain this whole codebase' workflow beyond agent tool use (e.g. grep/glob/read), and no independent hands-on evidence confirming it successfully maps a large unfamiliar codebase end-to-end. Missing for 10: explicit repo-map/codebase-summary feature, hands-on/independent confirmation of whole-codebase explanation without manual context selection.

   • [claimed-docs] “A fast, read-only agent for exploring codebases.”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “LSP enabled Automatically loads the right LSPs for the LLM”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”

   proof ↗⚑ flag

Context management

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

   weight 2 · round to Codex
   Codex~partialclaimed3/10

   Codex CLI supports `codex resume` to reopen or search past local chats in a repository, giving a limited form of session recall, but this requires manual user action rather than automatic memory building/recall across sessions. Missing for 10: evidence of automatic persistent memory (learned facts, preferences, or context) that Codex builds unprompted and recalls without explicit resume/search commands, and any cross-session synthesis beyond raw chat transcripts.

   • [claimed-docs] “Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”
   • [claimed-docs] “`codex resume`: Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”

   proof ↗⚑ flag

   OpenCode—none0/10

   No evidence in the pack describes any persistent memory feature that automatically builds or recalls context/knowledge across separate sessions; docs cover sessions, sharing, agents, MCP, skills, and permissions, but nothing about automatic cross-session memory persistence or recall.

   ⚑ flag

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

   weight 2 · round drawn
   Codex—none0/10

   No evidence in the pack describes Codex supporting multiple project directories or repositories being combined in a single session/context; documentation focuses on single-repository sessions, cloud tasks, and per-repository setup steps.

   ⚑ flag

   OpenCode—none0/10

   The evidence shows a permission flag (`external_directory`) that lets tool calls touch paths outside the working directory, but there is no documentation or community report describing a way to add multiple project directories into a single session for combined context. Multi-session and multi-agent features are about running parallel sessions, not merging directories into one context.

   • [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”

   proof ↗⚑ flag

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

   weight 3 · round to OpenCode
   Codex—none0/10

   The evidence pack covers Codex's CLI, cloud, MCP, and review features but contains no mention of a project-level instructions/config file (e.g., AGENTS.md or similar) for setting coding standards or conventions the agent should follow. This is a plausible and common capability for coding agents, but nothing in the pack documents or demonstrates it.

   ⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode's docs mention an `opencode init` step to set up a project (docs-21/39/56) and 'Agent skills' that let OpenCode discover reusable instructions from a repo or home directory (docs-8/28), which suggests some mechanism for project-level guidance, but no evidence explicitly describes a dedicated instructions/config file (e.g., AGENTS.md) for coding standards and conventions. Missing for 10: explicit documentation of a project instructions file format, guidance on writing coding-standards content into it, and independent/hands-on confirmation that the agent actually follows such a file.

   • [claimed-docs] “initialize OpenCode for the project by running the following command.”
   • [claimed-docs] “Next, initialize OpenCode for the project by running the following command.”
   • [claimed-docs] “initialize OpenCode for the project by running the following command”
   • [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
   • [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory.”

   proof ↗⚑ flag

Issue diagnosis

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

   weight 3 · round to Codex
   Codex✓fullclaimed7/10

   Codex CLI docs explicitly describe exploring unfamiliar code and running local dev tools to investigate issues, passing error screenshots for context, delegating focused investigation to subagents, and running dedicated reviews against uncommitted changes/commits/base branches to verify fixes before committing — covering reproduce, narrow-down, and verify steps. Missing for 10: no explicit 'reproduce a bug' walkthrough or first-hand/independent account of successfully diagnosing and fixing a real bug end-to-end with Codex.

   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Pass an error screenshot, architecture diagram, or design reference with the first prompt, or paste an image into the interactive composer.”
   • [claimed-docs] “Ask Codex to delegate focused work to specialized agents, then bring their findings back into the main terminal session.”
   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”

   proof ↗⚑ flag

   OpenCode~partialcommunity5/10

   OpenCode's general coding-agent capabilities (shell/tool execution, LSP integration, a read-only 'explore' agent, and a 'plan' agent for analysis without changes) imply support for investigating bugs and iterating on fixes, and community feedback confirms strong LSP-based codebase navigation. However, there is no explicit documentation of a reproduce/debug/verify workflow, test running, or root-cause tooling, and community reports cite failed tool calls and agents getting stuck on long sessions, undermining reliability for this exact workflow. Missing for 10: explicit debugging/test-execution documentation, first-party guidance on reproducing bugs or verifying fixes, and independent hands-on confirmation of successful root-cause workflows.

   • [claimed-docs] “A fast, read-only agent for exploring codebases.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “I've been trying various harnesses like Pi, OpenCode, Qwen Code, and Nanocoder. A common problem I keep running into is failed tool calls, r…”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”

   proof ↗⚑ flag

Marketplace

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

   weight 1 · round to OpenCode
   Codex✓fullclaimed7/10

   Codex CLI docs explicitly describe packaging repeatable instructions as "skills" and adding plugins to connect Codex to team tools/data from the CLI, directly matching the custom-skills story. Missing for 10: independent hands-on validation of skill creation/usage, and deeper documentation on skill authoring format/lifecycle beyond a single mention.

   • [claimed-docs] “Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without leaving the CLI.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity8/10

   OpenCode has a dedicated 'Agent Skills' feature that lets it discover reusable, on-demand instructions from repo or home directory via a native `skill` tool, directly matching the custom-skills story, and this is corroborated by community praise for its subagents/customizability. Missing for 10: no independent hands-on report specifically testing custom skill authoring/loading, and no detail on skill packaging/sharing ecosystem.

   • [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory. Skills are loaded on-demand via the native `skill…”
   • [claimed-docs] “Agent skills let OpenCode discover reusable instructions from your repo or home directory.”
   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”

   proof ↗⚑ flag

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

   weight 1 · round to Codex
   Codex~partialclaimed6/10

   Codex documents integration points for third-party ecosystem tools — triggering work from GitHub, GitLab, Linear, and Slack (partner platforms), and connecting to third-party MCP servers, plugins, and skills that give access to tools like Figma or a browser — which supports embedding partner-built capabilities into engineering workflows. However, the evidence is framed around Codex consuming tools/data sources rather than a curated marketplace of partner-built 'agent apps,' and there's no independent case study of a partner agent integration working end-to-end. Missing for 10: evidence of a partner/agent-app marketplace or certified third-party agent integrations, and independent verification of such integrations working in practice.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without leaving the CLI.”
   • [claimed-docs] “Use it to give ChatGPT or Codex access to third-party documentation, or to let it interact with developer tools like your browser or Figma.”
   • [claimed-docs] “Connect external tools with MCP — codex mcp: Add local or remote MCP servers, authenticate when needed, and inspect the tools available to t…”
   • [claimed-docs] “Use skills and plugins: Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without l…”
   • [claimed-docs] “Model Context Protocol (MCP) connects models to tools and context. Use it to give ChatGPT or Codex access to third-party documentation, or t…”

   proof ↗⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode supports MCP (local/remote servers) to add external tools, has an SDK/headless server for programmatic integrations, and GitHub Actions integration—these enable connecting third-party agent apps/tools into workflows. However, there's no evidence of a curated partner marketplace or vendor-vetted third-party 'agent apps' ecosystem beyond generic MCP/tool integration. missing for 10: a documented partner/marketplace ecosystem of pre-built third-party agent apps, case studies of integrating named partner agents, and independent verification of such integrations working smoothly.

   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”

   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 drawn
   Codex—none0/10

   Codex documents repo-level cloud environments, RBAC, and MCP connections to team tools, but no evidence describes a shared 'workspace' feature that unifies docs and repos into a common source of truth for a team; this is a plausible ask for an engineering tool but Codex's evidence only covers per-task cloud environments and repo configuration, not a persistent shared knowledge/workspace layer.

   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [claimed-docs] “Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashb…”
   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode offers session share links, repo-based 'agent skills', and enterprise SSO/config, but there is no evidence of a dedicated shared workspace feature that ingests both docs and repos into a common, persistent team source of truth — these are separate, ad-hoc mechanisms rather than a unified workspace.

   ⚑ flag

Tool integration

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

   weight 3 · round to Codex
   Codex~partialclaimed6/10

   Codex explicitly supports starting work from Slack (and GitHub/GitLab/Linear) and lets users add local or remote MCP servers to connect to third-party tools/docs (e.g. Figma, browser), giving a generic mechanism to extend context to workflow tools. However, there is no explicit documentation of native Jira or Google Drive connectors—only Slack is named among the story's specific tools, with Jira/Google Drive requiring the generic (and for one variant, deprecated/experimental) MCP server pathway. Missing for 10: named Jira integration, named Google Drive integration, and confirmation that the current (non-deprecated) MCP mechanism is broadly used for these specific SaaS tools.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Add local or remote MCP servers, authenticate when needed, and inspect the tools available to the current session before Codex uses them.”
   • [claimed-docs] “Package repeatable instructions as skills, then add plugins to connect Codex to your team's tools and data without leaving the CLI.”
   • [claimed-docs] “Use it to give ChatGPT or Codex access to third-party documentation, or to let it interact with developer tools like your browser or Figma.”
   • [claimed-docs] “Model Context Protocol (MCP) connects models to tools and context. Use it to give ChatGPT or Codex access to third-party documentation, or t…”
   • [claimed-docs] “Connect external tools with MCP — codex mcp: Add local or remote MCP servers, authenticate when needed, and inspect the tools available to t…”
   • [github] “Codex MCP Server Interface [experimental]: a JSON-RPC API that runs over the Model Context Protocol (MCP) transport to control a local Codex…”
   • [claimed-docs] “codex mcp-server is deprecated. Use the Codex app server instead. ... This page documents the deprecated command for existing integrations. …”

   proof ↗⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode supports MCP for adding external tools (local and remote servers), which is the generic mechanism by which one could connect Jira/Slack/Google Drive-type integrations, but there is no direct first-party or community evidence of specific Jira, Slack, or Google Drive connectors or integrations. missing for 10: named first-party or community-verified MCP servers/integrations for Jira, Slack, or Google Drive specifically, and any evidence of workflow-tool context extension beyond generic MCP support.

   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
   • [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex✓fullclaimed8/10

   First-party docs explicitly state Codex cloud tasks can be started from GitHub pull requests, GitLab merge requests/issues, Linear issues, or Slack channels/threads, matching the story directly. Missing for 10: independent/hands-on verification of these specific integrations working in practice (community evidence covers CLI/app UX but not the GitHub/GitLab/Linear/Slack kickoff flows specifically).

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”

   proof ↗⚑ flag

   OpenCode~partialclaimed4/10

   OpenCode has documented GitHub integration where mentioning /opencode or /oc in a comment triggers tasks in GitHub Actions, including issue-to-PR workflows, but there is no evidence of native GitLab, Linear, or Slack integrations for kicking off agent tasks. missing for 10: GitLab integration, Linear integration, Slack integration, independent hands-on confirmation of the GitHub Actions flow working reliably.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”

   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 Codex
   Codex✓fullclaimed8/10

   Codex supports starting tasks in the cloud from web/GitHub/GitLab/Linear/Slack, working in parallel cloud environments, and later resuming or continuing work from the CLI via 'codex cloud' (browse active/completed chats, submit/apply results) or 'codex resume' to reopen local chats, plus a shared MCP config across ChatGPT desktop, CLI, and IDE extension enabling cross-client continuity. missing for 10: independent hands-on confirmation of seamless state sync across devices/browsers, and no explicit mention of resuming a cloud-started task from a different physical device's browser session.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Start and review work from the web or Codex CLI.”
   • [claimed-docs] “Move work to Codex cloud — codex cloud: Browse active and completed chats, submit work to a configured environment, and apply the result to …”
   • [claimed-docs] “`codex resume`: Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”
   • [claimed-docs] “The ChatGPT desktop app, Codex CLI, and IDE extension share this configuration. Once you configure your MCP servers, you can switch among th…”

   proof ↗⚑ flag

   OpenCode~partialcommunity6/10

   OpenCode supports remote/headless usage via `opencode serve` plus a TUI that can connect to a remote backend, share links for sessions, and a WebUI that can connect to multiple backends from anywhere (including mobile), which enables cross-device continuation of a session. However, this requires manual server setup rather than seamless native cloud sync, and community reports note bugs restoring session state and provider/model selection issues across sessions. missing for 10: first-party seamless cross-device sync without self-hosting a server, official mobile app, and clear documentation/evidence of resuming full task state (not just session sharing) across devices.

   • [claimed-docs] “This allows using the TUI with a remote OpenCode backend.”
   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”

   proof ↗⚑ flag

Ide integration

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

   weight 1 · round drawn
   Codex—none0/10

   Evidence shows Codex's IDE extension explicitly targets VS Code, Cursor, and Windsurf (codex-gh-2), with no mention of JetBrains IDEs, interactive diff viewing within an IDE, or a 'share selected code as context' feature. The axis (IDE integration) is clearly applicable to Codex as a coding agent, but JetBrains-specific support and the described interactive-diff/context-sharing workflow are simply absent from the evidence pack.

   • [github] “If you want Codex in your code editor (VS Code, Cursor, Windsurf), install in your IDE.”

   proof ↗⚑ flag

   OpenCode—none0/10

   Evidence only shows OpenCode integrating with VS Code, Cursor, or 'any IDE that supports a terminal' via keyboard shortcuts for split-terminal view and inserting file references; there is no mention of a JetBrains-specific plugin, interactive diff viewer, or JetBrains context-sharing UI. missing for 10: JetBrains plugin/extension documentation, interactive diff rendering inside JetBrains, JetBrains-specific 'share selected code' mechanism.

   • [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
   • [claimed-docs] “Use Cmd+Esc (Mac) or Ctrl+Esc (Windows/Linux) to open OpenCode in a split terminal view”
   • [claimed-docs] “Use Cmd+Option+K (Mac) or Alt+Ctrl+K (Linux/Windows) to insert file references.”
   • [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal.”
   • [claimed-docs] “Use `Cmd+Esc` (Mac) or `Ctrl+Esc` (Windows/Linux) to open OpenCode in a split terminal view”
   • [claimed-docs] “Use `Cmd+Option+K` (Mac) or `Alt+Ctrl+K` (Linux/Windows) to insert file references.”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Codex✓fullcommunity8/10

   Codex explicitly offers an IDE extension for VS Code, Cursor, and Windsurf, plus a CLI usable within the terminal in your repo, both providing contextual chat/help with the codebase (edit files, run commands, review diffs). Community evidence confirms real-world usage of Codex CLI/app for editing and testing files in context, though some note UX friction compared to competitors. Missing for 10: deeper first-party documentation/screenshots of the IDE extension's chat UI specifically, and stronger independent hands-on corroboration of in-IDE chat quality.

   • [github] “If you want Codex in your code editor (VS Code, Cursor, Windsurf), install in your IDE.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [community] “Codex is my favorite UX for anything as it edits the files and I can use the proper tooling to adjust and test stuff... However lately the l…”

   proof ↗⚑ flag

   OpenCode✓fullcommunity8/10

   OpenCode ships an IDE extension and integrates directly in VS Code/Cursor with in-editor shortcuts (split terminal view, file-reference insertion) for contextual chat, and community users confirm using it as their daily coding harness with LSP integration inside editors. Missing for 10: independent hands-on review specifically of the IDE-extension chat UX (most community feedback is TUI/CLI-focused) and no screenshots/deep detail on in-IDE chat UI beyond shortcuts.

   • [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
   • [claimed-docs] “Any editor Available as a terminal interface, desktop app, and IDE extension”
   • [claimed-docs] “Use Cmd+Esc (Mac) or Ctrl+Esc (Windows/Linux) to open OpenCode in a split terminal view”
   • [claimed-docs] “Use Cmd+Option+K (Mac) or Alt+Ctrl+K (Linux/Windows) to insert file references.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”

   proof ↗⚑ flag

Session management

1. developerReview diffs visually and run multiple sessions side by side in a desktop app

   weight 2 · round drawn
   Codex~partialcommunity5/10

   Codex ships a desktop app ("codex app"/Codex App page) and documents parallel task execution plus diff/summary inspection before merging, suggesting the underlying pieces exist, but the evidence never shows the desktop app UI actually presenting a visual diff viewer or multiple sessions arranged side by side. Community notes even flag basic desktop-app reliability issues (stuck on 'Loading projects...', Mac-only availability). Missing for 10: concrete documentation/screenshots of the desktop app's diff viewer, explicit multi-session/side-by-side UI description, and independent confirmation it works smoothly.

   • [github] “If you want the desktop app experience, run <code>codex app</code> or visit the Codex App page.”
   • [github] “If you want the desktop app experience, run <code>codex app</code> or visit <a href="https://chatgpt.com/codex?app-landing-page=true">the Co…”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [community] “Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good…”
   • [community] “Mac only. Again. Apple is great but this is OpenAI devs showing their disconnect from the mainstream.”

   proof ↗⚑ flag

   OpenCode~partialclaimed5/10

   OpenCode has a documented desktop app with tabs (opencode-docs-19) and multi-session support to run multiple agents in parallel (opencode-docs-17/38), plus session share links; existence of the desktop app is also confirmed on GitHub (opencode-gh-1). However, there is no evidence describing a visual diff-review UI in the desktop app specifically — docs focus on TUI/terminal split views and file references rather than a diff viewer. Missing for 10: explicit documentation or screenshots of a visual diff/code-review interface in the desktop app, and independent/hands-on confirmation of side-by-side session usage in that app.

   • [claimed-docs] “Introducing tabs for desktop. Available on macOS, Windows, and Linux.”
   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [github] “OpenCode is also available as a desktop application.”
   • [claimed-docs] “Any editor Available as a terminal interface, desktop app, and IDE extension”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex✓fullcommunity7/10

   Codex documents cloud parallel task execution across multiple repos/environments (codex-docs-1,3,6), a web/CLI dashboard to browse active and completed chats and apply results locally (codex-docs-15), and resuming/searching across sessions (codex-docs-11,24), which together support managing multiple concurrent agent sessions from a unified interface. However, evidence is vendor-documentation only with no independent hands-on confirmation of a true 'unified workspace' UX for an engineering-lead managing many sessions simultaneously, and some community comments note UX rough edges (codex-comm-9,18). Missing for 10: independent/hands-on verification of multi-session management at scale, and clearer detail on cross-session visibility/coordination for a lead overseeing a team's agents.

   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Run tasks in parallel without tying up your local machine.”
   • [claimed-docs] “Delegate a longer task and return when it is ready.”
   • [claimed-docs] “Browse active and completed chats, submit work to a configured environment, and apply the result to your local repository from the terminal.”
   • [claimed-docs] “Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”
   • [claimed-docs] “`codex resume`: Reopen a recent chat from the current repository, or search across local chats when you need to return to older work.”
   • [community] “I wish Codex App was open source. I like it, but there are always a bunch of little paper cuts that, if you were using codex cli, you could …”

   proof ↗⚑ flag

   OpenCode✓fullcommunity8/10

   OpenCode explicitly supports multi-session workflows ('Start multiple agents in parallel on the same project'), tabs for desktop, share links for sessions, and a headless server that a WebUI can connect to across multiple backends, which community evidence corroborates ('WebUI... can connect to multiple OpenCode backends at once'). This directly matches an engineering-lead managing multiple agent sessions from one unified workspace. Missing for 10: no first-party documentation of team/organization-level oversight (e.g., viewing/managing sessions started by other engineers) and some reported bugs in session state restoration temper reliability.

   • [claimed-docs] “**Multi-session** Start multiple agents in parallel on the same project”
   • [claimed-docs] “Introducing tabs for desktop. Available on macOS, Windows, and Linux.”
   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “Multi-session Start multiple agents in parallel on the same project”
   • [claimed-docs] “Share links Share a link to any session for reference or to debug”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”

   proof ↗⚑ flag

Terminal workflow

1. developerRun a coding agent locally from my terminal

   weight 3 · round drawn
   Codex✓fullcommunity9/10

   Codex CLI is explicitly documented as a coding agent that runs locally in the terminal, with npm/standalone install, working against the local repository, editing files, running commands, and offering interactive TUI plus non-interactive exec mode — well corroborated by first-party docs and GitHub README, with community usage discussion confirming real-world use. Missing for 10: independent hands-on verification specifically of pure local terminal usage (most community commentary discusses model quality/UX rather than the local-run mechanics) and some caveats about performance/limits reported by users.

   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”
   • [github] “npm install -g @openai/codex”
   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”
   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”
   • [claimed-docs] “Install the Codex CLI with the standalone installer for macOS and Linux.”
   • [community] “Codex is my favorite UX for anything as it edits the files and I can use the proper tooling to adjust and test stuff... However lately the l…”
   • [community] “Genuinely excited to try this out. I've started using Codex much more heavily in the past two months and honestly, it's been shockingly good…”

   proof ↗⚑ flag

   OpenCode✓fullprobed9/10

   OpenCode is explicitly a terminal-based coding agent, installable via curl/npm, run with `opencode` command in any terminal, with rich CLI docs and confirmed hands-on community usage as a daily local terminal harness. Missing for 10: no independent benchmark/security audit fully vetting the terminal experience beyond anecdotal reports (some report TUI compatibility bugs on specific setups).

   • [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
   • [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal. Just run `opencode` in the terminal to get started.”
   • [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “OpenCode integrates with VS Code, Cursor, or any IDE that supports a terminal.”
   • [probe] “official CLI documented at https://opencode.ai/docs/cli/”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Codex✓fullclaimed8/10

   Docs explicitly describe running 'a non-interactive command in a repeatable workflow' and automating repeatable work without leaving the terminal, plus support for submitting work to configured environments from scripts (codex exec-style usage implied). Missing for 10: independent hands-on confirmation of non-interactive/CI usage and detailed exit-code/output-format documentation for scripting.

   • [claimed-docs] “Run a non-interactive command in a repeatable workflow.”
   • [claimed-docs] “Inspect code, make changes, run commands, and automate repeatable work without leaving your terminal.”
   • [claimed-docs] “Browse active and completed chats, submit work to a configured environment, and apply the result to your local repository from the terminal.”
   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”

   proof ↗⚑ flag

   OpenCode✓fullclaimed8/10

   The `opencode run` CLI command explicitly supports non-interactive one-shot execution (e.g. `opencode run "Explain how closures work"`), and `--auto` flag auto-approves permissions for unattended runs, plus `opencode serve` exposes a headless HTTP/OpenAPI server and JS/TS SDK for scripted/programmatic control, all fitting workflow automation. Missing for 10: independent hands-on evidence of non-interactive scripting reliability/CI use, and no dedicated exit-code/output-format docs for pipeline integration.

   • [claimed-docs] “opencode run "Explain how closures work in JavaScript"”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex~partialcommunity3/10

   Codex ships rich CLI/UI-only capabilities (cloud tasks, resume/review, skills, plugins, MCP client integration) with no evidence these are exposed via a dedicated Codex API, and the general OpenAI API (RBAC, Responses API) is not shown to cover Codex-specific workflows; community evidence even confirms the latest gpt-5.3-codex model 'isn't available on the API yet,' a documented parity gap. Missing for 10: documented API endpoints for cloud task delegation, chat/session resume, MCP tool orchestration, and confirmation that current models/features are API-accessible at parity with CLI/UI.

   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [community] “gpt-5.3-codex isn't available on the API yet — 'We are working to safely enable API access soon.'”
   • [claimed-docs] “Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashb…”
   • [claimed-docs] “Create a model response — request/response reference with runnable code samples selectable per language: HTTP, Python, TypeScript, Go, Ruby,…”
   • [claimed-docs] “codex mcp-server is deprecated. Use the Codex app server instead. ... This page documents the deprecated command for existing integrations. …”

   proof ↗⚑ flag

   OpenCode~partialprobed6/10

   OpenCode ships a headless server (`opencode serve`) exposing a documented OpenAPI spec (confirmed live at openapi.json) plus a JS/TS SDK explicitly for 'building integrations and controlling opencode programmatically,' and the TUI/WebUI can drive a remote backend — community confirms this works day-to-day including from mobile. However, no evidence explicitly enumerates full feature parity (e.g., agent skill management, permission config, enterprise SSO settings) as exposed via the API/SDK, and there's no independent audit confirming 1:1 UI/API parity. missing for 10: explicit parity documentation covering all UI-only features (skills, permission prompts, enterprise SSO), independent verification of full API coverage.

   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [claimed-docs] “Use it to build integrations and control opencode programmatically.”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
   • [claimed-docs] “This allows using the TUI with a remote OpenCode backend.”
   • [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Codex—none0/10

   No evidence of any data export feature or open-format export mechanism for chat history, project data, or configurations; Codex works with local files/git repos but there's no documented export/portability capability for user data (e.g., conversation history, settings) to leave the platform. Missing for 10: any documented data export tool, open-format export (JSON/Markdown dump), or data portability statement.

   ⚑ flag

   OpenCode—none0/10

   No evidence describes an explicit data-export feature or open-format portability guarantee for OpenCode; while it is open-source and stores config/sessions locally, there's no documented 'export all my data and leave' capability, and community threads even note telemetry sent to OpenCode's own servers with no way to disable it (opencode-comm-2), undercutting a clean data-portability story.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
   • [claimed-docs] “**Share links** Share a link to any session for reference or to debug”
   • [claimed-docs] “Share links Share a link to any session for reference or to debug”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex~partialcommunity4/10

   The Codex CLI source lives in a public GitHub repo (openai/codex) and a community comment implies its openness lets users 'diagnose and file an issue' the way they can't with the closed-source Codex App, suggesting at least the CLI's code is publicly viewable. However, no evidence pack item states an explicit open-source license, and the App/cloud components are explicitly described as closed. missing for 10: explicit license file/name (MIT, Apache, etc.), confirmation the full product (not just CLI) is open, and independent corroboration beyond one forum remark.

   • [github] “Codex CLI is a coding agent from OpenAI that runs locally on your computer.”
   • [community] “I wish Codex App was open source. I like it, but there are always a bunch of little paper cuts that, if you were using codex cli, you could …”

   proof ↗⚑ flag

   OpenCode✓fullcommunity7/10

   OpenCode's docs explicitly describe it as "open source" and a public GitHub repo exists (opencode-gh-1), and community members confirm they read and learned from the actual source code (opencode-comm-6), corroborating that the source is genuinely accessible. missing for 10: explicit citation of the license name/type (e.g., MIT/Apache) in the evidence pack, and a first-party statement pointing to the license file itself.

   • [claimed-docs] “OpenCode is an open source AI coding agent. It's available as a terminal-based interface, desktop app, or IDE extension.”
   • [github] “OpenCode is also available as a desktop application.”
   • [community] “OpenCode source code is even more awesome. I have learned so much from the way they have organized tools, agents, settings and prompts. mode…”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to OpenCode
   Codex—none0/10

   Codex CLI runs locally but requires signing into a ChatGPT account or OpenAI API key, and the core inference/model and cloud environments are OpenAI-hosted only; there is no self-hosted backend option. A commenter explicitly wishes the Codex App were open source, implying it is not, which forecloses self-hosting the core product.

   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [community] “I wish Codex App was open source. I like it, but there are always a bunch of little paper cuts that, if you were using codex cli, you could …”

   proof ↗⚑ flag

   OpenCode✓fullprobed8/10

   OpenCode is open source and installable via CLI, with a documented `opencode serve` headless HTTP server exposing an OpenAPI endpoint, plus SDK and remote/TUI client support, enabling full self-hosting of the core agent; community evidence confirms real-world self-hosted use ('opencode serve' accessible remotely) though also flags security hardening gaps around the server. missing for 10: independent audit confirming production-grade self-hosted security, and clearer official self-hosting/deployment guide beyond the serve command docs.

   • [claimed-docs] “curl -fsSL https://opencode.ai/install | bash”
   • [claimed-docs] “The opencode serve command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “The `opencode serve` command runs a headless HTTP server that exposes an OpenAPI endpoint that an opencode client can use.”
   • [claimed-docs] “Attach a terminal to an already running OpenCode backend server started via `serve` or `web` commands.”
   • [claimed-docs] “The opencode JS/TS SDK provides a type-safe client for interacting with the server. Use it to build integrations and control opencode progra…”
   • [probe] “PROBE openapi: HTTP 200 at https://opencode.ai/openapi.json — contains "openapi" key”
   • [community] “You can start a service via 'opencode serve', it can be accessed from anywhere and has great experience on mobile except a few bugs... The W…”
   • [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”

   proof ↗⚑ flag

Authentication

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

   weight 2 · round to OpenCode
   Codex~partialcommunity5/10

   GitHub docs confirm Codex CLI supports API key authentication as an alternative to ChatGPT account login, but note it 'requires additional setup,' and the account-login flow (Sign in with ChatGPT) is the recommended default. Missing for 10: detailed API-key setup documentation, first-party quickstart parity with account login, and independent confirmation that API-key auth is fully feature-equivalent (e.g. codex-comm-5 shows some newer models aren't even available via API yet).

   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [community] “gpt-5.3-codex isn't available on the API yet — 'We are working to safely enable API access soon.'”

   proof ↗⚑ flag

   OpenCode✓fullclaimed8/10

   OpenCode explicitly supports configuring API keys for any LLM provider as an alternative to logging in via account-based options like GitHub Copilot or ChatGPT Plus/Pro, giving developers a direct API-key auth path rather than requiring account login. Missing for 10: independent hands-on confirmation of the API key setup flow itself and details on key storage/security beyond docs claims.

   • [claimed-docs] “With OpenCode you can use any LLM provider by configuring their API keys.”
   • [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
   • [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [claimed-docs] “OpenCode Zen is a list of tested and verified models provided by the OpenCode team.”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex~partialclaimed5/10

   Codex supports signing in with a ChatGPT Business/Enterprise/Edu account (codex-gh-3, codex-gh-7) and OpenAI's platform offers RBAC to scope access at org/project level (codex-docs-28), suggesting enterprise-grade authentication and access control exist. However, there is no explicit documentation of SSO/SAML/OIDC federation with enterprise identity providers (e.g., Okta, Azure AD) specific to Codex, nor details on how ChatGPT Enterprise auth ties into RBAC for Codex usage. Missing for 10: explicit SSO/SAML/OIDC integration docs, enterprise IdP federation details, and independent confirmation of compliance-grade auth flows for Codex specifically.

   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “Run `codex` and select **Sign in with ChatGPT**. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Busi…”
   • [claimed-docs] “Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashb…”

   proof ↗⚑ flag

   OpenCode~partialclaimed6/10

   OpenCode has a documented enterprise config that integrates with SSO and enforces a centralized internal AI gateway, directly addressing enterprise identity/compliance needs, and supports login via GitHub Copilot/OpenAI accounts. However, there's no independent corroboration of this enterprise SSO feature in practice, no detail on supported identity providers (SAML/OIDC specifics), and community discussion focuses on telemetry/security concerns rather than confirming enterprise auth workflows. Missing for 10: independent/hands-on validation of SSO integration, details on supported IdPs, and evidence of enterprise customers actually using this for compliance/scalability.

   • [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
   • [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
   • [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex✓fullclaimed9/10

   GitHub docs explicitly recommend signing in with ChatGPT to use Codex under existing Plus, Pro, Business, Edu, or Enterprise subscription plans, with API key as an alternative for those without such plans, directly confirming subscription-based sign-in. missing for 10: independent hands-on confirmation of the sign-in flow itself (evidence focuses on capability descriptions rather than a walkthrough).

   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “Run `codex` and select **Sign in with ChatGPT**. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Busi…”
   • [github] “Run codex and select Sign in with ChatGPT. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, …”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity8/10

   OpenCode docs explicitly support signing in with existing subscriptions—GitHub Copilot and ChatGPT Plus/Pro—rather than requiring separate API keys, and community comments confirm using subscriptions (e.g., Codex $200/mo) inside OpenCode. Missing for 10: independent hands-on verification of the Copilot/ChatGPT login flow itself and broader coverage of other subscription providers beyond these two.

   • [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
   • [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [claimed-docs] “GitHub Copilot Log in with GitHub to use your Copilot account”
   • [claimed-docs] “ChatGPT Plus/Pro Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [community] “OpenCode is awesome. Claude Code is nothing special at all. Last month I switched to just using OpenCode with a Codex $200/mo subscription, …”

   proof ↗⚑ flag

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

   weight 1 · round to Codex
   Codex✓fullclaimed8/10

   Codex CLI explicitly recommends signing in with a ChatGPT account (Plus/Pro/Business/Edu/Enterprise) to use Codex without an API key, with API key usage noted as an alternative requiring additional setup. This directly matches the story of personal-account sign-in without managing API keys, though the exact free-tier scope/limits aren't detailed. Missing for 10: explicit confirmation of a genuinely free tier (vs. paid ChatGPT plans) and independent corroboration of the login flow's simplicity.

   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”
   • [github] “Run `codex` and select **Sign in with ChatGPT**. We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Busi…”

   proof ↗⚑ flag

   OpenCode✓fullcommunity7/10

   OpenCode's docs explicitly offer 'Log in with GitHub to use your Copilot account' and 'Log in with OpenAI to use your ChatGPT Plus or Pro account,' letting a developer authenticate with an existing personal subscription instead of managing provider API keys, and OpenCode Zen is noted to include a free coding model. Missing for 10: independent/hands-on user reports specifically confirming this login flow (community comments focus on API keys/local models, not the Copilot/ChatGPT login path), and clarity on any usage limits tied to the free tier.

   • [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
   • [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [claimed-docs] “GitHub Copilot Log in with GitHub to use your Copilot account”
   • [claimed-docs] “ChatGPT Plus/Pro Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [community] “OpenCode source code is even more awesome. I have learned so much from the way they have organized tools, agents, settings and prompts. mode…”

   proof ↗⚑ flag

Model choice

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

   weight 1 · round drawn
   Codex—none0/10

   Evidence shows Codex lets users manually choose the model and reasoning effort ('Stay in control: Choose the model, reasoning effort, permissions...') rather than any automatic best-model-per-task selection; no docs or community evidence describe an automatic model-routing/selection feature tied to cost or task type.

   • [claimed-docs] “Stay in control: Choose the model, reasoning effort, permissions, and commands that fit the task.”
   • [community] “The main issue I have with Codex is that the best model is insanely slow, except at nights and weekends when Silicon Valley goes to bed... I…”
   • [community] “First thoughts using gpt-5.3-codex-spark in Codex CLI: Blazing fast but it definitely has a small model feel... It has to be prompted to do …”

   proof ↗⚑ flag

   OpenCode—none0/10

   Evidence shows OpenCode supports many providers/models and lets users manually assign a model per agent or switch via Tab, but nothing indicates the tool automatically selects the optimal model for a given task — community feedback even confirms model/provider choice is manual and sometimes annoying to manage across sessions.

   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”
   • [claimed-docs] “You can use the Tab key to switch between primary agents during a session.”
   • [claimed-docs] “75+ LLM providers through Models.dev, including local models”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex—none0/10

   Docs confirm Codex lets users 'Choose the model, reasoning effort, permissions' (codex-docs-31), but this refers to selecting among OpenAI's own Codex/GPT models, not switching between different AI providers (e.g., Anthropic, Google). No evidence shows Codex supports plugging in or selecting non-OpenAI models/providers within a session.

   • [claimed-docs] “Stay in control: Choose the model, reasoning effort, permissions, and commands that fit the task.”
   • [github] “We recommend signing into your ChatGPT account to use Codex as part of your Plus, Pro, Business, Edu, or Enterprise plan.”
   • [github] “You can also use Codex with an API key, but this requires additional setup.”

   proof ↗⚑ flag

   OpenCode✓fullcommunity9/10

   OpenCode explicitly supports configuring any LLM provider via API keys, lists 75+ providers through Models.dev including local models, offers a curated OpenCode Zen model list, and supports logging in with GitHub Copilot or ChatGPT Plus/Pro accounts. Community evidence corroborates real-world use with multiple providers (Claude, Gemini, local llama.cpp, Qwen) and per-agent model selection. Missing for 10: some community reports note model/provider switching across sessions can be buggy or annoying, a minor UX caveat.

   • [claimed-docs] “With OpenCode you can use any LLM provider by configuring their API keys.”
   • [claimed-docs] “OpenCode Zen is a list of tested and verified models provided by the OpenCode team.”
   • [claimed-docs] “75+ LLM providers through Models.dev, including local models”
   • [claimed-docs] “Any model 75+ LLM providers through Models.dev, including local models”
   • [claimed-docs] “**GitHub Copilot** Log in with GitHub to use your Copilot account”
   • [claimed-docs] “**ChatGPT Plus/Pro** Log in with OpenAI to use your ChatGPT Plus or Pro account”
   • [community] “I really like how their subagents work, as a bonus I get to choose which model is in which agent.”
   • [community] “i've been using this as my primary harness for llama.cpp models, Claude, and Gemini for a few months now. the LSP integration is great.”
   • [community] “This replaced Aider for me a couple months back. I use it with Qwen 3.5 running locally when my daily limits run out on my other subscriptio…”
   • [community] “There are random bugs with loading/restoring state of the session; Model/Provider selection switch across sessions/projects is often annoyin…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Codex—none0/10

   No evidence in the pack mentions data residency, regional storage options, or geographic controls for where Codex data is stored; the pack covers RBAC, MCP, CLI features, and cloud task execution but nothing about choosing a storage region.

   ⚑ flag

   OpenCode—none0/10

   No evidence anywhere in the pack of a region/residency selection feature for data storage; OpenCode's docs focus on provider choice, self-hosting, and enterprise SSO, none of which address data residency. In fact, community reports indicate telemetry is always sent to OpenCode's own servers with no way to disable it, further suggesting the user lacks control over where certain data goes.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Codex—none0/10

   The evidence pack contains no mention of data-training opt-out controls, enterprise data usage policies, or privacy settings for excluding user data from model training; it covers CLI features, MCP, RBAC, and community sentiment but nothing about training-data exclusion.

   ⚑ flag

   OpenCode—none0/10

   The evidence pack contains no documentation of any setting, policy, or opt-out mechanism for preventing user data/code from being used to train AI models (OpenCode's docs focus on providers, agents, permissions, IDE integration, etc., none addressing training-data usage). Community evidence actually suggests the opposite direction of concern: telemetry is sent to OpenCode's own servers even with locally-hosted models with no way to disable it, which further undermines confidence that user data is protected from being retained/used.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Codex—none0/10

   No evidence pack items address data retention controls, deletion policies, or configurable retention windows for Codex; RBAC docs address access control, not retention/deletion. Missing for 10: any documentation of data retention settings, deletion APIs/workflows, or retention policy configuration.

   ⚑ flag

   OpenCode—none0/10

   No documentation describes any data retention or deletion controls, and community evidence indicates the opposite: OpenCode sends telemetry to its own servers even with local models, with no environment variables or flags to disable it, suggesting no user-facing data controls exist.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”

   proof ↗⚑ flag

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

   weight 2 · round to OpenCode
   Codex—none0/10

   No evidence in the pack mentions telemetry, usage tracking, data collection settings, or an opt-out mechanism for Codex; the docs and community threads cover features like MCP, CLI usage, and performance but never privacy/telemetry controls.

   ⚑ flag

   OpenCode!disputedcontradicted2/10

   OpenCode's docs make no mention of a telemetry opt-out setting, and a community report explicitly states OpenCode sends telemetry to its own servers even with locally hosted models, with no environment variables, flags, or config options to disable it. This is a first-party-vs-hands-on-evidence conflict: no documented opt-out mechanism exists, and independent evidence claims none is available. missing for 10: any official docs describing a telemetry toggle/opt-out, first-party acknowledgment of telemetry collection, and any evidence the reported issue was fixed.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”

   proof ↗⚑ flag

Data governance

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

   weight 1 · round drawn
   Codex—none0/10

   No evidence in the pack addresses data usage or training opt-out policies for code/prompts; RBAC and MCP docs are unrelated to this axis. Missing for 10: any enterprise data-usage/training opt-out policy documentation, admin controls for opting out, or third-party confirmation of such a policy.

   ⚑ flag

   OpenCode—none0/10

   No documentation exists describing a training-data opt-out or data-use policy for prompts/code; in fact community evidence indicates OpenCode sends telemetry to its own servers with no way to disable it, even when using local models, suggesting the opposite of user control over data usage.

   • [community] “OpenCode is sending telemetry to their own servers, even when you're using your own locally hosted models. There are no environment variable…”

   proof ↗⚑ flag

Pr review

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

   weight 3 · round drawn
   Codex~partialclaimed6/10

   Codex docs explicitly describe inspecting diffs and opening a pull request when cloud work is ready (codex-docs-5), and CLI docs note reviewing changes 'before you commit or open a pull request' (codex-docs-45), implying git workflow integration. However, staging changes, writing commit messages, and creating branches are not explicitly documented as first-class agent actions — they are only implied via general local repo access and command execution (codex-docs-9, codex-docs-30, codex-docs-17). Missing for 10: explicit documentation of commit-message generation, branch creation, and staging as named agent capabilities, plus independent hands-on confirmation of full PR workflow automation.

   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Start Codex in a repository to explore unfamiliar code, plan a change, edit files, and run your local development tools.”
   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”

   proof ↗⚑ flag

   OpenCode~partialclaimed6/10

   Docs explicitly describe GitHub integration where OpenCode 'will work in a new branch and submits a PR with all the changes' and can execute tasks via mentions in GitHub Actions, covering branch creation and PR opening; permission config also governs whether actions like git operations auto-run or prompt. However, there's no explicit mention of staging changes or generating commit messages as a distinct capability, and no independent/community evidence corroborates the PR-creation workflow in practice. missing for 10: explicit documentation of commit message generation/staging step, independent hands-on verification of the branch+PR workflow.

   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”

   proof ↗⚑ flag

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

   weight 3 · round to Codex
   Codex~partialclaimed5/10

   Codex CLI/cloud ships a dedicated 'review' capability that inspects uncommitted changes, a commit, or a base branch and reports prioritized findings without touching the working tree, and cloud tasks can be kicked off from GitHub PRs and later opened as PRs. However, there is no evidence of an automatic, PR-triggered review bot that comments on every pull request without manual invocation. missing for 10: evidence of automatic triggering on every PR (e.g., GitHub App/webhook auto-review), evidence of inline PR comments, independent confirmation of review quality on real PRs.

   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Start work in Codex cloud from GitHub pull requests, GitLab merge requests and issues, Linear issues, or Slack channels and threads.”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”

   proof ↗⚑ flag

   OpenCode~partialclaimed4/10

   OpenCode has a GitHub Actions integration (mention /opencode or /oc in a comment) and a read-only 'plan' agent that can review/suggest changes without modifying code, which can be used for PR feedback, but this requires an explicit manual mention rather than automatically triggering contextual review on every PR. Missing for 10: documented automatic/triggerless review on every new PR, evidence of inline contextual comments on diffs, and independent confirmation of this review workflow in practice.

   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”
   • [claimed-docs] “OpenCode integrates with your GitHub workflow. Mention /opencode or /oc in your comment, and OpenCode will execute tasks within your GitHub …”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [claimed-docs] “This will walk you through installing the GitHub app, creating the workflow, and setting up secrets.”

   proof ↗⚑ flag

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

   weight 3 · round to Codex
   Codex✓fullclaimed8/10

   Codex CLI has a dedicated review command that inspects diffs against uncommitted changes, a commit, or a base branch, reporting prioritized findings without modifying the working tree, plus cloud/web flows to inspect summaries and diffs before opening a PR. Missing for 10: independent/hands-on corroboration of the review command's accuracy and any CI-integrated check-running beyond exec/scripts.

   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Inspect the summary and diff, request a follow-up, or open a pull request when the result is ready.”
   • [claimed-docs] “Compose with scripts and CI: Use Codex interactively or call codex exec from repeatable workflows and pipelines.”

   proof ↗⚑ flag

   OpenCode~partialclaimed4/10

   OpenCode offers a read-only 'plan' agent for reviewing suggested changes without applying them and a permission system that can prompt before actions run, plus GitHub PR/Actions integration for submitting changes — these provide some review-safety scaffolding. However there is no documented diff-viewing UI or built-in test/lint/check-running capability before merge. Missing for 10: explicit diff inspection tooling, integrated test/lint/CI check execution, and independent evidence that these safety mechanisms actually prevent bad merges.

   • [claimed-docs] “Use the plan agent to analyze code and review suggestions without making any code changes.”
   • [claimed-docs] “This agent is useful when you want the LLM to analyze code, suggest changes, or create plans without making any actual modifications to your…”
   • [claimed-docs] “A fast, read-only agent for exploring codebases. Cannot modify files.”
   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Ask OpenCode to fix an issue or implement a feature. And it will work in a new branch and submits a PR with all the changes.”
   • [claimed-docs] “Mention `/opencode` or `/oc` in your comment, and OpenCode will execute tasks within your GitHub Actions runner.”

   proof ↗⚑ flag

Safe execution

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

   weight 2 · round to OpenCode
   Codex~partialclaimed6/10

   Codex documents fine-grained control over external tool access at the session/repo level: engineers can add/remove local or remote MCP servers, inspect available tools before they're used, and set permission boundaries for edits/commands via /permissions (codex-docs-16, codex-docs-38, codex-docs-39, codex-docs-46). This gives an engineer meaningful control over which integrations the agent can reach, and RBAC exists for org/project-level API access (codex-docs-28), but that RBAC is about API/dashboard permissions, not specifically about restricting agent tool/integration access org-wide for a lead managing a team's Codex usage. Missing for 10: evidence of centralized, lead-enforced policy that restricts which MCP servers/tools individual developers can enable (vs. per-session self-configuration), and independent confirmation this control actually prevents unauthorized tool access in practice.

   • [claimed-docs] “Add local or remote MCP servers, authenticate when needed, and inspect the tools available to the current session before Codex uses them.”
   • [claimed-docs] “Connect external tools with MCP — codex mcp: Add local or remote MCP servers, authenticate when needed, and inspect the tools available to t…”
   • [claimed-docs] “Set the boundaries for each run — /permissions: Choose when Codex can edit files or run commands without asking, and inspect the active sand…”
   • [claimed-docs] “In the `codex` TUI, use `/mcp` to see your active MCP servers.”
   • [claimed-docs] “Role-based access control (RBAC) lets you decide who can do what across your organization and projects—both through the API and in the Dashb…”

   proof ↗⚑ flag

   OpenCode✓fullclaimed8/10

   OpenCode's permission system lets leads set actions to auto-run, prompt, or block per tool/input, and MCP servers (external tools) are explicitly added/configured (docs-4/23/41). Enterprise config also lets orgs force use of an internal AI gateway and SSO, further restricting what integrations agents can reach (docs-33/50). Missing for 10: independent/hands-on confirmation that permission rules reliably block disallowed MCP tool calls in practice, and finer detail on allow/deny lists for specific external tool names beyond the general permission object.

   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “OpenCode uses the permission config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with --auto to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “For most permissions, you can use an object to apply different actions based on the tool input.”
   • [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP. OpenCode supports both local and remote servers.”
   • [claimed-docs] “You can add external tools to OpenCode using the Model Context Protocol, or MCP.”
   • [claimed-docs] “You can add external tools to OpenCode using the _Model Context Protocol_, or MCP.”
   • [claimed-docs] “This centralized config can integrate with your SSO provider and ensures all users access only your internal AI gateway.”
   • [claimed-docs] “Through the central config, OpenCode can integrate with your organization’s SSO provider for authentication.”

   proof ↗⚑ flag

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

   weight 2 · round to Codex
   Codex✓fullcommunity7/10

   First-party docs explicitly describe sandboxed execution: Codex lets you 'choose when Codex can edit files or run commands without asking, and inspect the active sandbox and writable roots' (codex-docs-17), and cloud tasks run in 'isolated cloud environments' with configurable dependencies/tools (codex-docs-1, codex-docs-4). This directly matches the engineering-lead's need for sandboxed code/tool interaction, though network-resource sandboxing specifics are not spelled out and there's no independent hands-on verification of sandbox robustness (a community comment raises but does not concretely confirm a sandbox-bypass issue). Missing for 10: explicit documentation of network-level sandbox controls, and independent/hands-on confirmation that the sandbox reliably contains tool/network access.

   • [claimed-docs] “Choose when Codex can edit files or run commands without asking, and inspect the active sandbox and writable roots before you continue.”
   • [claimed-docs] “Run tasks in isolated cloud environments, work in parallel, and start work from the web, GitHub, GitLab, Linear, or Slack.”
   • [claimed-docs] “Configure the dependencies, tools, variables, and setup steps each repository needs.”
   • [community] “Do people really want codex to have control over their computer and apps? I'm still paranoid about keeping things securely sandboxed.”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode's documentation only describes a permission system (auto-approve/prompt/block) and an 'external_directory' toggle for path access — not an isolated sandbox for code execution, tool calls, or network access. Community evidence (opencode-comm-18) even flags that the local server mode allows any local process or webpage to execute code without authentication, the opposite of sandboxed isolation, and there is no first-party claim of container/VM-based sandboxing to dispute.

   • [claimed-docs] “OpenCode uses the `permission` config to decide whether a given action should run automatically, prompt you, or be blocked.”
   • [claimed-docs] “Start OpenCode with `--auto` to automatically approve permission requests that are not explicitly denied.”
   • [claimed-docs] “Use external_directory to allow tool calls that touch paths outside the working directory where OpenCode was started.”
   • [community] “When server is enabled, any web page served from localhost/127.0.0.1 can execute code; any local process can execute code without authentica…”

   proof ↗⚑ flag

Security checks

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

   weight 1 · round drawn
   Codex—none0/10

   No evidence anywhere in the pack mentions license detection, public-code matching, or provenance references for AI-suggested code; Codex's review features (codex-docs-10, -41, -45) only cover code quality/prioritized findings, not license/public-code attribution.

   ⚑ flag

   OpenCode—none0/10

   No evidence of any license or public-code matching/attribution feature for AI-suggested code in OpenCode's docs or community reports; the product focuses on agent workflows, permissions, and MCP integration but nothing about code provenance or license scanning.

   ⚑ flag

2. developerGet contextual explanations and automatic fixes for security vulnerabilities

   weight 2 · round to Codex
   Codex~partialclaimed3/10

   Codex CLI has a dedicated review command that inspects uncommitted changes, commits, or branches and reports 'prioritized findings' (codex-docs-10, codex-docs-41, codex-docs-45), which could surface security issues, and as a general coding agent it can edit files/run commands. However, the review feature explicitly reports findings 'without modifying your working tree,' meaning it does not auto-fix, and no evidence specifically frames this as security-vulnerability detection/explanation with automatic remediation. missing for 10: explicit security-vulnerability scanning/explanation feature, evidence of automatic fix application (vs. just flagging), and any independent confirmation that Codex reliably identifies/fixes security issues.

   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Review changes before they ship: Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized f…”
   • [claimed-docs] “Run a dedicated review against uncommitted changes, a commit, or a base branch. Codex reports prioritized findings without modifying your wo…”
   • [claimed-docs] “Work against your local repository: Let Codex inspect files, make edits, and run the tools already installed on your machine.”

   proof ↗⚑ flag

   OpenCode—none0/10

   OpenCode is a general coding agent with plan/explore/build agents and permission controls, but no evidence describes any security-vulnerability scanning, contextual vulnerability explanations, or automatic security fix generation as a feature. Community evidence even highlights unresolved security reports and vulnerabilities in OpenCode itself, not a capability to detect/fix vulnerabilities in user code.

   ⚑ flag