OpenCode 2.0 can now be started, found and steered by other software without a person at the keyboard, according to the project’s own release notes on anoma.ly. That moves the coding assistant from a terminal program toward a service that your scripts, apps and scheduled jobs call.
The change begins with the server. OpenCode has always been split into a client and a server, but the notes say only its most advanced users ever relied on that design. In 2.0 the server runs by default as a single background process, and the terminal interface, the web interface and the desktop app all talk to it. Open any of them and you are looking at the same running instance.
Scripts get the same access. The @opencode/client package finds the local service by itself, so a script “just works,” in the notes’ words, which the project calls particularly useful for scheduled tasks. A command-line route, opencode api, does the same job from a shell. A pairing command, /pair or opencode pair, exposes the service to other machines, and the project says native apps built on that flow are in the works.
Underneath sits a rewritten API. The notes describe the old one as having grown haphazardly and say, bluntly, “It was bad.” The replacement was designed from the use cases of what the project calls millions of daily users, a figure the notes do not support with data. The example in the notes is short: a script asks the client to create a session in a directory, then sends it the prompt “Review the current changes.” The client package ships in a plain JavaScript flavor and one for Effect, a TypeScript library. OpenCode also knows its own API, and the notes say it calls that API itself for housekeeping, for example relocating a session to a separate git worktree before new work begins.
The third piece is the SDK. The @opencode/sdk package lets developers use OpenCode as a library, and the notes say the command-line tool is built on identical code. You can strip it down into your own variant that runs on a server or in constrained environments such as Durable Objects, and any standard OpenCode client can still connect to it because it speaks the same server protocol. An optional Effect-based interface exists but is still in development.
Several other changes ride along. A new @opencode/codemode package converts MCP servers or OpenAPI endpoints into functions the agent calls from a script, so a single script can chain several tool calls, feeding one result into the next, and finish in one round trip instead of many. Every MCP server is opted into this by default, which the project says lets you add a thousand of them with little context bloat. Background subagents and background shell commands let the main agent keep working while slow jobs run, and a hotkey pushes a slow foreground job into the background. The project says it rebuilt nearly every feature as an internal plugin (80+ of them), promoted terminal-interface plugins from experimental to stable, and made everything hot-reloadable. Those are the project’s claims; the notes publish no tests behind them.
Two things the notes leave open matter to anyone planning to self-host. They never state a licence, so confirm it in the repository before you build on it. And the notes promise “performance improvements” without a single measurement, so treat speed as unproven.
The breaking changes are short but real. Plugins written for 1.0 will not work in 2.0, the server API is completely different, and the notes say the tui.json config “is moved to json,” a line that is unclear as written. To upgrade, move to the latest 1.x release and run opencode upgrade --major. Desktop users download the new app. The notes suggest pointing OpenCode at its own migration doc to convert backwards-compatible settings.
Any team with 1.0 plugins or scripts written against the old server API now has a rewrite on its calendar, and staying on the last 1.x release until those are ported is the cheaper way to find out how big it is.
Based on OpenCode’s release notes published on anoma.ly on 12 October 2026.
