OpenCode 2.0 shipped this week, and it is not a version bump. The open source coding agent, which sits at 213,000 stars on GitHub, rebuilt its server API from scratch, made its background service a first-class citizen, and folded almost everything into a plugin system. The upgrade path includes real breaking changes. If you script against OpenCode, budget migration time.
The service model is the headline
OpenCode has had a client/server architecture since the start, but most people ignored it. In 2.0 the server runs automatically as a single background process, and every client, whether that is the TUI, the web interface, the desktop app, or your own scripts, talks to the same central process. The programmatic client, @opencode/client, autodiscovers the local service, and there is a new opencode api command group plus a pairing flow for connecting the service to other applications.
This is the change I find most interesting, because it quietly redefines what the tool is. A shared server means one session state across every surface. The session you started in the terminal is the session your web dashboard shows and the session a cron job can resume. For anyone running agents on schedules or in CI, that is a genuine platform feature rather than a convenience, and it is the kind of architecture other agent harnesses will end up copying.
The agent itself now knows its own API too. The release notes show it calling the API to move a session into a fresh git worktree before starting new work, interrupt a stuck session, prompt it to quarantine a failing test, and close finished tabs. Agents managing other agents is still slightly weird to watch, but it is the useful kind of weird.
Code Mode is the boldest bet
The new @opencode/codemode package takes a stance on how agents should use tools: let the model write code instead of calling tools one at a time. It ingests MCP servers or OpenAPI endpoints and turns them into callable functions in a minimal JavaScript interpreter. Given a task that touches GitHub and Linear, the agent writes one script that lists the issues, fans out the Linear ticket creation with Promise.all, and returns the identifiers. One round trip instead of a dozen tool calls.
The thesis is that models write better code than they sequence tool calls, and the release makes Code Mode the default for MCP servers. I think they are right about the failure mode. Sequential tool calling burns context on intermediate results and gives the model a dozen chances to lose the plot. A script keeps the logic in one artifact you can read. The cost is a new class of bug: the agent’s script can be wrong in ways a single tool call rarely is, so the interpreter having a small surface area matters more than it sounds.
Plugins, and eating your own dog food
Nearly every feature in 2.0 ships as an internal plugin, more than 80 of them, with a stable API for TUI plugins built on OpenTUI and hot reload so you can write one mid-session. This is the strongest way to keep a plugin API honest. If the maintainers build the product out of the same plugins users write, the API rot that kills most plugin systems has nowhere to hide.
The other extensibility story is the SDK. @opencode/sdk exposes the same core that powers the CLI, so you can strip it down and run your own flavor of OpenCode on a server, or somewhere exotic like Cloudflare Durable Objects, and connect to it with any standard OpenCode client because it speaks the same server protocol. An Effect-based API variant is in development.
The catch: real breaking changes
Three things do not survive the upgrade. Version 1 plugins are dead. The server API is completely different, so anything you built against it needs rework. The TUI configuration file moved, and the rest of the config changes are backward compatible but worth reviewing. The upgrade itself is opencode upgrade --major from the latest 1.x release, and the migration guide lives at opencode.ai if you would rather have OpenCode migrate its own config.
The launch discussion on Hacker News included reports of upgrade friction, which tracks with a release this invasive. My advice would be to read the migration guide before running the upgrade command, and if you have production scripts against the old server API, keep a 1.x binary pinned until the port is done. Day-one upgrades of a rebuilt API are how weekends get consumed.
What it means beyond this project
Three directions in 2.0 look like the shape of things to come for agent tooling generally. A shared background service with autodiscovery, so agents behave like daemons instead of terminal sessions. Tool access composed as model-written code, cutting round trips and context bloat. And a plugin API maintained by dogfooding. None of these ideas are new, but a project with this many users shipping all three at once, as defaults, is a signal worth reading.
For developers, the practical read is simpler: OpenCode 2.0 is a mature platform now, not just a CLI. If you have been embedding agents into scripts and services with homegrown glue, the client and SDK packages exist precisely for that. Just read the migration guide first.