OpenCode 2.0 Turns the Coding Agent Into a Service

Most coding agents are programs you launch. You open a terminal, start a session, and when the window closes, the agent's world closes with it.

OpenCode 2.0 changes that model. The agent becomes a background service that your terminal, browser, desktop app, and scripts can all use. The rebuilt API, background subagents, and hot-reloadable plugins follow from that central idea.

Anomaly, the company behind the open-source project, published its formal 2.0 announcement on October 12, around three months after the public beta opened in July. Here is what changed, what to watch out for, and who should upgrade now versus wait.

A rollout that took its time

OpenCode 2.0 did not arrive on one launch day. The public beta opened in July, Anomaly published an engineering post about its plugin architecture in September, and the formal announcement followed on October 12. Developers also questioned V2's stability and complained about missing release notes, as The New Stack reported.

Version 1.19.0, released October 11, added opencode upgrade --major and /update as paths to V2. Its notes say updates are no longer installed automatically, so users must choose when to update.

The big idea: an agent you don't launch

OpenCode had a client/server split before, but mostly for power users. In 2.0, one background server starts automatically and the terminal, web, and desktop clients connect to it.

flowchart LR
  TUI[Terminal] --> S[OpenCode service]
  WEB[Web app] --> S
  DESK[Desktop app] --> S
  SCR[Your scripts] --> S
  PAIR[Paired apps] --> S
  S --> MOD[Model providers]
  S --> EXT[Tools, MCP servers, plugins]
  S --> BG[Background subagents and shell commands]

Start a session in the terminal and pick it up in the desktop app or browser. Scripts using @opencode/client discover the local service, and opencode api reaches it from the shell. You can expose it to other hosts and connect applications with /pair or opencode pair; Anomaly says native apps using this flow are in development. It is similar to tmux, where work outlives the terminal window.

A persistent service has a larger exposure surface than a process that ends with the terminal. The v1.19.0 notes include a fix for validating PTY connection origins and tickets. Before exposing the service beyond your machine, restrict network access, review pairing behavior, and test client and tool permissions.

An API the agent can use on itself

Anomaly's description of the old API was blunt: “It was bad.” It had grown piecemeal as the team learned what agents needed, so the developers started over.

OpenCode can now use its own API. In Anomaly's examples, the agent creates a Git worktree for a task, moves the session into it, and can list sessions, inspect a stuck session, interrupt it, or send new instructions. Developers can use vanilla JavaScript or Effect-based clients through @opencode/client; see the API reference.

Code Mode: scripts instead of tool-call ping-pong

Traditional tool use loops between model, tool, and result. Each step adds a round trip, and connected tool definitions consume context-window space.

Code Mode changes the unit of work. The @opencode/codemode package converts MCP servers and OpenAPI endpoints into functions under a tools object. The agent can write one script to call a tool, filter results, and call another. This illustrative example uses hypothetical server and tool names.

// Summarize noisy production errors for the on-call channel
const { issues } = await tools.sentry.list_issues({
  project: "web-app",
  status: "unresolved",
  limit: 20,
})

const noisy = issues.filter(issue => issue.count > 100)

await tools.slack.post_message({
  channel: "#oncall",
  text: noisy.map(issue => `${issue.title}: ${issue.count} events`).join("\n"),
})

return noisy.map(issue => issue.id)

As separate tool calls, this takes at least two model round trips, with the issue list passing through context. As a script, only the returned IDs need to come back.

Code Mode is enabled by default for MCP servers. Anomaly says developers can connect a thousand with minimal context bloat because the agent discovers and composes tools as needed. Servers can opt out with codemode: false. The interpreter runs natively without a Node.js VM or an engine such as QuickJS.

I think this is the right bet if models are better at writing small programs than juggling tool schemas. The trade-off is transparency: a multi-action script is harder to inspect than separate calls. Tools can be denied by normalized <server>_<tool> names, and session calls carry a session ID in request metadata. The docs I reviewed do not fully explain how permissions apply when one script fans out into several calls, so test this before using it with production systems.

Background work

OpenCode 2.0 adds two kinds of concurrency. Background subagents take on work while the primary agent continues, and can use a different model. Background shell commands run tests or builds asynchronously, with OpenCode reporting when they finish. Ctrl+B can move a slow foreground task to the background.

Two things need attention. Parallel work can create conflicting edits in one working tree, so separate worktrees seem sensible, although that is my inference rather than a documented workflow. Also, each child agent uses its own configured permissions. A parent's subagent rules determine which agents it can launch, but do not assume the child inherits the parent's limits.

Plugins that can rewrite the running agent

Anomaly says V1's plugin system did not get enough attention. In 2.0, more than 80 internal plugins power much of the product. TUI plugins, built on OpenTUI, are now stable. Hot reload lets OpenCode change its configuration, connect an MCP server, or write a plugin and use it in the same turn, without restarting.

The design, explained in Anomaly's September post, fixes a subtle problem: when plugins mutate a shared registry, outcomes can depend on how often they run and in what order. Anomaly describes a catalog refresh undoing a policy plugin's disabled flags and a plugin repeatedly halving an output limit on reload.

The solution is to stop letting plugins mutate shared state directly. Each plugin registers a transformation. When something changes, OpenCode rebuilds the state from an empty starting point and replays the transformations in order, exactly once.

flowchart LR
  E[Empty state] --> A[Plugin A transform]
  A --> B[Plugin B transform]
  B --> C[Plugin C transform]
  C --> R[Published result]
  RL[Reload called] -.-> E

This prevents refreshes from undoing policies, removes providers that disappear upstream, and avoids applying the same change repeatedly. The same State abstraction underpins skills, commands, agents, tools, MCP servers, and formatters. Removing a plugin removes what it registered. For developers, deterministic rebuilds make a self-modifying agent easier to reason about and trust.

The SDK: OpenCode as a library

The @opencode/sdk package exposes the same code that powers the CLI as a library. Developers can adapt it to run their own version of the agent on a server or in environments such as Cloudflare Durable Objects. OpenCode clients can connect through the standard server protocol, and an Effect-based API is also available. The SDK is still early; check the SDK documentation before depending on it.

For example, an internal developer portal could launch code-review sessions without rebuilding the agent runtime. That is an inference from the SDK's stated capabilities, not an official demo. A shared service and embeddable core could turn OpenCode from an app into a platform.

What it breaks

The migration guide lists three intentional breaking changes. Other supported V1 functionality is meant to keep working, and regressions are treated as compatibility bugs.

V2 reads V1 configuration from the same locations and normalizes supported settings in memory without rewriting source files. You can try it before converting formats. Permissions change from a per-tool map to an ordered array, where the last matching rule wins.

// V1
{
  "permission": {
    "bash": { "npm publish *": "deny" },
    "edit": "allow"
  }
}

// V2
{
  "permissions": [
    { "action": "shell", "resource": "npm publish *", "effect": "deny" },
    { "action": "edit", "resource": "*", "effect": "allow" }
  ]
}

The quiet changes

• No LSP diagnostics. V2 accepts lsp configuration but does not run language servers, expose LSP tools, or provide LSP diagnostics. Replace workflows that rely on them with lint, typecheck, or compiler commands.

• AGENTS.md only. V2 does not use CLAUDE.md as a fallback. Move relevant instructions into AGENTS.md if you relied on that behavior.

• No session sharing yet. The share setting is accepted, but session sharing is not supported yet.

• One command, one version by default. Current migration docs say V1 and V2 both use opencode and are no longer installed side by side by default. The V2 curl installer replaces the V1 binary. Some older beta-era guides still describe a separate opencode2 command, so check that the instructions you follow match the current docs.

The migration guide recommends asking OpenCode to migrate the configuration while preserving existing behavior. You do not need to convert everything before trying V2.

Upgrade now, or wait?

Upgrade now if you want a single session to follow you across terminal, desktop, and web; you script against the agent or run it unattended; or you connect many MCP servers and want to reduce their context cost.

Wait if you depend on V1 plugins, integrations that call the old server API, LSP diagnostics, or a CLAUDE.md fallback.

The ecosystem is already dividing along that line. The vimcode plugin has experimental V2 support, recommends an older release for V1 users, and plans to focus future maintenance on V2. An unofficial .NET SDK also targets 2.x servers.

If you decide to upgrade:

1. Back up your V1 configuration and keep a way to reinstall the version you use today. Do not assume V1 and V2 can be installed side by side.

2. From V1.19.0, run opencode upgrade --major or use /update. Desktop users can get the current build from opencode.ai/download.

3. Verify models, credentials, agents, permissions, MCP servers, and plugins in a real project before relying on V2.

4. Port plugins and API integrations. Convert configuration to the native V2 format only if and when you need to.

The bigger picture

The harness is also where the fight over model choice and control is playing out. In January 2026, Anthropic introduced safeguards against third-party tools impersonating Claude Code with consumer subscription credentials. VentureBeat reported that the restrictions disrupted some OpenCode users. The New Stack said this coincided with increased interest in OpenCode, where developers can switch model providers.

In July, Anaconda acquired Kilo, another open-source coding agent that had already rebuilt its CLI and VS Code extension on OpenCode. A shared service and embeddable SDK make this kind of reuse a first-class design goal rather than an accidental side effect.

Verdict

OpenCode 2.0 is a rearchitecture, not just a feature drop. The shared service is a strong foundation, and Code Mode and hot-reloadable plugins look most likely to age well. The main rough edges are the drawn-out rollout and the removal of LSP diagnostics, which is easy to miss in the migration guide.

Back up your V1 setup, test V2 on a real project, and migrate plugins and integrations at your own pace. Do not assume the versions can run side by side, and verify permissions before exposing the service or connecting production tools.

Sources and a note on method

This article draws on Anomaly's OpenCode 2.0 and OpenCode Reloaded posts; the V2 migration, configuration, agents, and MCP server docs; the v1.19.0 release notes; and The New Stack's coverage. Migration details were checked against the live V2 documentation on October 15, 2026; older beta guides may describe earlier behavior. I found no benchmarks in the sources reviewed, so this article focuses on architecture and migration. Feature descriptions reflect Anomaly's claims unless marked as analysis or inference. The project is at github.com/anomalyco/opencode.