OpenCode 2.0: The Terminal Agent Grew a Server, Broke Your Plugins, and Started Paying You in DeepSeek

"The old API grew haphazardly as we and the world collectively learned what agents are and should be. It was bad." — the OpenCode 2.0 announcement, October 13, 2026

There is a specific kind of email a developer gets that says almost nothing and changes the whole week. OpenCode's landed Friday night, and it read, in its entirety, like this:

hey

opencode 2.0 is out. it's the next major version of opencode

we also started phase 3 of operation cheepseek. opencode go now gets $80 of usage for deepseek v4.1 flash

Eighteen words, one subject line, two links. No changelog, no migration guide, no warning. And that is exactly the right way to release a major version, because "it's the next major version" is doing an enormous amount of work in that sentence.

OpenCode 2.0 is not a big feature drop. It's a different animal. Version 1.8 — the one many of us are still running — is a very good open-source terminal agent. Version 2.0 is a local agent runtime that happens to ship with a terminal client. That's a real distinction, and it's worth walking through what actually changed before you type opencode upgrade --major.

The one architectural change that explains everything else

From the beginning, OpenCode had a client/server model. But it didn't use it by default. You could run a server and connect a TUI and a web client to it, and a small number of power users did. Everyone else ran a process and got a process.

In 2.0, the server is the default. One background service starts automatically on your machine and owns sessions, config, permissions, models, MCP servers, plugins, and tool execution. The TUI connects to it. The web interface connects to it. The desktop app connects to it. Custom scripts connect to it. They are all talking to the same daemon, looking at the same sessions.

That single decision cascades into nearly every other headline:

• Unified sessions. Start a task in the terminal, open the web UI, and it's the same conversation — not a re-implementation of one. opencode pair prints a short-lived URL, a username, and a password, and your browser joins the party at http://127.0.0.1:49374. Desktop gets remote pairing with a QR code over OpenTunnel.
• Persistent work. Long-running jobs survive your interface changing. Close the TUI, the work keeps happening because the work was never inside the TUI.
• Programmatic access as the norm. @opencode/client auto-discovers the local service and just works — which is the unlock for scheduled tasks. opencode api gives you the same thing from the shell; opencode --standalone runs a private server if you'd rather not share.

If you run OpenCode headless in CI or behind an API, this is the part to think hardest about. The default is now one shared server per user account. You get a private server with opencode --standalone, or with opencode service set disabled true.

Code Mode: the agent stops calling tools one at a time

This is the feature that most deserves the phrase "changes the shape of the thing."

In 1.x, tool use looked like every other agent: the model picks a tool, the tool runs, the result comes back, the model decides again. Works fine for a few calls. Gets expensive and slow when a task is fifty predictable calls with a transform in the middle.

2.0 introduces @opencode/codemode, a minimal JavaScript interpreter. It ingests your MCP servers and OpenAPI endpoints and turns them into functions the agent can call from a script. So instead of this:

list GitHub issues → return to model → interpret → call Linear once per issue → return → summarise

You get this:

const { issues } = await tools.github.list_issues({
  owner: "anomalyco", repo: "opencode",
  labels: ["bug"], state: "OPEN"
});
const filed = await Promise.all(issues.map(({ title }) =>
  tools.linear.save_issue({ team: "OC", title })
));
return filed.map(i => i.identifier);

One round trip. Map, filter, aggregate, branch — all inside the execution instead of across model turns. And because every MCP server is opted into Code Mode by default, you can attach a hundred of them without blowing up your context window, because the agent discovers functions rather than reading every schema on every request.

Two honest caveats. First, this is not "run arbitrary JavaScript." The interpreter has no unrestricted filesystem access, no imports, no timers, no direct fetch — it only reaches tools in its catalog, execute carries its own permission gate, and nested tool calls still respect their individual permissions. Second, Code Mode earns its keep on multi-tool pipelines. If your task is "read one file, change one line," it's overhead.

Background work: the agent stops blocking you

Two additions, and they're siblings.

