GeezerVison

OpenCode and Claude Code attack the same job from opposite ends. OpenCode is an MIT-licensed terminal agent that talks to whatever model you connect, and Claude Code is Anthropic’s closed agent built around Claude. Cursor and Codex CLI now crowd the same opencode vs claude code decision, and the pick comes down to billing, sandboxing and whether you live in a terminal or an editor.

Original content from computingforgeeks.com - post 165424

We compare all four on install, pricing, MCP config, sandbox modes, local models and subagents. In October 2026 we installed OpenCode 2.2.5, Claude Code 2.1.316, Codex CLI 0.166.0 and the Cursor CLI on an Ubuntu 26.04 VM and ran the MCP, sandbox and local-model steps there against a small Ollama model. We checked every version and price against the vendors’ pages again on 5 November 2026. The one change sits with Cursor, whose Plus tier page now documents Grok models only. Sign-in flows and paid-model sessions were not run, and each one is marked where it appears. There are no benchmark numbers here; our execution test of six coding CLIs has those.

Choose the Agent That Fits How You Work

Start from where you write code and who pays for the tokens, because those two facts rule out half the field before features matter. The short version, one line per tool:

• OpenCode: any model, any provider, open source, terminal first
• Claude Code: Claude subscription, deepest hooks and subagents
• Codex CLI: ChatGPT plan, strictest default sandbox, Apache-2.0
• Cursor: full IDE with inline diffs, plus an agent CLI

If you already pay for ChatGPT Plus, Codex costs you nothing extra, and if you already pay for Claude Pro, Claude Code does not either. OpenCode is the one to run when you want to switch models without switching tools, or when the model has to run on your own hardware. Cursor wins only if you want the editor itself, since its CLI is a thin companion to the IDE rather than the main product.

Check the Four Side by Side

The table holds the facts that decide most picks. Prices are the entry plan that includes the tool, in USD per month as listed on each vendor’s pricing page on 5 November 2026:

Feature	OpenCode	Claude Code	Codex CLI	Cursor
Interface	Terminal TUI, desktop app	Terminal CLI	Terminal TUI	VS Code fork plus agent CLI
License	MIT	Proprietary, all rights reserved	Apache-2.0	Proprietary
Models	75+ providers via Models.dev	Claude, also via Bedrock, Vertex or a gateway	OpenAI models, plus local via --oss	Grok, third-party on Premium and up
Sign-in	API keys, ChatGPT plan, Copilot, OpenCode Go	Claude plan or Console API key	ChatGPT plan or API key	Cursor account or CURSOR_API_KEY
Project instructions	AGENTS.md only	CLAUDE.md (can read AGENTS.md)	AGENTS.md	.cursor/rules or AGENTS.md
MCP config	opencode.json, mcp.servers	.mcp.json or ~/.claude.json	~/.codex/config.toml	.cursor/mcp.json
OS sandbox	None, permission rules only	Optional, bubblewrap on Linux	On by default, bubblewrap on Linux	CLI --sandbox flag
Local models	Yes, OpenAI-compatible endpoints	Through Ollama’s Anthropic API, needs a large model	Yes, --oss or a custom provider	No documented route
Entry price	$0 plus API, or Go $10	Pro $20	Plus $20 (Free and Go get limited use)	Plus $8 (Grok models only)

Two rows changed most since the first version of this comparison. Claude Code is no longer Claude-only in practice, because Ollama now exposes an Anthropic-compatible API, and Cursor moved to new plan names in which its cheapest paid tier cannot reach Claude or GPT at all.

OpenCode

OpenCode is the open-source one, maintained by Anomaly at github.com/anomalyco/opencode with roughly 223,000 stars and an MIT license. The current line is OpenCode 2, which shipped 2.2.5 on 30 October 2026, and its install path differs from the 1.x line that most older tutorials (including our first pass at this page) used. Install OpenCode 2 with the script from the project README:

curl -fsSL https://opencode.ai/v2/install | bash

The script drops the binary in $HOME/.opencode/bin, so open a new shell before checking the version:

opencode --version

On our VM it reported the 2.x line, not the 1.x builds older guides show.

opencode v2.2.5

The npm package is now @opencode/cli, and Homebrew users get the fastest updates from the project tap rather than the official formula:

