Skip to content
AI Primer
release

OpenCode v2 introduces one backend for TUI, desktop, and web sessions

OpenCode v2 moves its TUI, desktop, and web clients onto a shared backend so sessions stay synced and resource use drops across windows. The beta matters for multi-window agent workflows, though the next build still lacks features.

3 min read
OpenCode v2 introduces one backend for TUI, desktop, and web sessions
OpenCode v2 introduces one backend for TUI, desktop, and web sessions

TL;DR

  • thdxr's OpenCode v2 demo says the TUI, desktop, and web clients now share one backend, so sessions stay synced across windows by default.
  • According to thdxr's follow-up, the shared backend also makes always-on agent work more practical because the stack can hot reload across surfaces.
  • thdxr's resource-usage screenshot puts one long-running instance at about 460 MB RSS after more than five hours, while another thdxr reply says MCP usage is only minimized as far as the spec allows.
  • Beta timing is still loose: one thdxr reply targeted the end of next week, while another reply pointed early testers to bun i -g @opencode-ai/cli@next and warned that many features are still missing.

thdxr's demo clip shows edits propagating across terminal, desktop, and browser at the same time. You can also check the memory screenshot, the note about seeing all sessions on your computer, and the install reply that quietly frames this as a rough beta rather than a finished release.

Shared backend

OpenCode v2's core change is architectural. In thdxr's main post, thdxr says every client surface now talks to the same backend, which means sync is the default behavior instead of a separate feature.

That design also changes what the product can host. In thdxr's reply about always-on agents, he says they waited to ship this until the API and data model were ready, because an always-on agent setup means more systems have to be hot reloaded safely.

Session picker

The shared backend also changes session discovery. In thdxr's session-picker reply, he calls the current picker a weak version of what they want, then says the new architecture can finally guarantee visibility into all sessions on the local machine.

That is a small line with big workflow implications for anyone who keeps multiple agent runs open. The old problem was not just switching sessions, it was knowing the other sessions existed.

Resource use and MCP limits

The launch thread pairs the sync demo with a resource claim. thdxr's main post says a single shared backend should minimize usage when multiple windows are open, and his screenshot reply shows one process after 5 hours and 14 minutes at roughly 460 MB RSS.

The fine print is in thdxr's MCP reply. He says OpenCode does not fully minimize MCP overhead, only as much as the MCP spec permits, which suggests some duplication still lives at the protocol boundary.

Beta path

This is still a beta story, not a polished ship. one thdxr reply said the team was hoping for beta by the end of next week, while another thdxr reply gave a @next install path and immediately added that it is missing a lot of features right now.

The same reply from thdxr's install reply points to bun i -g @opencode-ai/cli@next, which makes the current build more like a preview channel than a formal release.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 3 threads
TL;DR2 posts
Resource use and MCP limits1 post
Beta path1 post
Share on X