Background subagents. The primary agent can hand an independent task to another agent — optionally running a different model — and keep working. Ask for a code review to run in the background while you keep prompting, and you're no longer waiting on a review to move forward.

Background shell commands. The shell tool can be invoked asynchronously, so bun test or a build doesn't freeze your session. The agent gets notified when it finishes.

And when something you thought would be quick turns out not to be, Ctrl+B shoves the running foreground shell or subagent into the background. In 1.8, long tasks generally meant sitting still.

Worth noting the direction of travel: Anthropic reportedly hardcoded an instruction telling Opus 5 not to use subagents in Claude Code, because it hurt performance. OpenCode 2.0 is betting the opposite way — that the newest models are good at orchestration and a harness should let them express it. One of those bets is wrong. The next six months will say which.

Plugins: 80+ internal, hot-reloadable, and yes — yours are broken

Here's the part that will cost you a weekend.

Anomaly made a deliberate choice: they implemented nearly every 2.0 feature as an internal plugin, and there are now more than eighty of them. The reasoning is ruthless and correct — if your own architecture depends on the plugin API, you will maintain the plugin API. TUI plugins also graduate from experimental to stable.

They also built full hot-reload. OpenCode can write a plugin for itself mid-session and use it immediately, no restart. The system can grow new organs while it's running.

Now the bill. The migration guide lists three intentional breaking changes, and this is the first:

Plugins use a new plugin API. V1 plugin implementations do not run in V2.

Not "need a tweak." Do not run. A V2 plugin exports Plugin.define({ id, setup }); a V1 plugin is simply the wrong shape.

The community reaction splits cleanly along this line. Hacker News commenters running stock config report 2.0 spawning async subtasks more aggressively than 1.x ever did — more than five in flight out of the box, with background shells handled properly. Reddit is blunter: "Opencode 2 vs v1.19.0" says v2 broke the whole workflow, another post titled "one weekend with OpenCode V2" reports most custom additions broke, several bugs, and — worst of all — some modifications that can't be expressed as plugins and therefore have to be re-applied after every update.

Both are true. The docs describe a smooth path for stock setups; the loud posts are from people with heavy plugin stacks. Anomaly says this out loud in their own guide, which is more than most vendors manage.

What else breaks, and what quietly disappears

The server API is completely different. The announcement is unusually candid about why: "The old API grew haphazardly... It was bad." They rebuilt it from scratch around real usage across millions of users. Anything you wrote against V1 endpoints needs to move to @opencode/client and the V2 API reference. The payoff is that the new API is expressive enough for OpenCode to call its own API — it will create a git worktree for new work, rename and move the session into it, or, when you say "the flaky test session is stuck, stop it," find the session, read its context, interrupt it, tell it to quarantine the test, and close your leftover tabs.

Terminal config moves. Layered tui.json(c) files become one global ~/.config/opencode/cli.json. Your global tui settings auto-migrate on first V2 launch. Project-local client config does not.

LSP support is gone. This one is easy to miss and will annoy the right kind of person. V2 accepts and preserves your lsp configuration but does not run language servers, expose LSP tools, or produce LSP diagnostics. The docs' answer: use your lint, typecheck, or compiler commands instead.

The CLAUDE.md fallback is dropped. V2 discovers AGENTS.md only. If you share a repo between OpenCode and Claude Code and you've been keeping guidance in CLAUDE.md, move it to AGENTS.md and point the other tool at that. (Recent releases added OPENCODE_DISABLE_CLAUDE_CODE flags for .claude skill discovery, so this is a live area.)

And a security default flips. V1 asked before touching paths outside the project. V2 allows external_directory by default. If you want the old behaviour back, add this to your permissions array:

{ "action": "external_directory", "resource": "*", "effect": "ask" }

The config rewrite, if you want it

You don't have to convert anything. V2 reads V1 config from the same locations and normalizes V1 fields in memory without rewriting the file, and the docs say supported V1 config, agent definitions, commands, and skills are intended to keep working — if something supported breaks, treat it as a compatibility bug.

