OpenCode vs Claude Code: a practical comparison

Recommendation: OpenCode fits a team that needs to choose between model providers or run local models. Claude Code fits a team that already works with Anthropic models. Neither name says which model, permissions or repository setup a session used, so a fair comparison runs both on the same task, from the same commit, with the same test.

The map shows the three settings that differ between the two tools: where the model comes from, which file holds project instructions, and which file holds permission rules. The sections below cover each one, then the trial that compares them.

Side by side

This table describes configuration, not code quality. A claim that one tool writes better code would need a controlled run, and the result would depend on the model behind it as much as on the tool.

Models and accounts

In OpenCode, a provider is connected first and a model is then picked with /models (model selection). The same repository task can run against a hosted model, a different vendor or a local endpoint without changing anything else. Each model still has its own tool support, pricing and data policy, so the provider and model name belong in the trial record.

Claude Code signs in to an Anthropic account or uses an API key (setup). /model switches between the Anthropic models that account can use. A working installation on one account does not move billing to a different subscription or API key.

Project instructions

Both tools read a Markdown file at the repository root before they start work. OpenCode reads AGENTS.md and falls back to CLAUDE.md only when no AGENTS.md exists. Claude Code reads CLAUDE.md. A repository that already has a CLAUDE.md therefore gives both tools the same instructions with no extra file.

/init in either tool scans the repository and drafts the file. The draft guesses build and test commands from what it finds. It needs a review before it is committed, since a wrong test command in the instructions misleads every later session.

Permission rules

Both tools let a team decide which actions run without asking. The difference is the default.

OpenCode allows most tools out of the box. Two actions ask first: external_directory (paths outside the project) and doom_loop (the same tool call repeated three times with identical input). Reads of .env files are denied by default (permissions). A stricter project policy in opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "edit": "ask",
    "bash": { "*": "ask", "pnpm test*": "allow", "git push*": "deny" },
    "external_directory": "deny"
  }
}

• edit: "ask" asks before every file write, edit or patch.
• bash takes patterns. * matches any command, and the last matching rule wins, so pnpm test runs freely, git push is blocked and everything else asks.
• external_directory: "deny" blocks any path outside the project directory.

Claude Code asks before file edits and before shell commands outside a built-in read-only set (permissions). Rules live in .claude/settings.json and can be viewed or changed with /permissions:

{
  "permissions": {
    "allow": ["Bash(pnpm test *)"],
    "deny": ["Bash(git push *)", "Read(./.env)"],
    "defaultMode": "default"
  }
}

• allow and deny take tool rules. Bash(pnpm test *) matches pnpm test with any arguments.
• Read(./.env) blocks reading the .env file, matching OpenCode's default.
• defaultMode sets how a session starts. default asks as described above, acceptEdits accepts file edits without asking, and plan reads and explores without editing source files.

A project instruction such as "never push" is not a permission rule. Both tools enforce the rules in their config files, while the instruction file only shapes what the model tries to do.

A fair trial

A comparison only holds when both runs get the same task, the same starting code and the same access. Separate git worktrees give each tool its own directory from one recorded commit, so neither run sees the other's edits:

BASE=$(git rev-parse HEAD)
git worktree add -b trial/opencode ../trial-opencode "$BASE"
git worktree add -b trial/claude ../trial-claude "$BASE"

• git rev-parse HEAD prints the full hash of the current commit. Storing it in BASE makes the starting point exact and repeatable.
• -b trial/opencode creates a new branch for that run.
• ../trial-opencode is the directory the worktree is created in.
• "$BASE" starts both branches from the same commit.

The brief given to each tool contains the same four things: the bug report, the files or examples nearby, the exact acceptance command, and a limit on unrelated changes. A task small enough to review in one sitting keeps tool problems apart from environment problems. A missing compiler in one directory is a setup failure, not a coding failure.

Production credentials stay out of both runs. If one tool gets broader access to finish, the runs are no longer the same experiment, and the exception goes in the report.

Cost and the trial report

Cost belongs to the model, not the executable. OpenCode is free to install, but the configured provider bills for tokens. Claude Code usage counts against an Anthropic subscription or API key. A subscription fee is not added again on top of included usage, and hitting a quota limit is not a code-quality result.

The report for each run records:

Keeping failed attempts in the report stops the conclusion from resting on the best run only. The AI code review guide covers the review step, and the Claude Code, Codex and Gemini CLI comparison covers a wider set of agents.

Running both in one place

Oyren Codespaces run Claude Code and OpenCode on the same Linux machine with browser VS Code and a terminal, so both worktrees sit side by side. Agent sign-in and model usage stay with each tool's own account, separate from the Codespace runtime.