npm i -g @opencode/cli@latest
brew install anomalyco/tap/opencode-v2

Inside the TUI, run /connect to add a provider and /models to pick one (the paid provider sign-ins were not run for this update). OpenCode’s catalog comes from Models.dev and covers 75+ providers, and it also accepts a ChatGPT Plus or Pro sign-in, a GitHub Copilot subscription and its own OpenCode Go plan. Release 2.2.3 added a Claude Agent provider that reuses an existing Claude Code login, so you can drive Claude from OpenCode without a separate API key. Our OpenCode setup guide walks through providers and agents in more depth.

The 2.x config format is where people trip. MCP servers now sit under mcp.servers instead of directly under mcp, custom providers live under providers with package and settings keys, and a server is switched off with disabled rather than enabled. The migration guide says a 1.x opencode.json still loads and converting it is optional, so the V2 shape is the recommended form rather than a hard requirement. What does break is V1 plugins, which don’t run in V2.

Two primary agents ship by default and Tab switches between them. Build has full access, and Plan blocks file edits outside its own plan files, but in V2 Plan can still run shell commands without asking, because every agent starts from an allow-all policy. A general subagent handles multi-step searches and you call it with @general. The third-party Oh My OpenAgent orchestration layer was written for the 1.x plugin API, so check its README for V2 support before you rely on it.

Where OpenCode falls short is guardrails. It has no OS-level sandbox, and the V2 default lets the agent edit files and run shell commands without prompting, so apart from a few built-in .env read rules it can do anything your user can until you add a rule such as {"action": "shell", "resource": "*", "effect": "ask"} to the permissions list. Quality also depends entirely on the model you connect: OpenCode with a small local model is a very different tool from OpenCode with a frontier model.

Claude Code

Claude Code is Anthropic’s agent, and it is the most opinionated of the four. Anthropic recommends the native installer, which needs no Node.js, over the npm package:

curl -fsSL https://claude.ai/install.sh | bash

You should see the installer end with the version and the binary’s location.

✔ Claude Code successfully installed!
  Version: 2.1.316
  Location: ~/.local/bin/claude

The setup docs list Ubuntu 20.04 or Debian 10 and later with 4 GB of RAM, and apt, dnf and apk repositories exist if you prefer packages. You need a Claude Pro, Max, Ultra, Team or Enterprise plan, or a Console account billed per token, because the free Claude plan does not include Claude Code. Start it in a project directory:

cd ~/projects/myapp
claude

The first run opens a browser sign-in, which we did not run here because it needs a paid plan. For CI, claude setup-token creates a long-lived token, and setting ANTHROPIC_API_KEY skips the login prompt entirely. Claude Code reads CLAUDE.md for project rules, and its memory docs say it can read a repository’s AGENTS.md in its place, which matters if you share a repo with Codex or OpenCode users.

Its strength is the extension surface around the model. Hooks run your scripts before and after tool calls, subagents in .claude/agents take scoped jobs with their own tools, skills package repeatable workflows, and claude agents manages background sessions you can attach to later. That matters more than it sounds, because a hook that blocks a bad command is a stronger guarantee than a line in a prompt asking the model to behave.

The cost is lock-in to Anthropic’s terms and a closed codebase. Language-server support comes through code-intelligence plugins, which is now more than OpenCode 2 offers, since V2 keeps lsp settings but doesn’t run language servers. The Claude Code cheat sheet lists every flag and slash command.

Codex CLI

Codex CLI is OpenAI’s terminal agent, written in Rust and released under Apache-2.0 at github.com/openai/codex. Release 0.166.0 landed on 29 October 2026. Install it with the official script, or with npm or Homebrew:

curl -fsSL https://chatgpt.com/codex/install.sh | sh

The package-manager equivalents install the same binary:

npm install -g @openai/codex
brew install --cask codex

Pick one method. When we ran the script after an npm install, it warned that “Multiple managed Codex installs can be ambiguous because PATH order decides which one runs”, so remove the other copy first. Confirm the build:

codex --version

You get the same build number as the release tag.

codex-cli 0.166.0