But the native V2 shape is genuinely nicer, and it's different enough that you should recognise it when a colleague sends you one. The highlights:

• Permissions become one ordered array of { action, resource, effect } instead of a map grouped by tool. The ordering makes precedence explicit — a real improvement over trying to reason about nested overrides.
• Several actions get renamed: bash → shell, task → subagent, and write + patch collapse into edit.
• agent becomes agents, prompt becomes system, and model variants fold into the model string with a #: anthropic/claude-sonnet-4-5#high. maxSteps becomes steps.
• MCP servers group under mcp.servers, enabled inverts to disabled, and the single timeout splits into timeout.catalog and timeout.execution.
• Skills' separate paths and urls merge into one ordered array. Your .opencode/skills/ directory is discovered as before.

The single best trick in the whole migration: ask OpenCode to do it. The guide's recommended prompt is literally "Migrate my OpenCode configuration, including file-based definitions, from the V1 format to the native V2 format. Preserve its behavior and all unrelated settings." V1 and V2 fields can coexist at the top level, and conversion doesn't have to happen at once.

So what is 2.0 actually for?

Step back and the strategy is legible. @opencode/sdk ships the exact code that powers the CLI, so you can strip it down and run your own flavour of OpenCode on a server or in specialised environments like Durable Objects — and then connect any OpenCode client to it, because it speaks the standard server protocol. There's an optional Effect-based API for the people who live there.

That is the move from tool to platform. And it's a different lane than the two obvious rivals are in.

Codex is the cloud-native one. Reusable per-repo cloud environments, up to eight parallel subagents in isolated cloud sandboxes, Chrome extension, goals, mobile access. It's included in ChatGPT plans from Plus at $20/month up through Pro, with GPT-5.6 Sol as the recommended default. Morph's October measurement put Codex at $8.39 per DeepSWE task with 74% resolution. If your work is "fan out ten independent tasks and review the diffs," Codex is built for exactly that.

Claude Code is the harness-and-model-quality play. Deepest terminal harness, hooks, Agent Skills, custom subagents, worktree isolation, browser control via the Chrome extension, and — as of this month — Code Review out of research preview for Team and Enterprise, roughly three times faster. Claude Opus 5.5 leads SWE-bench Pro at 89.9%; Opus 5 tops SWE-bench Verified at 97.00%. Included in paid Claude plans from Pro (~$20/month) to Max ($100/$200). Enterprise reality lands around $150–250 per developer per month in normal use. If your work is "this is hard, get it right," that's the lane.

OpenCode 2.0 is the model-agnostic, local-first, embeddable one. It doesn't care which model you bring; it cares that your agent runtime runs on your machine, that its own API is programmable, that its plugins reload live, and that you can embed the whole thing in a service you own. Nobody else in this list is offering that, because nobody else has a business model that wants it.

Operation Cheepseek Phase 3, or: the bribe

Which brings us back to the second line of that email.

"Cheepseek" is a pun — cheap plus DeepSeek — and phase 3 is a straight-up subsidy. OpenCode Go now allocates $80 of monthly usage to DeepSeek V4.1 Flash. For context, that's the top of the paid ladder: most of the roster sits at $60, the premium tier (Kimi K3, GLM-5.3, GPT 6 Luna, Claude Haiku 5.5) at $15. Flash now sits above all of them, at roughly 34,670 requests per five hours on the $10/month Go plan. Hacker News described it more honestly than any marketing copy: a 4x usage promo.

Why push that particular model so hard? Because DeepSeek's V4.1-Flash-1017 update, dated one day before the newsletter, moved the needle sharply:

Benchmark	V4.1-Flash	1017 update
Terminal-Bench 4.0	31.2	42.3
Apex Bench v1.1	64.6	72.1
DeepSWE v1.1	74.2	77.0
Automation-Bench	54.8	60.5
Humanity's Last Exam (no tools)	36.8	42.6

