OpenCode

What it is and how it works

OpenCode is a terminal-based AI coding agent built by the SST team (the same group behind the SST infrastructure-as-code framework), designed as an open-source, provider-agnostic alternative to Claude Code. It runs as a rich terminal user interface (TUI) rather than a chat window bolted onto an editor — the interaction model is a persistent, full-screen terminal session where you converse with an agent that can read your codebase, propose edits, run shell commands, and iterate against real command output (test runs, linters, build errors) in a loop.

Architecturally, OpenCode is a client-agnostic agent core wrapped in a terminal UI. It is explicitly "bring your own LLM": rather than shipping tied to a single model vendor, it supports multiple providers through a pluggable backend — Anthropic, OpenAI, Google, local inference servers, and others exposing an OpenAI-compatible or native API. This is the project's central design bet: the agentic loop (planning, tool calls, file edits, verification) is treated as a reusable harness that is largely model-agnostic, and the choice of "which brain drives the loop" is left to the user's budget, latency needs, and privacy requirements rather than baked into the product. It also implements the Model Context Protocol (MCP), so it can attach to external MCP servers for things like database access, browser automation, or ticket-tracker integration, using the same protocol that Claude Desktop and Claude Code use — meaning MCP servers you've already configured for other tools are largely reusable here.

Under the hood, the agent loop follows the now-familiar pattern popularized by Claude Code and similar CLI agents: the model is given tool definitions for file read/write, shell execution, and search, and it operates autonomously within a permission model that lets you approve or auto-approve categories of actions. Because OpenCode is open source (unlike Claude Code, which is closed-source despite being distributed as a CLI), its permission gating, prompt construction, and tool-calling logic are all inspectable and modifiable — a meaningful difference for teams that want to audit exactly what gets sent to a model or customize agent behavior beyond what config flags expose.

Deployment patterns

The dominant deployment shape is solo developer, local machine, terminal-native workflow — install via the project's install script or a package manager, run opencode in a repo, and point it at a provider by supplying an API key (Anthropic, OpenAI, etc.) or a local endpoint. Because it has no GPU or OS-specific runtime dependency of its own — it's a Go/TypeScript-based CLI orchestrating remote or local API calls, not an inference engine — it runs identically on macOS, Linux, and Windows, which is a real practical advantage over some competing agent tools that started Unix-first and treat Windows as an afterthought.

A second common pattern is pairing OpenCode with a self-hosted or local model server (llama.cpp server, Ollama, vLLM, or similar) for privacy-sensitive codebases, since the agent itself has no opinion about where inference happens — it just needs an API endpoint. This makes it attractive to teams that want Claude-Code-style agentic workflows without any code leaving their network, at the cost of needing a capable enough local model, since agentic coding loops are considerably more demanding on instruction-following and tool-call reliability than simple autocomplete.

Team usage tends to be informal rather than server-based: because pricing is "free, bring your own API key," there's no natural multi-seat SaaS deployment the way there is for hosted tools — each engineer runs their own instance against their own key, and consistency across a team is achieved via shared config files (checked into the repo) rather than centralized infrastructure. Some teams standardize on a specific provider/model pin in a committed OpenCode config so that agent behavior doesn't silently drift as individuals switch providers.

How it compares

Against Claude Code, OpenCode's direct inspiration, the trade is openness and provider flexibility versus polish and tight integration. Claude Code is closed-source and Anthropic-model-only, but benefits from first-party integration work and doesn't require you to manage a separate agent-harness codebase. OpenCode gives you the same terminal-agent workflow shape without vendor lock-in, at the cost of being a younger, community-maintained project where rough edges are more likely.

Against Aider, the longer-established open-source terminal coding agent, OpenCode is newer and has a more modern, full-screen TUI versus Aider's more minimal REPL-style interface. Aider has a longer track record, a more mature and battle-tested diff/edit-application strategy (including its repo-map and multiple edit formats tuned per model), and a larger base of accumulated real-world usage data on which models perform well for which languages. OpenCode's MCP support and richer TUI are advantages for users who want tool ecosystem integration, but Aider remains the safer choice for teams prioritizing proven reliability over interface polish.

Against Cursor or other IDE-embedded agents, OpenCode's terminal-only interface is both a limitation and a feature: no GUI, no inline diff visualization in an editor pane, but also no IDE lock-in — it works over SSH into a remote box, in a devcontainer, or in any environment with a terminal, which IDE-bound agents generally cannot match.

Best use cases and honest limitations

OpenCode fits developers who already live in the terminal, want a Claude-Code-style agent loop but need multi-provider flexibility (cost arbitrage, using a cheaper or local model for routine tasks, avoiding single-vendor dependency), or want an inspectable, modifiable open-source agent rather than a black box. The MCP support means it slots into an existing tool ecosystem — database MCP servers, browser MCP servers — without extra glue code, and cross-platform parity (including genuine Windows support) is a real differentiator versus tools with weaker Windows stories.

The honest caveats are the ones the project's own data reflects: it is a younger project than Aider, so expect more frequent breaking changes, less battle-tested edit-application heuristics, and a smaller base of community troubleshooting knowledge. More fundamentally, output quality is entirely a function of which model you point it at — since OpenCode supplies the harness, not the intelligence, a weak or small local model will produce a noticeably worse agentic experience than the same harness driven by a frontier model, and the "BYO LLM" flexibility that is its main selling point is also what makes results inconsistent across users depending on their provider choice and budget. Teams wanting a single, predictable, vendor-supported experience with minimal configuration decisions are better served by a first-party tool; teams that want control, portability, and the ability to swap or self-host the underlying model should find OpenCode a reasonable fit.