OpenCode Models for Coding Agents

OpenCode models change who receives repository context, how much context survives, which tools behave cleanly, how retries cost money, and what a failed coding-agent run looks like when someone has to explain it later.

This is for teams already using or evaluating OpenCode in real repositories. Not first-run setup. Not “which model is smartest.” The useful question is narrower: which model route should handle which coding-agent task, under which provider, with which fallback path?

OpenCode’s own model documentation is the baseline: models are selected as provider/model, variants can add request overlays, local models need explicit capability and limit records, and session-level choices do not automatically rewrite team config. That last part matters more than it sounds.

What OpenCode Model Choice Actually Changes

Provider, model family, context window, latency, and tool behavior

A model switch changes five things at once.

The provider changes the request package, credentials, base URL, headers, body fields, outage surface, and billing source. The model family changes coding style, instruction following, reasoning behavior, and patch quality. The context window changes how much repository state can stay visible before compaction or replay becomes expensive.

Latency changes the way people work. A slower model can be fine for review and planning. It becomes irritating during small edit loops. Cold starts are invisible to low-frequency users. Intolerable for high-frequency ones.

Tool behavior is the part teams underestimate. A model may look strong in chat and still mishandle tool calls, streamed reasoning fields, file references, or patch boundaries. For coding agents, those are not small quirks. They are failure modes.

Why model-agnostic coding tools still need routing decisions

OpenCode is model-agnostic in the useful sense. It can work across providers. The provider documentation says the catalog is built from Models.dev, then adjusted by project configuration, provider overlays, runtime packages, credentials, and model entries.

That does not remove routing work. It moves the routing decision closer to the team.

A single default may work for one developer. It usually fails at team scale. Repository reading, debugging, review, migration, and test repair do not need the same model every time. Some tasks need a large context window. Some need low latency. Some need stronger reasoning. Some need to stay local because the repository is restricted.

Having many tools is not the problem. Having to manage your tools is.

Compare Models by Coding-Agent Task

Repository reading, planning, code edits, debugging, tests, and review

I use task type before model name. It keeps the discussion honest.

Task	What matters most	Sensible route
Repository reading	Context size, file reference accuracy, low cost	Cheaper hosted model or capable local model
Planning	Reasoning, architecture awareness, restrained output	Strong hosted model or high-reasoning variant
Code edits	Tool reliability, patch discipline, syntax accuracy	Proven coding model with stable tool behavior
Debugging	Test interpretation, stack trace reasoning, retry cost	Stronger model after one cheap first pass
Test repair	Latency, command discipline, focused diffs	Default coding model with narrow permissions
Review	Long context, conservative judgment, security awareness	Strong hosted model, often a higher variant

OpenCode lets agents and commands choose their own model. The agents documentation shows agent profiles combining prompts, preferred models, tool permissions, and metadata. That is where routing becomes practical.

A review agent can use a stronger model and deny edits. A build agent can use the default model and allow normal coding tools. An explore agent can stay read-only. Same OpenCode install. Different risk profile.

When local models are enough and when stronger hosted models are safer

Local coding models are enough for low-risk reading, simple refactors, internal search, naming cleanup, and “explain this module” tasks. They are also useful when the repository cannot leave the machine or the network path is restricted.

They are not automatically safer for major edits. Local means local endpoint, not guaranteed tool competence.

OpenCode supports local models through an OpenAI-compatible server, but the docs are explicit: the team must provide the real model name, context limits, modalities, and tool support. OpenCode cannot infer whether those values are accurate.

I would use local models only after a canary passes:

reads repository files without leaking outside scope
follows “do not edit” instructions
produces valid patch plans
handles tool calls correctly
respects output limits
recovers from failed tests without inventing commands

Stronger hosted models are safer when the task touches architecture, migrations, security-sensitive code, flaky test diagnosis, or broad edits across several packages. Claude GPT coding comparisons are useful here only if they are task-based. “Claude is better” or “GPT is faster” is not a policy.

Cost, Context, and Reliability Tradeoffs

Token spend, context replay, retry rate, and manual repair time

The cheapest model is not the lowest-cost route.

