OpenCode 2.0 turns the agent into a service. The client/server split existed from the start, but in 2.0 the server runs automatically as a single background process on your machine, and the TUI, the web interface and the desktop app all talk to that same process. That one change is what makes the rest of the release interesting, because once the harness is a local service with a real API, everything else you want from an agent setup becomes something you can script instead of something you wait for a vendor to ship.
A harness is the wrapper around the model. It holds context, runs the tools, edits files and decides what the model is allowed to touch. The model matters, and the harness decides how much of the model you actually get. OpenCode is MIT licensed and connects to 75+ providers through Models.dev, including local models. Claude Code is closed and runs Claude models only, priced from $20 a month on Pro, with Max tiers at $100 and $200. Those two sentences describe most of the difference, and most of the consequences.
What open actually buys an engineering team
The license isn't the point by itself. The point is which decisions stay yours.
With an open harness you choose the model per task. The expensive reasoning model writes the migration; a cheap model generates the session title. OpenCode exposes that directly, because small_model in config sets a separate model for lightweight work like title generation and the --model flag overrides the main one per invocation. You can also restrict what the harness is permitted to reach at all, with enabled_providers as an allowlist or an experimental.policies block that denies provider.use on a named provider. For a team doing client work under a data processing agreement, that last control is the difference between a tool you can defend in a security review and one you cannot.
You also get to read the permission model instead of trusting a description of it. Permissions in OpenCode are config, so {"permission": {"edit": "ask", "bash": "ask"}} makes both tools request approval, and on macOS an admin can enforce settings through a managed preferences profile in the ai.opencode.managed domain that a developer can't override. Deploy that by MDM and the harness config stops being a per-laptop opinion.
The honest cost of open is that you carry the integration. Nobody ships you a default that works, so you pick the models, test the tool-calling, and own the config repo. Closed harnesses sell exactly that work back to you, and for a solo developer the trade often favours buying it.
The pieces of 2.0 that change how you work
Four things in this release matter more than the rest.
The API was rewritten from scratch, and the agent knows about its own API. OpenCode will call it to move the current session into a git worktree when you start new work, rename a session, interrupt a stuck one or close a finished tab. Ask it to start rate limiting uploads in a new worktree and the worktree, the rename and the move all happen as tool calls instead of three commands you type.
Code Mode is the one I would build on first. The @opencode/codemode package is a pure interpreter for a JavaScript-like language built around calling tools, and it ingests MCP servers or OpenAPI endpoints as callable functions. Instead of one round trip per tool call, the model writes a short program that calls a tool, maps over the results and calls another. The interpreter runs only the language features it implements, so programs can't reach the network, filesystem, processes or application APIs except through tools the host supplies, and the host can cap execution time, tool calls and output size. Every MCP server in 2.0 is opted into Code Mode by default, which is why you can add a long list of servers without the context bloat that used to make people ration them. Set "codemode": false on a server when you want its tools exposed directly.
Background work got real. 2.0 adds background subagents, so the primary agent kicks off work to another one, optionally on a different model, and keeps going. It adds asynchronous shell commands so a long test run doesn't block the session, and a hotkey moves a foreground subagent or shell command to the background when it takes longer than you expected. Pair that with the always-on service and the programmatic client, which autodiscovers the local service, and scheduled agent work stops needing a bespoke daemon:
// Illustration of the shape the client package documents
import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"
const endpoint = await Service.ensure()
const client = OpenCode.make({
baseUrl: endpoint.url,
headers: Service.headers(endpoint),
})
const session = await client.session.create({
location: { directory: process.cwd() },
})
await client.session.prompt({
sessionID: session.id,
text: "Review the current changes",
})
Plugins stopped being decoration. The team implemented nearly every 2.0 feature as an internal plugin, and there are now 80+ of them, which is the only mechanism I trust to keep a plugin API maintained. TUI plugins are stable, everything hot-reloads, and the agent can write a plugin for itself mid-session and use it immediately.
Where the token bill actually goes
Agentic coding spends most of its money on input tokens. The agent reads files, reads them again after an edit, and re-reads context after a compaction, so the input price is the number to watch. Claude Opus 5.5 is $4 per million input and $20 per million output, and Claude Fable 5.1 is $10 and $50. On published open-weight pricing, Qwen3-Coder is $0.18 per million for both input and output, against GLM-4.6 at $0.60 and $2.20 and Kimi K2 0905 at $0.60 and $2.50. An order of magnitude on input, for work where the model is mostly reading.
That gap isn't an argument for running everything on the cheapest model. It is an argument for routing. The work that benefits from a frontier model is the ambiguous part, like deciding an approach across unfamiliar code or untangling a failure whose cause is three layers from the symptom. The work that doesn't is most of the volume, and it looks like writing the test for a function you just specified, applying a rename across forty files, generating a changelog entry or summarising a diff. An open harness lets you put each class of work on a different model in the same session, and 2.0's background subagents let you trigger a subagent manually on a different model, so the cheap model reviews while the expensive one keeps building.
Two settings matter more than model choice for input spend. Compaction is configurable, and prune removes old tool outputs to save tokens but defaults to false, so turning it on is a deliberate act. MCP tools also consume context, which is why the v2 docs tell you to add only the servers you need even with Code Mode reducing the bloat.
Local models close the loop for work that cannot leave a machine. OpenCode treats a local server as an ordinary OpenAI-compatible provider, including llama.cpp's llama-server with an explicit context and output limit:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"llama.cpp": {
"npm": "@ai-sdk/openai-compatible",
"name": "llama-server (local)",
"options": { "baseURL": "http://127.0.0.1:8080/v1" },
"models": {
"qwen3-coder:a3b": {
"name": "Qwen3-Coder: a3b-30b (local)",
"limit": { "context": 128000, "output": 65536 }
}
}
}
}
}
The docs are blunt about the failure mode. If tool calls aren't working well, pick a model with strong tool-calling support. Cheap tokens on a model that fumbles tool calls cost more than expensive tokens on one that does not, because every retry pays the input price again.
Plan the upgrade around three breaking changes
2.0 isn't a drop-in replacement. 1.0 plugins will not work, the server API is completely different, and tui.json config has moved. Everything else is described as backwards compatible. You upgrade by getting onto the latest 1.x release and running opencode upgrade --major, and the release note suggests pointing OpenCode at the migration doc so it migrates your config for you.
Sequence it in that order. The config move is mechanical. The server API break is the one that bites teams who wrote scripts against 1.x, and it is also the reason to do the upgrade, because the old API, by the maintainers' own account, grew haphazardly and the new one was rebuilt around what agents turned out to need. If you have internal plugins, treat them as rewrites instead of ports, and check whether the feature you built exists among the 80+ internal plugins now shipping.
One operational note worth setting before anyone else upgrades. OpenCode 1 and 2 both use the opencode command and cannot be installed side by side under their default command, so a mixed team needs a decision about which version the shared automation targets.
Pin your models and permissions in a committed config first
Before you upgrade anything, put a project opencode.json in the repo that names the model, the small_model, the provider allowlist and the permission settings for edit and bash. Config files merge rather than replace, with project config overriding global, so a committed project config gives every engineer the same model routing and the same approval gates without taking away their personal preferences. Then upgrade, then move your scripts to the new API, then start adding MCP servers now that Code Mode makes them cheap to carry.
If you are weighing agent tooling against governed data access on the platform side, our work on that is at /ai.
Frequently asked questions
What is the biggest change in OpenCode 2.0?
The server now runs automatically as a single background process, and every client (TUI, web, desktop, programmatic) talks to that one process, which is what makes scripted and scheduled agent work practical. The API was also rewritten from scratch, and the agent can call its own API to create worktrees, rename sessions and interrupt other sessions.
Is OpenCode free, and what does it cost to run?
OpenCode itself is MIT licensed and free, and you pay for inference through whichever provider you connect. Published open-weight pricing runs roughly $0.18 to $0.60 per million input tokens, against $4 per million input for Claude Opus 5.5, so the bill depends on your model routing more than on the harness.
How is an open harness different from Claude Code?
Claude Code is closed source and runs Claude models only, on subscriptions from $20 to $200 a month; OpenCode is open source and connects to 75+ providers including local models, so the model choice, the permission model and the provider allowlist are yours to configure and audit. The trade is that you own the integration work a closed product does for you.
What breaks when upgrading from OpenCode 1.x?
Three things break. 1.0 plugins don't work in 2.0, the server API is completely different, and tui.json config has moved. Get onto the latest 1.x release, run opencode upgrade --major, and note that OpenCode 1 and 2 share the opencode command and cannot be installed side by side under their defaults.