OpenCode 2.0: One Process Runs the TUI, Web, and Desktop App

⏱️ Reading time: 10 min

You open the terminal, the browser, and the desktop app, and all three talk to the same background process: that’s how OpenCode 2.0 starts, the update with which Anomaly redesigns the service, the API, and the way agents use tools after gathering data from millions of daily uses.

📑 En este artículo

1. TL;DR
2. What Is OpenCode
3. What Happened: OpenCode 2.0 Changes the Service Model
4. Context and History
5. Technical Details: How the Unified Service and Code Mode Work
6. Impact and Analysis
7. What’s Next
8. Frequently Asked Questions
   1. What is code mode in OpenCode 2.0?
   2. How do OpenCode’s TUI, web, and desktop app connect?
   3. What are OpenCode’s background subagents?
   4. Do you need to configure anything to activate OpenCode’s unified service?
   5. Does the open source agent break compatibility with the previous version?
   6. Where can you try Anomaly’s CLI?
9. References

The change is not minor: before, that client/server model existed but stayed hidden behind an optional advanced setting.

TL;DR

• OpenCode turns the server into a single process shared by the TUI, web, and desktop app.
• The @opencode/codemode package lets you write JavaScript to chain MCP calls in a single round trip.
• All MCP servers run in code mode by default, so adding thousands of them doesn’t bloat the context.
• It adds subagents and background shell commands, even using a different model than the main one.
• The API was rewritten from scratch after Anomaly admitted the previous one grew poorly under real-world use.

What Is OpenCode

OpenCode is an open source coding agent built by Anomaly that runs in the terminal, browser, and desktop. It works as a client for a local service that runs coding sessions assisted by language models, and the OpenCode 2.0 update turned it into a client/server system by default.

Before this version, the client/server model existed but was optional: most users opened each interface as a standalone program, without sharing sessions or context between them. The underlying change isn’t a new feature, but turning on by default something that had been in the code since the project started.

What Happened: OpenCode 2.0 Changes the Service Model

Anomaly released OpenCode 2.0 as what its own team describes as a major revision of the project, built on the experience of millions of daily users. The most visible change is that the server, which had run under a client/server model from the start, now automatically starts as a single background process on the user’s machine.

When you open the TUI, the web client, or the desktop app, all three connect to that same central process instead of spinning up separate instances. If you use the programmatic @opencode/client package to build your own scripts, they detect the local service automatically, which is useful for scheduled tasks that previously required managing the connection by hand. You can also invoke it via the CLI with opencode api commands, or expose the process to other applications with /pair or opencode pair.

At the same time, Anomaly’s CLI rewrote the API from scratch. Anomaly admits the previous version grew without a plan while the team and community figured out what agents actually needed, and that it ended up being hard to use; the new version reviewed real use cases to cover virtually any operation needed, including having the agent itself call its API to move to a git worktree when starting a new task.

Context and History

The client/server model isn’t new: it had been in OpenCode since its earliest versions, but it stayed as an option for advanced users who wanted to run the process separately and connect multiple interfaces by hand. Most of the user base never turned it on, so each session lived isolated inside the terminal or browser that opened it.

That design created a friction well known in code agent tools: if you closed the terminal, you lost the session’s thread, and coordinating the same work across different interfaces meant repeating context. Integration with Model Context Protocol (MCP) servers suffered a similar problem: every tool added piled onto the model’s list of visible functions, so connecting too many bloated the context before writing a single line of code.

Anomaly’s tool tackles both problems at once: it unifies the backend so sessions survive closing any particular client, and it changes how MCP tools are exposed so adding more doesn’t cost more context.

Technical Details: How the Unified Service and Code Mode Work

The underlying change is simple to describe but has practical consequences: instead of each interface (TUI, web, desktop) spinning up its own process, the first one opened creates the service and the following ones reuse it. The @opencode/client package includes a discovery method that looks for that local process before trying to create a new one:

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 pending changes in this repo",
})

Service.ensure() locates the active process (or starts it if it doesn’t exist) and returns the URL and headers needed to talk to it, without the script knowing in advance whether there are zero, one, or several clients open. The call to session.create returns an object with an identifier in the format ses_7c41e09a, the same one used by the session list inside the TUI: if you open that session from another interface, it’s literally the same one, not a copy.

The second major change is code mode, shipped in the @opencode/codemode package. It’s a minimalist JavaScript interpreter, without the complexity of a Node.js VM or embedding an engine like QuickJS, that turns MCP servers and OpenAPI endpoints into functions an agent can call from a script. Instead of asking the model for one tool at a time (list issues, then create each ticket one by one), the agent writes a script that chains several calls and returns the final result in a single turn. In Anomaly’s CLI, all MCP servers run in code mode by default, so adding hundreds of integrations doesn’t multiply the context the model has to read on every turn.

The third change is background tasks: Anomaly’s tool adds subagents that the main agent can delegate to without stopping, even using a different model than the one driving the main conversation, plus shell commands that run asynchronously. That way, a long bun test or bun run build doesn’t block the agent while you keep giving it instructions; the user can also manually send that work to the background to free up the main conversation.

sequenceDiagram
    participant T as TUI
    participant W as Web
    participant D as Desktop
    participant S as OpenCode Service
    T->>S: connects to local session
    W->>S: connects to same session
    D->>S: connects to same session
    S-->>T: shared state
    Note over T,W,D: all three interfaces see the same sessions

To confirm the service runs as a single process, it’s enough to check the opencode api commands exposed by the CLI itself: if a session created from the TUI also shows up when connecting from a script with @opencode/client, it’s the same session, not a new one, a sign that the interfaces actually share a backend.

💭 Key takeaway: code mode doesn’t replace the model: it just gives it a place to write the glue between tools without spending a conversation turn on every call.

Impact and Analysis

OpenCode 2.0’s bet is economic as much as technical: every tool call within a language model’s turn costs tokens, and adding dozens of MCP servers to an agent used to mean paying that cost on every turn even when not all tools were used. Code mode shifts that cost to a script that runs once, which in practice lowers how many turns an agent needs for tasks like auditing issues across several repositories or syncing tickets between different systems.

The unified service also changes how you work with code agents: a session no longer depends on the terminal where you opened it staying open. That enables workflows where someone starts a task from their phone with the desktop app running on their computer, or where a cron job triggers a script that uses the same session a developer left half-finished.

The honest side of the change: unifying everything into a single local process also concentrates the risk there. If that process crashes or gets tied up with a heavy task, all three interfaces lose service at the same time, something that didn’t happen before with separate processes.

What’s Next

Anomaly confirmed it’s already working on native applications that take advantage of this same remote connection flow, the /pair command to link external clients to a session, though it hasn’t given a release date yet. The rest of the project’s direction depends on how code mode performs with larger MCP integrations in production, something that for now can only be measured project by project.

Try it yourself: install OpenCode, open the TUI and the web client at the same time, and check whether both show the same active session without having to log in again.

Frequently Asked Questions

What is code mode in OpenCode 2.0?

It’s a minimalist JavaScript interpreter from the @opencode/codemode package that turns MCP servers and OpenAPI endpoints into functions callable from a script, so the agent can chain several calls in a single run instead of requesting one tool per turn.

How do OpenCode’s TUI, web, and desktop app connect?

All three connect to the same service process running in the background on the machine: the first interface opened starts it, and the following ones reuse it automatically.

What are OpenCode’s background subagents?

They’re processes that the main agent can delegate to without stopping the conversation, even using a different model than the one driving the main thread; they can be launched automatically or manually with a keyboard shortcut.

Do you need to configure anything to activate OpenCode’s unified service?

No: starting with 2.0, the process starts by default. Those who already used it manually, or those who want to expose it to another machine, can still control it with commands like opencode api or /pair.

Does the open source agent break compatibility with the previous version?

The API was rewritten from scratch, so integrations that relied on old endpoints need review; Anomaly designed the new version to cover existing use cases, but any script that talked directly to the previous API should be tested against the new one before relying on it in production.

Where can you try Anomaly’s CLI?

OpenCode’s official announcement was published on Anomaly’s blog, along with the project’s repository, which documents the @opencode/client and @opencode/codemode packages.

References

• Anomaly: official OpenCode 2.0 announcement with details on every change.
• GitHub: OpenCode project repository, with the @opencode/client and @opencode/codemode packages.
• Model Context Protocol: specification of the protocol that code mode turns into callable functions.

📱 Do you like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Featured image: Foto de Carlos Gonzalez en Unsplash