OpenCode 2.0: One Shared Service for Coding Agents

At 5:30 p.m., a coding agent is running tests in your terminal while a browser tab holds a plan for the same repository. In many tools, those windows behave like separate rooms: sessions drift apart, plugins load twice, and a script has to guess which process owns the work. OpenCode 2.0 takes a more deliberate route. It puts one local service in the middle, then lets the terminal, web, desktop app, and your own programs share it.

What changed in OpenCode 2.0?

The headline feature is not a new button or a flashier chat panel. It is a change in ownership. OpenCode 2.0 gives one background process responsibility for sessions, permissions, plugins, and the state behind your work. The interfaces become clients: different ways to look at and control the same system.

One local service instead of scattered sessions

OpenCode uses a client/server model. The server is the long-running process that owns the work; a client is an interface that sends it requests. In practical terms, the terminal client, web interface, and desktop app can all connect to the same service.

A terminal user interface, or TUI, is a text-based application that runs inside your terminal. It may look separate from the web or desktop versions, but in OpenCode 2.0 those clients can see the same sessions and ongoing tasks.

terminal client ─┐
web client ├──> OpenCode service
 desktop client ┘ ├── sessions
 ├── permissions
 └── plugins

That shared process also gives scripts a stable place to connect. The @opencode/client package can discover or start the local service before creating a session:

import { OpenCode } from '@opencode/client'
import { Service } from '@opencode/client/service'

const endpoint = await Service.ensure
const client = OpenCode.make({
 baseUrl: endpoint.url,
 headers: Service.headers(endpoint),
})

const session = await client.session.create({
 location: { directory: process.cwd },
})

await client.session.prompt({
 sessionID: session.id,
 text: 'Review the current changes',
})

Service.ensure means the script does not need to know whether the service is already running. That matters for scheduled jobs, automation, and small internal tools. When OpenCode needs to run on another machine, the same architecture can support a standalone server and remote clients.

An API built around real agent work

An API, short for application programming interface, is a collection of named operations that software can call. OpenCode 2.0 rebuilds its API around the things people actually do with coding agents: create sessions, inspect context, interrupt stuck work, move a session, manage tabs, and create Git worktrees.

A Git worktree is a separate working directory connected to the same repository. It lets you work on another branch without disturbing the files in your current checkout. That makes a request such as “start this feature in a new worktree” more than a conversational promise. The agent can create the worktree, rename the session, and move the work there through its own API.

This is an important shift. The agent is not limited to editing files inside one conversation. It can operate the workspace around that conversation too.

Code Mode turns tool calls into small programs

OpenCode 2.0 also changes how an agent works with external services. MCP, the Model Context Protocol, is a standard way to expose tools and data sources to an AI application. OpenAPI is a related format for describing HTTP APIs. Code Mode can ingest either kind of interface and present the available actions as functions inside a small JavaScript interpreter.

Instead of calling a GitHub tool, waiting for the result, then asking the model to decide what to do next, the agent can write a short script:

const { issues } = await tools.github.list_issues({
 owner: 'anomalyco',
 repo: 'opencode',
 labels: ['bug'],
 state: 'OPEN',
})

const filed = await Promise.all(
 issues.map(({ title }) =>
 tools.linear.save_issue({ team: 'OC', title })
 )
)

return filed.map(issue => issue.identifier)

The example finds open GitHub bugs and creates matching Linear issues. Promise.all lets several independent requests run together, while await pauses each step until its result is ready. More importantly, the agent can compose tools in one script instead of turning every handoff into another model round trip.

That reduces the amount of tool description placed in the model’s context, meaning the information the model must keep in view. In OpenCode 2.0, MCP servers use Code Mode by default, so a large collection of tools does not have to crowd the main conversation.

Background work keeps the main session moving

A subagent is a separate agent session given a focused task. OpenCode 2.0 can send a code review to a background subagent while the primary session continues with another request. The same idea applies to shell commands such as test suites, builds, and formatters.

The interaction feels closer to handing work to a colleague than waiting beside a frozen terminal. You can ask for a background review, continue editing, and receive the result when it finishes. If a foreground task runs longer than expected, Ctrl+B moves it into the background.

This matters because coding work rarely arrives in one neat sequence. Tests run while documentation changes. A review happens while a second bug is being investigated. OpenCode’s task model is finally shaped around that reality.

Plugins become part of the foundation

A plugin is an extension that adds behavior to an application. In OpenCode 2.0, many built-in capabilities are implemented through the same plugin system available to users. That forces the plugin interface to stay close to the real application instead of becoming a neglected side door.

A small plugin can look like this:

import { Plugin } from '@opencode/plugin'

export default Plugin.define({
 id: 'review-helper',
 async setup(ctx) {
 await ctx.storage.set('loaded', true)
 },
})

OpenCode can load local or published plugins, and changes can be hot-reloaded. Hot reload means the running application notices a code change and applies it without a full restart. In the right workflow, an agent can create an extension during a session and use it almost immediately. Terminal UI plugins have also moved from experimental territory into the supported extension model.

The SDK makes OpenCode embeddable

The software development kit, or SDK, is the library version of OpenCode. The network client connects to a running server, while @opencode/sdk can host OpenCode inside another application.

import { OpenCode } from '@opencode/sdk'

await using opencode = await OpenCode.create

const session = await opencode.sessions.create({
 location: { directory: '/workspace' },
})

await opencode.sessions.prompt({
 sessionID: session.id,
 text: 'Review the current changes',
})

This embedded form routes requests in memory rather than adding another network hop. It opens the door to custom server applications, automation services, and specialized runtimes without rebuilding the agent from scratch.

The upgrade does require attention. OpenCode 2.0 introduces a new plugin API, new server and client contracts, and a move from older tui.json configuration files to a global cli.json file. Existing project definitions are intended to remain compatible, but V1 plugins will not work unchanged. For the command-line installation, the documented path is to update to the latest 1.x release first, then run opencode upgrade --major.

OpenCode 2.0 is best understood as an architectural reset. One service keeps every interface synchronized, Code Mode lets agents compose tools through scripts, background work supports parallel tasks, and plugins plus the SDK make the whole system easier to reshape. The result feels less like a chat window attached to a repository and more like a programmable workspace that happens to speak natural language.