A cheap model that needs three retries and one manual repair pass can cost more than a stronger first pass. This is especially true in agent work, where context replay eats tokens and failed edits create human cleanup time.

Track four numbers:

token spend per completed task
retry rate
manual repair time
accepted diff rate

I do not care much about raw response price without those four numbers. It is like pricing a build system by electricity cost while ignoring broken builds.

Context is the second cost trap. Large windows help, but they can hide sloppy prompting and uncontrolled file loading. Good routing asks what the task needs to see, not how much the model can theoretically hold.

Provider outages, unsupported features, and fallback paths

Provider outages are normal. Unsupported features are also normal. The problem is pretending they are surprises.

A fallback path should specify the next route by task type. If the default hosted provider is unavailable, repository reading may move to a local model. A high-risk migration may wait. A code review may switch to another hosted model with a known long-context profile.

The Models.dev catalog is useful as a reference point because it tracks providers, context, output, reasoning, tool calls, structured output, weights, price, release dates, and updates. Still, catalog metadata is not production evidence. It tells the team what to inspect. It does not replace a canary run in the actual repo.

Found the pattern on the third try: fallback policy has to be written before the outage. During the outage, people just want the task done.

Build a Practical OpenCode Model Policy

Default model, escalation rules, restricted repositories, and approval records

A practical policy starts small.

Pick one default model for normal coding tasks. Name it by OpenCode reference, not display label. Use provider/model, and include a variant only where the team has tested it. If a model comes through OpenRouter, Vercel AI Gateway, or another compatible gateway, record the gateway route. Do not pretend it is the same as direct provider access.

Escalation rules should be task-based:

use default for small edits and test repair
use stronger hosted model for cross-package planning
use review-specific model for security and regression review
use local model for restricted read-only exploration
pause instead of fallback for protected repositories when no approved model is available

Restricted repositories need their own policy. A model that is fine for a docs repo may be blocked for auth, payments, customer data, infrastructure, or unreleased product code.

Approval records should capture who approved the provider, model ID, endpoint, context limit, tool support, permissions, and rollback route. Not glamorous. Useful later.

What to test before changing team-wide model settings

Before changing OpenCode providers or default models for a team, run the same task suite every time.

Use at least six canaries:

read-only repository summary
plan-only feature change
single-file edit
multi-file edit
failing test diagnosis
review of an existing diff

The permissions documentation matters here because model changes should not quietly expand action rights. OpenCode V2 uses ordered rules with allow, ask, and deny; shell, edit, read, subagent, web, and MCP-style tool actions can be controlled separately.

Keep model testing and permission testing separate. If a run fails because edits were denied, that is not a model-quality result. If a model asks to run a broad shell command under a narrow policy, that is useful evidence.

Good enough. That is the most honest assessment I can give.

FAQ

Who approves new OpenCode models for shared repositories?

The platform owner should approve provider access and model routing. The repository owner should approve repo-specific risk. Security should approve restricted repositories, local endpoint exceptions, and tool permissions. For shared repositories, individual developers should not add new OpenCode providers as team defaults without review. A model switch changes context exposure, failure behavior, and support evidence.

What evidence should be kept after a model switch causes regressions?

Keep the model reference, provider ID, endpoint path, variant, OpenCode version, permissions, prompt, raw transcript, tool calls, patch diff, test output, retry count, and rollback time. Also keep the previous working route. Regression analysis is easier when the old and new model records sit next to each other.

How should teams communicate temporary model restrictions?

Say which model route is restricted, which repositories are affected, why the restriction exists, and what fallback route is approved. Avoid vague wording like “AI coding models are unstable.” If the issue is provider outage, say provider outage. If the issue is tool-call behavior, say tool-call behavior. If the issue is policy review, say policy review.

Conclusion

OpenCode models are not just a quality choice. They are provider, context, latency, cost, tool behavior, and permission choices bundled into one reference string.

The clean policy is simple: default route for normal work, stronger route for riskier reasoning, local route for constrained read-only tasks, and written fallback rules before anything breaks.

This conclusion has an expiration date - models update fast.

Previous posts: