OpenCode 2.0 is an architectural reset disguised as a version bump. The headline change is a persistent background service — a single daemon process that every interface (TUI, web, desktop app, programmatic client) connects to. Sessions survive tab closures. Scripts autodiscover the local service. You can expose it to other hosts and pair with remote applications. This is the move from "chat tool" to "local agent runtime," and it has structural consequences for how developers interact with AI coding assistants. The API was rewritten from scratch. The team admits the 1.0 API "was bad" — it grew reactively as the industry collectively figured out what agents should do. The new API covers session management, programmatic prompting, and self-referential operations where OpenCode calls its own API to do things like migrate a session into a git worktree. A new client package (@opencode/client) ships with both vanilla JavaScript and Effect-based interfaces. The most technically aggressive move is Code Mode, powered by @opencode/codemode — a minimal JavaScript interpreter that ingests MCP servers or OpenAPI endpoints and converts them into callable functions. Instead of the agent invoking tools one at a time in separate round trips, it writes scripts that compose multiple tool calls in a single execution. All MCP servers are opted into Code Mode by default, meaning you can connect hundreds of them with minimal context bloat. The agent discovers and chains them as needed. Background tasks get first-class support. The primary agent can spawn subagents (even with different models) and run shell commands asynchronously. If a foreground task stalls, a hotkey moves it to background. This is orchestration infrastructure — the models are getting good enough at delegation that the harness needs to stop being the bottleneck. The plugin system was effectively rebuilt by dogfooding: nearly every 2.0 feature is implemented as an internal plugin, 80+ in total. TUI plugins graduate from experimental to stable, built on OpenTUI. Everything hot-reloads, so the agent can write a plugin mid-session and use it immediately. This is the strongest signal of architectural confidence — if your own features can't use the plugin API, the plugin API is a toy. OpenCode can now also be used as an embedded library via @opencode/sdk, the same code powering the CLI. You can strip it down and run your own variant on a server or in specialized environments like Durable Objects, then connect standard OpenCode clients to it. The upgrade path from 1.x is a CLI command, but 1.0 plugins break, the server API is completely different, and TUI config files moved formats. The strategic picture: OpenCode is building toward a local-first agent operating system. The persistent service, the composable tool runtime, the plugin architecture, and the embeddable SDK are all moves to make OpenCode the substrate that other tools and workflows sit on top of — not just another coding chat interface. The risk is platform complexity; the opportunity is that whoever owns the agent runtime layer captures an enormous amount of developer workflow.