Sign in with codex login, which opens the ChatGPT OAuth flow by default and also accepts an API key. A ChatGPT sign-in bills against your plan and unlocks the cloud features, while API-key mode bills per token and loses cloud tasks, GitHub review and Slack. We did not sign in for this update, so codex login status on our VM printed Not logged in. In scripts it exits 0 when credentials exist, which makes a cheap pre-flight check (the codex exec half needs a signed-in account and was not run here):

codex login status && codex exec "run the test suite and fix the first failure"

Codex reads AGENTS.md for project instructions and keeps subagents, hooks, skills and plugins in ~/.codex/config.toml. Its session handling is the richest of the four, and these are the commands you’ll reach for:

• codex resume --last to reopen the latest session
• codex fork to branch a session into a new one
• codex exec --json for CI runs
• codex exec --worktree to work in a managed Git worktree
• codex cloud to hand a task to OpenAI’s hosted runners

The fork and worktree pair is the one we’d use most, because it lets you try a second approach without losing the first. Our Codex CLI cheat sheet covers the full command set.

One change catches people who followed older guides. The codex mcp-server command and the standalone binary were removed, and the CLI reference points you to the Codex app server instead, so a setup that ran Codex as an MCP server for another agent breaks after upgrading.

Cursor

Cursor is still the only one of the four that gives you a full IDE. It is a VS Code fork with the agent built into the editor, so you get inline diffs you accept or reject line by line, Tab completion, the debugger and your extensions in one window. For frontend work where you want to see the change in context before it lands, that review loop is hard to beat from a terminal.

The old “Cursor can’t run on a server” complaint is only half true now. The editor still needs a desktop, but the Cursor CLI installs on Linux, macOS, WSL and native Windows, and its binary is called agent:

curl https://cursor.com/install -fsS | bash

Cursor versions its CLI by build date rather than semver:

agent --version

Ours was the 22 October build.

2026.10.22-27dcf5f

After agent login (not run here), the CLI offers Agent, Plan and Ask modes, a headless -p print mode with JSON output, --resume, and -w to work in a Git worktree. Prefixing a prompt with & hands it to a Cloud Agent that runs in an isolated VM on Cursor’s side.

Pricing is the part to read carefully. Cursor is now sold inside what its docs call The X Subscription, shared with Grok, and the cheapest paid tier (Plus at $8) reaches Grok models only. Claude, GPT and Gemini need Premium or higher and are billed at API list price from prepaid credit. Bring-your-own-key covers OpenAI, Anthropic, Google, Azure OpenAI and Bedrock for chat models only, and Cursor documents no route to a local model.

Add an MCP Server in Each Tool

All four speak MCP, but each stores servers in a different file, so a team that mixes tools ends up maintaining four configs for the same server. To compare like for like, we add the remote Context7 docs server to each one. Claude Code takes the transport as a flag and writes to .mcp.json or ~/.claude.json depending on --scope:

claude mcp add --transport http --scope project context7 https://mcp.context7.com/mcp

It confirms the scope and the file it changed.

Added HTTP MCP server context7 with URL: https://mcp.context7.com/mcp to project config
File modified: /home/josphat/myapp/.mcp.json

A project-scoped server doesn’t load until someone approves it, which stops a cloned repo from starting tools behind your back. claude mcp list shows that state:

context7: https://mcp.context7.com/mcp (HTTP) - ⏸ Pending approval (run `claude` to approve)

Codex writes a [mcp_servers.context7] table into ~/.codex/config.toml:

codex mcp add context7 --url https://mcp.context7.com/mcp

Expect a surprise here. Codex saves the server, detects that Context7 supports OAuth and starts the login flow in the same command, so on a headless box the terminal sits waiting for a browser callback:

Added global MCP server 'context7'.
Detected OAuth support. Starting OAuth flow…
Authorize `context7` by opening this URL in your browser:
https://clerk.context7.com/oauth/authorize?response_type=code&client_id=...

(Browser launch failed; please copy the URL above manually.)

Codex has already saved the config at that point, so Ctrl+C is safe and codex mcp login context7 finishes the sign-in later. The list shows the server enabled but not authenticated:

Name      Url                           Bearer Token Env Var  Status   Auth
context7  https://mcp.context7.com/mcp  -                     enabled  Not logged in

OpenCode 2 writes to the project config unless you add --global, and remote servers try OAuth by default:

opencode mcp add context7 --url https://mcp.context7.com/mcp

It wrote opencode.json in the project directory using the new mcp.servers shape:

{
  "mcp": {
    "servers": {
      "context7": {
        "type": "remote",
        "url": "https://mcp.context7.com/mcp"
      }
    }
  }
}

One quirk on 2.2.5: opencode mcp list right after the add printed No MCP servers configured, yet a later opencode run --print-logs in the same directory logged message="mcp connected" server=context7 tools=2. Trust the run log over the list command until that is fixed.

Cursor has no add command, so you edit the JSON yourself. Open the project file:

mkdir -p .cursor && vim .cursor/mcp.json

Add the server under mcpServers. The editor and the agent CLI read the same file:

{
  "mcpServers": {
    "context7": {
      "url": "https://mcp.context7.com/mcp"
    }
  }
}

Like Claude Code, the Cursor CLI holds the server back until you approve it (agent mcp list printed context7: not loaded (needs approval)), and --approve-mcps skips that in headless runs. Codex and Claude Code both have mcp login subcommands for OAuth servers, OpenCode uses opencode mcp auth, and Cursor takes OAuth client details in an auth block. Keep secrets out of these files in every case: Cursor expands ${env:NAME}, OpenCode expands {env:NAME}, and Codex reads a token from the variable named in bearer_token_env_var.

Control What Each Agent May Run

This is the biggest practical difference between the four, and it is where Codex leads. Codex runs every command inside an OS sandbox by default, using bubblewrap on Linux and Seatbelt on macOS, with network access off and .git, .codex and .aws kept read-only. The CLI reference recommends this pair of flags for everyday local work:

codex --sandbox workspace-write --ask-for-approval on-request

The 0.166.0 help lists read-only, workspace-write and danger-full-access for --sandbox, and only on-request and never for --ask-for-approval, so older guides that use untrusted are out of date. On Linux Codex uses bwrap, so install the bubblewrap package first; the bundled fallback helper needs unprivileged user namespaces, and OpenAI’s sandbox docs say Ubuntu 24.04 may need the bwrap-userns-restrict AppArmor profile loaded. Test the sandbox on your box before trusting it:

codex sandbox -- echo sandbox-ok

On our Ubuntu 26.04 VM with bubblewrap 0.11.1 it printed sandbox-ok. The older codex sandbox linux -- ... form from earlier releases no longer exists: 0.166.0 treats linux as the command and panics with Failed to execvp linux: No such file or directory (os error 2). Save --dangerously-bypass-approvals-and-sandbox for a throwaway VM or container.

Claude Code leans on permission modes instead, with the OS sandbox as an opt-in. The 2.1.316 help lists the --permission-mode choices as acceptEdits, auto, bypassPermissions, manual, dontAsk and plan, where manual is the alias the docs give for default. auto became the start mode for terminal and VS Code sessions in 2.1.283, while claude -p still starts in the default mode. To review a change before anything is written, start in plan mode:

claude --permission-mode plan

Running /sandbox inside a session (an interactive step we did not run without a sign-in) turns on OS isolation for shell commands, built on bubblewrap and socat on Linux and WSL2. It is off by default, covers shell commands only, and hits the same Ubuntu AppArmor restriction as Codex when bubblewrap can’t start. OpenCode has no OS sandbox at all and allows everything until you write ask or deny rules. Cursor’s CLI help shows --sandbox <mode> with enabled or disabled, and -f, --force (“Force allow commands unless explicitly denied”, aliased as --yolo).

If an agent will run unattended on a machine that holds credentials, we’d pick Codex’s defaults or Claude Code with /sandbox on and sandbox.failIfUnavailable set to true, because by default Claude Code runs commands unsandboxed when the sandbox can’t start. OpenCode on its default allow-all policy should only run inside a container or a VM you can throw away.

Run Local and Open Models

Three of the four can now drive a model on your own hardware, which changes the old verdict that only OpenCode works air-gapped. The route differs per tool, and so does how much of the agent survives a weaker model. We ran each route against Ollama 0.40.13 serving qwen3:1.7b on CPU, a deliberately small model, so the point is whether the plumbing works, not answer quality. Our Ollama listened on port 11500 instead of the default 11434, so every route needed its base URL set by hand.

