OpenCode: a terminal agent that treats the TUI seriously

Most coding CLIs treat the terminal as a dumb pipe: stream some tokens, ask yes or no, repeat. OpenCode treats it as a product surface. That sounds cosmetic until you accept an uncomfortable truth about coding agents: the interface decides how much of the agent's work you actually review, and review is where the value gets won or lost.

The TUI is the product

Launch it and the difference is immediate: a responsive full-screen interface with real scrollback, syntax-highlighted diffs, themes, and keybindings worth learning. Sessions are first-class: list them, resume them, share them. None of this changes what the model can do. All of it changes how fast you can see what the model is doing, and supervision speed, not model speed, is the practical bottleneck in most coding sessions.

Any key, any model

OpenCode is aggressively provider-agnostic. Bring an API key from any major lab, point it at an OpenAI-compatible endpoint, or run against a local model server. Same interface, same config. Switching models mid-project is a config edit, not a migration, and local models get the same first-class treatment as frontier APIs, a pairing I've covered separately.

For a team, the quiet benefit is that the tool outlives your provider decisions. When pricing shifts or a new model leapfrogs the incumbent, you re-point OpenCode instead of retraining muscle memory on a new CLI. That durability is the core promise of the open column in my landscape map.

The client/server split

The sleeper feature: OpenCode isn't one program. The engine runs as a server; the TUI you see is just a client attached to it. For weeks you won't notice. Then one day you want to drive a session on your desktop from a laptop, or point a different frontend at a running agent, or script against the engine from CI — and the architecture that looked like overkill becomes the feature you won't give up.

LSP integration rides the same philosophy: language servers run alongside the agent and their diagnostics flow back into the loop, so the model finds out about the type error it just introduced without you pasting compiler output like it's 2024.

The tuning tax

A vendor CLI is a model wearing a custom-fitted harness. OpenCode is a well-made harness that fits every model a little loosely.

Provider-agnosticism has a cost that never makes the README. Vendor agents co-evolve with their models: the prompts, tool definitions, and recovery behavior get tuned against one family's quirks, and by all appearances the models are trained back toward the harness. OpenCode's harness has to stay generic. Run the same frontier model through both, and the vendor loop tends to recover from weird states a little more gracefully.

The gap narrows as models get better at being generic agents, but it's real, and it's the honest price of neutrality. Whether that price is worth paying is the whole question of open versus vendor CLIs.

Reach for OpenCode if you live in the terminal, switch models often, or want your agent reachable from more than one screen. Skip it if you're all-in on a single vendor's models: their own CLI will squeeze more out of every token. Either way, keep an eye on the client/server split. My bet is that idea, not the pretty interface, is the part everyone ends up copying.