That Terminal-Bench jump takes it past GLM-5.3 (37.9) and past GPT-5.6 Sol (39.9) on agentic command-line task completion. It's MIT-licensed, it has a 1M-token context window, and its KV-cache compression — about 890 bytes per token, versus roughly 12 GB per million tokens for GLM-5.3-Flash — is what makes long agent transcripts affordable to run at all. And it's a flash model: it finishes tasks in fewer tokens and shorter outputs, so its per-task cost beats models with two-to-four-times higher list prices.

It is not the best model in the world. Opus 5 still wins raw reasoning and several vision benchmarks, and GPT-5.6 Sol edges ZeroBench. But "second-tier on reasoning, first-tier on agentic work, and effectively free at volume" is an extremely good thing to put in front of someone deciding whether to switch agents.

And note the framing. OpenCode isn't discounting their software — that's MIT and free forever. They're discounting the fuel. Go Plus at $40/month raises the ceilings further, and if you burn through the allowance, "Use balance" falls back to pay-as-you-go rather than blocking you mid-task.

Two things to read before you point proprietary code at it: most providers on Go are zero-retention, but Grok 4.7/4.6, GPT 6 Luna, GPT 5.6 Luna, Claude Haiku 5.5 and Cat Jam Free keep logs for 30 days, and the two "Contributor" models — Gemini 4 Argon and Muse Spark 1.3 — are cheaper precisely because they train on your prompts. Also, there's no longer a single base URL; the endpoint now depends on the model's wire protocol (/openai/v1/chat/completions, /openai/v1/responses, or /anthropic/v1/messages). And Go is not tied to OpenCode — Claude Code, Codex, Hermes, Pi, ZCode and others are all validated clients.

What to watch

• Your plugin inventory. If you have any, read the plugin migration guide and port one at a time. Keep V1 until each one works.
• The external_directory default. Flip it back to ask before you upgrade if you're anywhere near a shared machine.
• Anything scripted against the V1 server API. Budget the @opencode/client migration, don't hope.
• CI and headless setups. Decide deliberately between the shared service and opencode --standalone.
• CLAUDE.md repos. Move to AGENTS.md.
• Whether the subagent bet pays off. OpenCode 2.0 is all-in on models orchestrating themselves; Anthropic went the other way. That divergence is the most interesting thing in the release.

The bottom line

OpenCode 2.0 is the moment the project stopped being a good open-source CLI and became a platform — a shared local service, a rebuilt API, an embeddable SDK, a hot-reloadable plugin system, and a Code Mode that turns your tool catalogue into a scripting interface. If you run stock config, opencode upgrade --major is a fifteen-minute upgrade with a nicer diff viewer at the end. If you built plugins, your weekend is booked, and Anomaly's own documentation will tell you exactly why.

The honest framing is this: the platform is the product now, and your plugins were the beta test. They're compensating you with four times the usage allowance on a model that just beat GPT-5.6 Sol at the thing agents actually do. That's not a bad severance package.

And if you're a developer in the middle of this genuinely hard migration — there's nothing to sell you here. The software is free, and always will be. Someone just decided to buy you the tokens.

---

Sources: OpenCode 2.0 announcement and migration guide (opencode.ai/v2/docs/migrate-v1); OpenCode changelog (v2.0.29–v2.0.32, Oct 2026); OpenCode Go plan page and pricing docs; The New Stack (Oct 12, 2026); Developers Digest upgrade analysis (Oct 11, 2026); aiidelist 2.0 guide; Hacker News and r/opencode migration threads; DeepSeek V4.1-Flash-1017 model card via MindStudio; vals.ai and OpenRouter pricing; OpenAI GPT-5.6 announcement and ChatGPT/Codex changelog (GPT-5.5 retirement Oct 14, 2026); Anthropic Claude Opus 5.5 announcement and Claude Code docs; SWE-bench Pro leaderboard; Morph codex-vs-claude-code and opencode-vs-claude-code comparisons (Oct 2026); getdx AI coding assistant pricing guide. Facts verified 2026-10-18. Plugin breakage reports are community signal, not a survey.