Codex has a dedicated --oss switch for Ollama or LM Studio, picked with --local-provider or oss_provider in the config. On the default port that is the documented route (we did not run it on 11434):

codex --oss --local-provider ollama -m qwen3:1.7b

In our run, codex exec --oss on 0.166.0 failed the same way whether we set CODEX_OSS_BASE_URL=http://127.0.0.1:11500/v1 or CODEX_OSS_PORT=11500. The session header showed provider: ollama, but the turn was rejected over a provider mismatch, not a connection error, so we can’t say whether the default port avoids it:

Error: turn/start: turn/start failed: This chat uses ollama, but your current provider is openai. Switch to ollama to continue. (code -32600), data: {"type":"modelProviderMismatch","modelProvider":"ollama","currentModelProvider":"openai"}

Overriding the built-in provider with -c model_providers.ollama.base_url=... is refused outright with model_providers contains reserved built-in provider IDs: `ollama`. Built-in providers cannot be overridden. The route we saw work was a custom provider under a new ID, using the Responses wire API:

codex exec -c model_provider=local -c model_providers.local.name=local -c model_providers.local.base_url="http://127.0.0.1:11500/v1" -c model_providers.local.wire_api=responses -m qwen3:1.7b --skip-git-repo-check "Reply with the word ready" </dev/null

Codex’s header confirms the custom provider and the read-only sandbox that codex exec uses by default, and the 1.7B model answered after its thinking text.

OpenAI Codex v0.166.0
--------
model: qwen3:1.7b
provider: local
approval: never
sandbox: read-only
--------
user
Reply with the word ready
warning: Model metadata for `qwen3:1.7b` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.
...
codex
Ready
...

Put the same keys in a [model_providers.local] table in config.toml to keep it. Keep the </dev/null in scripts too, because codex exec reads extra prompt input from stdin (it prints Reading additional input from stdin...) and the redirect stops it from blocking on an open one.

Claude Code reaches local models through Ollama’s Anthropic-compatible API. Ollama’s integration page offers ollama launch claude, or you set three variables yourself and pass the model name:

export ANTHROPIC_BASE_URL=http://127.0.0.1:11500
export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
claude -p "Reply with the word ready" --model qwen3:1.7b

It printed no answer from the model, only this warning:

Claude Code doesn't recognize the model "qwen3:1.7b", so it assumes a context window of 200k tokens. Update Claude Code, or see https://code.claude.com/docs/en/model-config#correct-the-window-for-a-gateway-or-custom-model-id to set the window.
[claude-code:unrecognized_model] {"model":"qwen3:1.7b","query_source":"sdk"}

The most likely cause is the 1.7B model, which is far too small for Claude Code’s large system prompt and tool list, but we did not rerun it with a bigger model to prove that. Ollama recommends a context window of 64k tokens or more and a much larger model for this, so budget real hardware before planning on Claude Code offline. The same base-URL mechanism is how companies route Claude Code through an LLM gateway, and CLAUDE_CODE_USE_BEDROCK=1 or CLAUDE_CODE_USE_VERTEX=1 switch it to AWS or Google Cloud billing. You do not need a cloud vendor for that routing either: our guide to self-hosting FreeLLMAPI with Docker stands a router up in Docker Compose that puts several providers behind one unified key speaking the OpenAI and Anthropic wire formats, and wires that key into OpenCode and Claude Code.

OpenCode 2 needs the least setup of the three, because Ollama and LM Studio are built-in providers. OpenCode probes Ollama on 127.0.0.1:11434, and the docs say a pulled model then shows up in /models with no config (we did not test the default port). For our port 11500, a one-line override of the built-in provider’s settings.baseURL in opencode.jsonc was accepted. opencode models still didn’t list the Ollama model, but naming it with -m worked:

opencode run --standalone -m ollama/qwen3:1.7b "Reply with the word ready"

Our small model chose to answer through a shell tool call, so you can see the Build agent run a command without asking.

> build · qwen3:1.7b
$ echo ready
ready

The process did not exit after ready, though, and sat waiting until our 100-second timeout killed it, so wrap scripted runs in timeout. Our earlier attempt without --standalone went through OpenCode’s background service and printed nothing before we stopped it, which may only mean the CPU model had not answered yet. Any other OpenAI-compatible runtime, such as llama.cpp’s llama-server, gets its own provider entry (this variant follows the docs and was not run). Open the project config:

