OpenCode or Claude Code: weighing model choice, extensions and governance

OpenCode and Claude Code do much the same work. Both are terminal-first coding agents that read a repository, edit files, run commands and explain what they are doing. The difference that matters is who controls what. OpenCode is open source and lets you connect the model provider of your choice. Claude Code comes from Anthropic, is built around Anthropic's models, and is maintained, supported and priced by that vendor. For one developer the choice can come down to taste. For a team it touches procurement, data handling and how rules get enforced. This page compares the two on model choice, extensibility, support and governance, then sets out a pilot you can run on your own code.

Model choice: your pick or the vendor's

OpenCode is provider-agnostic. You configure one or more providers with your own credentials, and that can include models served on your own hardware. That lets you keep code with a provider your company already has an agreement with, route different tasks to different models, or switch when your needs change. Check whether the specific provider and model you need are supported in the current release.

The cost of that freedom is evaluation work. A coding agent's behavior depends heavily on the model behind it, and the prompts and tool definitions an agent ships with may suit some models better than others. Switching models is a change you should test, not a setting you flip.

Claude Code is designed around Anthropic's models, and the vendor develops the agent and the models together. If your company buys model access through a cloud platform rather than directly, check the documentation for which routes are supported.

Ask early whether model choice is a requirement (data residency, an existing contract, local-only processing) or a preference. A requirement can decide the comparison before anything else is tested. The note on governance that survives a model change explains why your rules should not hinge on which model happens to run.

Extensibility: what you can add and what you can change

The two overlap a lot here. Both read project-level configuration and an instruction file that tells the agent about your codebase; both support custom commands, specialized agents for particular tasks, and MCP servers for external tools. If you are still deciding how to add capabilities, MCP, skills or CLI tools compares the three routes.

The deeper difference is what you can change. With OpenCode you can read the source, fork it and patch it. When the agent does something surprising, you can find out exactly how the prompt and the tool call were built. The trade-off is that a fork is yours to maintain against a fast-moving upstream.

With Claude Code, the extension points are the ones the vendor provides, such as hooks that run your scripts at defined moments, skills, plugins and MCP. You can build a lot on those, but you cannot change the core loop. Check the current documentation for the extension point you need rather than assuming it exists.

Support and upkeep

With an open-source agent, support means community channels, the issue tracker and the changelog. Releases can be frequent and can change behavior, so a team should pin a version, upgrade deliberately and keep a short note of what changed. You can contribute fixes, and nobody owes you one unless you pay someone for support.

With a vendor agent, you get documentation, a status page and whatever support channel your plan includes. The vendor decides the release cadence and updates may arrive automatically, so check whether a team can pin or delay versions. Contractual commitments exist only where your agreement states them.

Either way, someone on your team needs to own the shared configuration, the instruction file and the upgrade policy. An agent nobody owns ends up configured by whoever touched it last.

Governance: where your rules actually live

• Permissions. Both let you decide which actions run freely, which ask first and which are blocked, covering file edits, shell commands and web access. Find out which settings a developer can override locally and whether the team can enforce a baseline.
• Data flow. With OpenCode, code and prompts go to whichever provider you configure, so governance is the sum of that provider's terms and your configuration discipline. With Claude Code, they go to Anthropic or to the cloud platform you route through; read the retention and training terms for your plan.
• Records. Git shows the diff. It does not show which commands produced it, which files were read along the way, or which requests were refused. Terminal scrollback is not an audit trail.
• Secrets. In both tools, block reads of environment files and credential directories, and run the agent under an account that holds no production credentials.

A baseline policy, written as pseudo-configuration rather than either tool's actual syntax:

edit:
  allow: [src/**, tests/**]
  ask:   everything else
shell:
  allow: [npm test, npm run lint, git status, git diff]
  ask:   [git push, npm install]
  deny:  [rm -rf, git push --force, curl * | sh]
read:
  deny:  [.env, .env.*, ~/.aws/**, ~/.ssh/**]
web_fetch: ask

Run a pilot instead of reading opinions

1. Pick eight to ten real tasks from your backlog: a bug fix, a small feature, a refactor, a test-writing job, a dependency upgrade, and at least one task in an unfamiliar part of the code.
2. Write acceptance criteria first. For example: “The failing test passes, no other test changes, the diff touches only the parser module, and the pull request explains the root cause.” Write acceptance criteria before the agent starts explains why the order matters.
3. Run both agents on the same tasks, from the same commit, under the same permission policy. If you try several models with OpenCode, treat each model as a separate candidate.
4. Record per task whether the criteria were met, how often you had to step in, what the policy blocked, and anything the agent read or attempted that it should not have.
5. Review the diffs without knowing which agent produced them, if you can arrange it.
6. Weigh the results against your non-negotiables: model and data requirements, support expectations and central enforcement.

For neighboring choices, see comparing terminal coding agents and terminal agent or editor agent.

Keeping governance outside the agent

Whichever agent wins, its configuration file is a policy for one machine. GoCux keeps governance with the work instead. A work order records the goal, the scope it may touch and the acceptance criteria; steps, sources and decisions accumulate on that one record. Consequential actions pause for a person. An approval applies to the single attempt it was given for and is checked again when the action runs, and the refused call is shown exactly as it was made, so you approve what was really asked. Routing between models stays inside the service, and approvals and records stay attached to the work order rather than to a particular agent or model. See development work with a reviewable result and the OpenCode integration design guide.

What to verify before you standardize

• Whether model choice is a requirement or a preference for your team, written down.
• The provider and data terms that apply to your code under each option.
• A baseline permission policy, and whether developers can override it.
• A pinned version, and an owner for upgrades and shared configuration.
• The support you can actually expect when something breaks.
• Pilot results on your own tasks, judged against criteria written beforehand.
• A record of what the agent did beyond the diff, for work that needs one.