OpenCode 2.0 is the kind of "2.0" that quietly breaks your muscle memory. The headline changes are an auto-running background server, a rewritten API, a JavaScript "Code Mode" that lets the agent compose MCP tools in a single round trip, and background subagents. Here is what I actually think about, and what breaks on upgrade.
The server now runs by itself
OpenCode always used a client/server model, but only power users touched it. In 2.0 the server starts automatically as a single background process, and the TUI, web interface and desktop app all talk to that same process. The @opencode/client package now autodiscovers the local service, so scheduled scripts and cron-style jobs just connect and work. You can also drive it with opencode api CLI commands, or expose it to other hosts and run /pair (or opencode pair) to link it to other applications — the team says native apps are in the works around that flow.
The practical consequence: OpenCode stops being a thing you launch per-session and starts being a daemon you can reach from anywhere on the machine. I would reach for the @opencode/client package when I want to script a nightly review job rather than babysit a TUI.
Code Mode turns MCP servers into scriptable functions
This is the part I care about. @opencode/codemode is a minimal JavaScript interpreter that ingests MCP servers or OpenAPI endpoints and converts them into functions the agent can call inside a script. It runs those scripts natively — no NodeJS VMs, no QuickJS embedding, per the source. So instead of an agent calling list_issues then save_issue then save_issue in three separate round trips, it writes one script that maps over the results and returns the identifiers.
Every MCP server in 2.0 is opted into Code Mode by default. The stated payoff is context: you can add a thousand of them with minimal context bloat, and the agent discovers and composes them. That is a real answer to the MCP context-bloat problem I have been chewing on — the tool list used to eat the whole context window before the model could think.
Background subagents and async shell
2.0 adds background subagents: the primary agent can kick work to a second agent (even a different model) and keep prompting. You can trigger it manually — "spawn a background fable subagent to review this code" — while the foreground keeps going. Background shell commands work the same way: the shell tool runs asynchronously, so a long bun test or build does not block you, and the agent is notified when it finishes. A hotkey (ctrl b in the example) moves a running foreground command or subagent to the background so you can keep typing.
For long agentic sessions this is the difference between a tool that nags you and one that keeps moving. I would watch whether background subagents stay honest about when their work is actually done — that has been the weak spot in orchestration claims before.
What breaks on upgrade
Three things are breaking, and they are not subtle:
| Change | 1.x behavior | 2.0 behavior |
|---|---|---|
| Plugins | 1.0 plugin system | 1.0 plugins will not work |
| Server API | Old, "grew haphazardly" API | Completely different, rewritten from scratch |
| TUI config | tui.json |
moved to json |
The rest is backwards compatible. To upgrade, be on the latest 1.x release and run opencode upgrade --major; the desktop app is a separate download.
Two things worth saying out loud before you hit that command. First, the plugin system got real attention: the team implemented nearly every 2.0 feature as an internal plugin — 80+ of them — to keep the Plugin API maintained, and TUI plugins are now stable, powered by OpenTUI. Second, everything hot-reloads, so the agent can write a plugin for itself mid-session and use it immediately. That is a genuine capability, but it also means the blast radius of a confused agent writing a bad plugin is your running session.
The SDK, if you want your own flavor
@opencode/sdk exposes the exact code that powers the CLI as a library. You can strip it down and run your own OpenCode on a server or in specialized environments like Durable Objects, then connect any OpenCode client to it since it speaks the standard server protocol. There is an optional Effect-based API, still in development but usable. The catch is the same as any young SDK: things are shifting, so pin it and expect churn.
My read: 2.0 is a bet that the agent is the runtime, not the model. Code Mode, background subagents and the always-on server all push toward "the agent orchestrates the machine." If you are scripting OpenCode into a pipeline, plan on rewriting your plugin layer and API calls — this is not a drop-in patch.
Sources: