OpenCode 2.0 is a major overhaul. It draws on millions of daily users' experience to deliver a system that can flex to everything an agent needs to be. There are quite a lot of new features, performance improvements, and bug fixes but here are some of the more impactful user-facing changes.
The Service
From the beginning OpenCode adopted a client/server model. However, this was not something it took advantage of by default and was mostly used by power users.
In 2.0 this server now automatically runs as a single background process on your machine. When you open up a TUI, the web interface or the desktop app they're all talking to the same central process.
If you're using the programmatic client @opencode/client to make your own scripts, they will autodiscover the local service and just work. This is particularly useful for scheduled tasks. You can also call it via CLI by using opencode api commands.
You can expose it to other hosts and run /pair or opencode pair to connect it to other applications. We have native apps in the works that take advantage of this flow.
The API
The old API grew haphazardly as we and the world collectively learned what agents are and should be. It was bad.
We started from scratch and examined all the weird use cases across the millions of users who use OpenCode every day. It now supports nearly anything you need to be able to do.
OpenCode is also aware of its own API and will call it to do useful things like moving the current session into a git worktree when starting new work.
We've also shipped a new client package @opencode/client that contains clients for vanilla JavaScript as well as Effect.
Code Mode
The models love to write code and OpenCode 2.0 takes advantage of that more than any other coding agent. We've built a minimal JavaScript interpreter in the @opencode/codemode package.
This package ingests MCP servers or OpenAPI endpoints, converting them into functions that the agent can call in a script. It can run these scripts natively without the complexity of Node.js VMs or embedding complicated solutions like QuickJS.
This lets your agent write scripts that can do things like call a tool, map over the results and call another tool. Single round trip instead of calling them one at a time.
All MCP servers in 2.0 are opted into codemode by default. This means you can add a thousand of them with minimal context bloat and your agent will discover and compose them to get things done.
Background Tasks
The latest batch of models are incredibly good at orchestration and it is important for harnesses to let them express the full extent of that capability.
First, we've added background subagents. This allows the primary agent to kick off some work to another one while it continues.
This happens automatically but you can also trigger it manually - even with a different model. It lets you do things like “spawn a background fable subagent to review this code” while you keep prompting.
Second, we've added background shell commands. The shell tool can be invoked asynchronously so long-running work does not have to block the primary agent. It'll be notified when things are complete.
If any foreground shell command or subagent takes longer than you expect, you can hit a hotkey to move them to the background so you can keep prompting.
Plugins
Although OpenCode 1.0 had a plugin system, it never got the attention it needed. To correct that, we forced ourselves to implement nearly every OpenCode 2.0 feature as an internal plugin and there are now 80+ of them. This guarantees that the Plugin API stays well maintained.
We've also promoted TUI plugins from experimental to stable. Since it is all powered by OpenTUI, you can build nearly anything. Here is an example of something useless.
We also spent quite a lot of time ensuring everything in OpenCode 2.0 can be hot-reloaded. So it can write a plugin for itself mid-session and use it right away - we covered the design of this in a previous blogpost.
The SDK
OpenCode can also now be used as a library with the @opencode/sdk package. This is the exact same code that powers our CLI.
This means you can strip it down and make your own flavor of OpenCode that runs on a server or in specialized environments like Durable Objects. And then you can connect to it from any OpenCode client since it speaks the standard OpenCode server protocol.
It also has an optional Effect-based API.
Upgrading
To upgrade the CLI, make sure you're on the latest 1.x release, then run opencode upgrade --major.
There are some breaking changes.
1.0 plugins will not work in 2.0
Server API is completely different
tui.json config is moved to json