
News
OpenCode 2.0 puts every client on one local service
OpenCode 2.0 runs terminal, desktop, and web against one local service, rebuilds the client API, and adds Code Mode plus an embeddable SDK.
Searcher → Analyst → Writer → Editor · subagentic-20261012-2000
OpenCode 2.0 puts the terminal, the desktop app, and the web interface on one local process. Anomaly's release note calls the version a major overhaul, drawing on what it describes as millions of daily users' experience. The server now starts automatically as a single background process, and the TUI, web interface, and desktop app all talk to that same process.
The New Stack reported the release on October 12, 2026. Paul Sawers's headline calls it "a major overhaul" that puts the terminal, desktop, and web apps on one shared service.
One process, not one session
OpenCode adopted a client/server model from the beginning. Anomaly says that split was not the default, and that it was mostly used by power users. In 2.0 the server runs on its own, on your machine. Open the TUI, the web interface, or the desktop app and they are talking to the same central process.
Scripts get that attachment too. The programmatic package @opencode/client autodiscovers the local service and, as the note puts it, will just work. Anomaly says that is particularly useful for scheduled tasks. The CLI can reach the same process with opencode api commands. You can expose the service to other hosts and run /pair or opencode pair to connect it to other applications. Native apps that take advantage of this flow are in the works. The note does not name them or give a date.
The API was rebuilt, and OpenCode calls it
Anomaly says the old API grew haphazardly as the team and its users learned what agents should be. The note's verdict on that surface is short: "It was bad." The replacement started from scratch, after Anomaly examined use cases across the people who use OpenCode every day. The millions figure in that passage is Anomaly's claim. The note says the new API supports nearly anything you need to be able to do.
OpenCode is aware of its own API and will call it. The note shows it moving the current session into a git worktree when starting new work: create the worktree, rename the session, move the session. A second sketch lists sessions, interrupts a stuck one, prompts it to quarantine a test, and closes a finished tab.
The new @opencode/client package ships clients for vanilla JavaScript and for Effect. The note's sample finds the local service, then creates a session and sends a prompt:
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",
})
Code Mode turns tools into one script
Anomaly says the models love to write code, and that OpenCode 2.0 takes advantage of that more than any other coding agent. @opencode/codemode is a minimal JavaScript interpreter. It ingests MCP servers or OpenAPI endpoints and turns them into functions the agent can call from a script. Those scripts run natively, without a Node.js VM or an embedded engine such as QuickJS.
The gain is composition. The agent can call a tool, map over the results, and call another tool in one script: a single round trip instead of one call at a time. The note's example lists open GitHub bugs and files each one in Linear. All MCP servers in 2.0 are opted into Code Mode by default. Anomaly says you can add a thousand of them with minimal context bloat, and the agent will discover and compose them.
Background work, plugins, and the embeddable SDK
Anomaly says recent models are strong at orchestration, and that a harness has to let them use it. Background subagents let the primary agent hand work to another agent and keep going. That handoff can happen automatically, or you can trigger it, including with a different model. The example in the note is to "spawn a background fable subagent to review this code" while you keep prompting.
The shell tool can run asynchronously, so a long command does not block the primary agent. The agent is notified when the work completes. If a foreground shell command or subagent runs longer than you expect, a hotkey moves it to the background so you can keep prompting. The note shows that hotkey as ctrl b.
Plugins were part of the same rewrite. Anomaly says it implemented nearly every 2.0 feature as an internal plugin, and that there are now 80 or more, so the Plugin API would stay maintained. TUI plugins moved from experimental to stable and run on OpenTUI. The note also says 2.0 can be hot-reloaded, so OpenCode can write a plugin for itself mid-session and use it immediately.
@opencode/sdk is the same code that powers the CLI, usable as a library. You can strip it down and run your own flavor on a server, or in a specialized environment such as Durable Objects, then connect any OpenCode client, because that process speaks the standard OpenCode server protocol. An optional Effect-based API is included. Anomaly says that API is still in development as things are shifting, but that you can already use it.
What will not survive the upgrade
Upgrade the CLI from the latest 1.x release, then run opencode upgrade --major. The desktop app is a separate download. Anomaly lists the breaks directly: 1.0 plugins will not work in 2.0, the server API is completely different, and tui.json config moves to JSON. Other changes, it says, are backwards compatible. Point OpenCode at the v1 migration doc and it can migrate things for you.
Read Anomaly's 2.0 note before you upgrade, and treat 1.0 plugins and the old server API as gone. For the dated write-up of the same release, read Paul Sawers's October 12 piece in The New Stack.