OpenCode 2.0 adds a background server, code mode and an SDK

OpenCode 2.0 adds a background server, code mode and an SDK

The OpenCode team has announced OpenCode 2.0, which it describes as a major overhaul of its coding agent, built on the experience of what the post calls millions of daily users. The post lists the changes it considers most impactful for users.

The service. OpenCode has had a client/server model from the start, but it was mostly used by power users rather than by default. In 2.0 the server runs automatically as a single background process on the user's machine. The TUI, the web interface and the desktop app all talk to that same central process. Scripts written with the programmatic client @opencode/client autodiscover the local service and work without setup, which the post says is useful for scheduled tasks. The service can also be called from the command line with opencode api commands, and it can be exposed to other hosts with /pair or opencode pair. The team says native apps that use this flow are in the works.

The API. The authors say the old API grew haphazardly while they and the wider world learned what agents are and should be, and call it bad. They rewrote it from scratch after examining unusual use cases across their users. OpenCode is aware of its own API and calls it to do things such as moving the current session into a git worktree when new work starts. A new package, @opencode/client, ships clients for vanilla JavaScript and for Effect.

Code mode. The @opencode/codemode package is a minimal JavaScript interpreter that takes MCP servers or OpenAPI endpoints and turns them into functions the agent can call from a script. It runs these scripts natively, without Node.js VMs or an embedded engine such as QuickJS. A script can call a tool, map over the results and call another tool in a single round trip instead of one call at a time. All MCP servers in 2.0 are opted into code mode by default, which the post says means you can add a thousand of them with minimal context bloat while the agent discovers and composes them.

Background tasks. Background subagents let the primary agent hand work to another agent and keep going. This happens automatically, but can be triggered by hand, even with a different model; the post's example prompt is "spawn a background fable subagent to review this code". Shell commands can also run asynchronously, so long-running work does not block the primary agent, which is notified when they finish. A hotkey moves any foreground shell command or subagent to the background so the user can keep prompting.

Plugins. The authors say the 1.0 plugin system never got the attention it needed. To fix that, they implemented nearly every 2.0 feature as an internal plugin, and there are now 80+ of them, which they say keeps the Plugin API well maintained. TUI plugins moved from experimental to stable, and since the TUI is powered by OpenTUI the post says nearly anything can be built. Everything in 2.0 can be hot-reloaded, so OpenCode can write a plugin for itself mid-session and use it at once.

The SDK. OpenCode can now be used as a library through @opencode/sdk, which the post says is the exact same code that powers the CLI. It can be stripped down into a custom flavor that runs on a server or in specialized environments such as Durable Objects, and any OpenCode client can connect to it because it speaks the standard OpenCode server protocol. An optional Effect-based API is included. The SDK is still in development as things are shifting, but can already be used.

Upgrading. To upgrade the CLI, be on the latest 1.x release and run opencode upgrade --major. The desktop app is upgraded by downloading the latest version. There are breaking changes: 1.0 plugins will not work in 2.0, the server API is completely different, and the tui.json config has moved. Other changes are backwards compatible, and the post suggests pointing OpenCode at its migration doc so it can migrate things for you.

Key facts

  • OpenCode 2.0 runs the server automatically as one background process on the user's machine; the TUI, web interface and desktop app all connect to it.
  • The API was rewritten from scratch, and a new @opencode/client package provides clients for vanilla JavaScript and Effect.
  • The @opencode/codemode package is a minimal JavaScript interpreter that turns MCP servers and OpenAPI endpoints into functions an agent can call in one script; all MCP servers are opted in by default.
  • Background subagents and background shell commands let the primary agent keep working; a hotkey moves foreground tasks to the background.
  • Breaking changes from 1.x: 1.0 plugins do not work, the server API is completely different, and the tui.json config has moved. Upgrade with opencode upgrade --major.

Why it matters

The release changes how OpenCode is built: a single local service that every interface shares, rather than a client/server split that mostly power users touched. On top of that the team adds a code mode that lets an agent compose many MCP servers or OpenAPI endpoints in a script, background subagents and shell commands, and a library form of the CLI. The post presents all of this as a response to how well current models write code and orchestrate work.

Who it affects

Existing OpenCode 1.x users, who face breaking changes when they upgrade. Plugin authors, whose 1.0 plugins will not work in 2.0. People who script against the server API, which is completely different. Developers who want to embed an agent: @opencode/client and @opencode/sdk are aimed at them, including those targeting servers or environments such as Durable Objects. Anyone who connects many MCP servers also feels the change, because they are all routed through code mode by default.

How to use it

To upgrade the CLI, get onto the latest 1.x release and run opencode upgrade --major. For the desktop app, download the latest version. Scripts built on @opencode/client autodiscover the local service, and the service can also be driven with opencode api commands. To connect other applications or hosts, use /pair or opencode pair. If a foreground shell command or subagent runs long, a hotkey moves it to the background. The post suggests pointing OpenCode at its migration doc so it can migrate your setup.

How solid is it

This is the OpenCode team's own announcement, so every claim is the team's description of its product. The post gives no benchmarks or measurements for the performance improvements it mentions, and the figure of millions of daily users is not broken down or sourced. The "80+" internal plugins and the "thousand MCP servers with minimal context bloat" are the authors' statements, not independent results. The SDK is described as still in development.

Risks and caveats

Upgrading is not seamless: 1.0 plugins stop working, the server API is completely different, and the tui.json config has moved. The SDK is still in development, and the post says things are shifting. The native apps built on the pairing flow are described only as in the works, with no timescale given. The post gives no pricing or licensing information and no release date, and it does not say which models are supported.

“spawn a background fable subagent to review this code”

— Example prompt in the OpenCode 2.0 announcement post