OpenCode 2.0: what the open coding agent's biggest rewrite changes for local AI

Anomaly has shipped OpenCode 2.0. The company calls it a major overhaul, built on the experience of millions of daily users: a system that can flex to everything a coding agent needs to be. There are new features, performance work and plenty of bug fixes, but the user-facing changes are more structural than cosmetic. OpenCode is no longer just a terminal program that talks to a model. It is a service, an API, an SDK and a plugin platform at once.

For anyone running models locally that shift matters more than the release notes suggest. Most of what 2.0 adds addresses the same bottlenecks local AI users hit every day: scarce context, one GPU that cannot do two things at once and a harness that has to adapt to models it does not control.

One background service, many clients

OpenCode has used a client/server model since the beginning, but 1.x rarely took advantage of it. In 2.0 the server now runs automatically as a single background process on your machine. Whether you open the TUI, the web interface or the desktop app, they all talk to the same central process. Sessions live in one place instead of being duplicated per client.

That has an immediate practical consequence for scripts. If you use the programmatic client @opencode/client, it will autodiscover the local service and just work. Scheduled tasks, cron jobs, CI hooks and small automation scripts can drive the same agent you use interactively, without managing a server yourself. You can also call it from the CLI with the opencode api commands.

The service can be exposed to other hosts and paired through /pair or opencode pair. Anomaly says native apps taking advantage of this flow are in the works. For a local setup the appeal is obvious: the machine with the GPU runs the model and the service, while a lighter laptop drives it over the network.

An API OpenCode can call itself

Anomaly is blunt about the old API: it grew haphazardly and it was bad. Version 2.0 starts from scratch. The new API is designed around the weird cases found across millions of users and covers nearly anything an agent needs to do.

The more interesting part is that OpenCode is now aware of its own API and calls it to do useful things. The announcement shows it moving a session into a git worktree when starting new work, listing and inspecting sessions, interrupting a stuck run, renaming a session or closing a tab. Agent management becomes an agent capability rather than hard-wired UI logic. That is a cleaner architecture and a good sign for anyone building on top of it.

Code mode: fewer round trips, less context

Code mode is the feature most likely to matter for local models. OpenCode 2.0 includes @opencode/codemode, a minimal JavaScript interpreter. It ingests MCP servers or OpenAPI endpoints, converts them into functions the agent can call inside a script and runs those scripts natively, without a Node.js VM or a heavyweight embedded engine such as QuickJS.

Instead of calling one tool at a time, the agent can write a short program: call a tool, map over the results and call another tool in a single round trip. That is faster, but it is also much cheaper in context, because the agent no longer has to paste every intermediate result back into the conversation.

All MCP servers are opted into code mode by default in 2.0. Anomaly argues you can add a thousand of them with minimal context bloat and the agent will discover and compose them as needed. On a local model with a 32K window that is not a luxury. Tool definitions alone can eat 30 to 50% of the context on a heavily equipped setup, as we explain in our MCP guide. Deferring discovery until the script needs a tool changes the budget entirely.

There is a caveat worth stating. Code mode trades tool-call turns for generated JavaScript. Models that reliably emit valid JSON tool calls are not automatically good at writing correct multi-step scripts. With a smaller local model, test this path before assuming it is a win.

Background subagents and shell commands

The latest models are good at orchestration and harnesses need to let them express it. OpenCode 2.0 adds two ways to work asynchronously.

First, background subagents. The primary agent can hand work to another agent while it continues, automatically or on request, even with a different model. The announcement's example is spawning a background subagent to review code while you keep prompting.

Second, background shell commands. The shell tool can be invoked asynchronously so long-running work does not block the primary agent, which is notified when things complete. If a foreground command or subagent takes longer than expected, a hotkey moves it to the background.

On a single local GPU this is useful but not magic: inference is still serialised and two agents running at once will contend for the same VRAM. The real win is organisational. You can keep a long build or test run going while you prompt and you can let a cheap local model handle a background review while a larger one stays on the main task, provided both fit in memory. On one card, a smaller model for the subagent is the sane default.

Plugins become the architecture

OpenCode 1.0 had a plugin system, but it never got the attention it needed. To fix that, Anomaly forced itself to implement nearly every 2.0 feature as an internal plugin. There are now more than 80 of them. That guarantees the plugin API stays well maintained, because the product itself depends on it.

TUI plugins are promoted from experimental to stable, powered by OpenTUI. Anomaly also spent a lot of time making everything hot-reloadable, so OpenCode can write a plugin for itself mid-session and use it immediately. The design is covered in its previous post on reloading.

For local AI this is more relevant than it sounds. The harness is where most of the adaptation happens when you switch models: prompt formats, tool-call parsers, context handling, provider quirks. A maintained plugin API with hot reload means you can patch those behaviours without forking the agent. If the docs are not enough, you can simply ask OpenCode to build the plugin.

The SDK: your own flavor of OpenCode

OpenCode can now be used as a library through @opencode/sdk. It is the exact same code that powers the CLI. In principle you can strip it down and make your own flavor of OpenCode that runs on a server or in specialised environments, then connect to it from any OpenCode client because it speaks the standard server protocol. An optional Effect-based API is part of the package and still in development.

This is the piece that turns OpenCode from an application into infrastructure. A local assistant backed by your own model, an internal coding service on a workstation or a scheduled maintenance agent that speaks the same protocol are all reasonable projects now.

What it changes for local AI

OpenCode 2.0 was not built specifically for local models, but several design choices line up with the constraints of running them:

• One service instead of many processes. A single long-lived agent on the machine that owns the model and the sessions is easier to schedule, monitor and pair with other devices.
• Context is treated as a budget. Code mode defers tool discovery and collapses multi-step calls into one script, which is exactly what a 32K or 64K local window needs. Context sizing rules still apply, as our Ollama guide and coding model guide describe.
• Asynchrony fits heterogeneous hardware. A background subagent can run a smaller local model while the main agent uses a larger one and long shell jobs no longer freeze the session.
• The harness can be extended safely. A plugin-first architecture is how you adapt a fast-moving open agent to the quirks of open-weight models.

The honest limit is unchanged: the model still has to call tools correctly. A frontier model makes code mode look effortless; a 7B model may not. OpenCode 2.0 gives a good local model a better harness, not a better brain.

Upgrading and breaking changes

To upgrade the CLI, make sure you are on the latest 1.x release, then run:

opencode upgrade --major

The desktop app is a separate download from opencode.ai/download. There are real breaking changes:

• 1.0 plugins will not work in 2.0.
• The server API is completely different.
• The tui.json config moves to a JSON format.

Most other changes are backwards compatible, but backing up your configuration and plugins before switching is sensible. Anomaly recommends pointing OpenCode at the migration guide so it can migrate things for you. Since the agent can now modify its own setup, keeping a known-good config copy is cheap insurance.

Sources

• Anomaly website — the company behind OpenCode
• OpenCode 2.0 announcement — Anomaly, October 2026
• Plugins documentation — OpenCode 2.0 docs
• SDK documentation — OpenCode 2.0 docs
• Migrate from 1.x — OpenCode 2.0 migration guide
• OpenCode download — desktop app