vim opencode.jsonc

Add the runtime under its own provider ID with the OpenAI-compatible package, following the 2.x providers format:

{
  "$schema": "https://opencode.ai/config.json",
  "providers": {
    "llama-server": {
      "name": "llama.cpp",
      "package": "@opencode/ai/providers/openai-compatible",
      "settings": {
        "baseURL": "http://127.0.0.1:8080/v1"
      },
      "models": {
        "gpt-oss-20b": {}
      }
    }
  }
}

The model then appears as llama-server/gpt-oss-20b. Cursor is the odd one out here: its BYOK list covers hosted providers only, so a local model is not an option.

Run Subagents and Automation

All four now run parallel or delegated work, but they put it in different places. Claude Code and Codex keep it local and scriptable, Cursor pushes it to its cloud, and OpenCode exposes a server you can attach clients to. For CI, the non-interactive entry points are what you will call from a pipeline:

• OpenCode: opencode run "prompt", opencode serve
• Claude Code: claude -p "prompt", -c to continue
• Codex CLI: codex exec "prompt", codex exec resume --last
• Cursor: agent -p "prompt" --output-format json

Claude Code’s subagents are files in .claude/agents with their own prompt and tool list, which makes them easy to review in Git. Codex configures subagents under [agents] in config.toml and adds codex agents as a command center for sessions on a shared server. OpenCode lets you define custom agents with their own model, so a review agent on a large model and an edit agent on a cheap one can share a session. Cursor’s answer is Cloud Agents in isolated VMs that you can start from the editor, Slack, GitHub or Linear.

Choose a Pricing Tier

Every price below comes from the vendor’s own pricing page or docs on 5 November 2026, in USD per month. Annual billing is cheaper on most of them, and all four change plans often, so check the page on the day you buy:

Tier	OpenCode	Claude Code	Codex CLI	Cursor
Free	Tool is free, you pay providers	Not included in Claude Free	Limited Codex on ChatGPT Free	Free, limited agent use
Entry	OpenCode Go $10	Pro $20	Go $8 (limited), Plus $20	Plus $8, Grok models only
Heavy use	Go Plus $40	Max $100, Ultra $200	Pro from $100	Premium $30, Super $100, Ultra $200
Teams	Go Teams, per-member pricing	Team $25 or $125 per seat (monthly)	Business and Enterprise include Codex	$30, $100 or $200 per seat
Pay per token	Any provider’s API	Console API key	OpenAI API key	Third-party models from prepaid credit

The cheapest serious setup depends on what you already pay for. A ChatGPT Plus subscriber gets Codex and can also sign OpenCode into the same plan, so that $20 covers two agents. A Claude Pro subscriber gets Claude Code, and OpenCode’s Claude Agent provider can reuse that login. Cursor’s $8 Plus tier looks cheap until you notice it cannot use Claude or GPT, which pushes most people who want those models to Premium at $30 plus credit.

Use Them Together

Plenty of teams end up running two of these, and a shared AGENTS.md is what makes that workable. Codex, OpenCode and Cursor all read it, and Claude Code can read it in place of CLAUDE.md, so one file of build commands and conventions serves every agent in the repo. OpenCode 2 reads AGENTS.md only, so a repo that keeps its rules in CLAUDE.md should move them.

A common pairing is Cursor for day-to-day editing with a terminal agent for the long jobs: a multi-file refactor, a failing CI run, a migration across 40 Terraform modules. Codex fits that second slot well when the job runs unattended, because its sandbox is on by default, while Claude Code fits when you want hooks to enforce your rules on every tool call. For infrastructure work specifically, our guide on AI coding agents for Terraform, Ansible and Kubernetes shows those agents on real configs.

OpenCode earns its place next to either one when you want a second opinion from a different model family on the same diff, or a local model for code that must not leave the network. Budget is the real limit: two subscriptions plus API spend adds up fast, so pick one primary agent and keep the second for the jobs it does better. If you want the commands for all of them on one page, the free cheat sheet pack includes the OpenCode CLI cheat sheet alongside the Claude Code and Codex ones.

Keep reading