OpenCode, the terminal coding agent from the SST team, just shipped v1.17.8 and has 176,000 GitHub stars as of June 2026. Claude Code sits at 132K. OpenCode also topped LogRocket's AI dev tool power rankings this month, displacing Cursor. That's a real market signal, not just GitHub vanity metrics.
The core pitch: OpenCode is free, MIT-licensed, and works with 75+ AI providers. You pick the model. The agent is the constant; the intelligence behind it is a config option.
What OpenCode Actually Is
It's a Go-based CLI with a terminal UI, built by the SST team (the people behind SST and terminal.shop), and it runs on a client/server architecture. The TUI is just one client. The agent process runs on your machine and can be driven remotely from another client, including a desktop app for macOS and Windows.
It ships with two built-in agents: a build agent with full filesystem and shell access, and a plan agent that's read-only for code exploration and analysis. An additional general subagent handles multi-step searches and complex tasks you invoke with @general. LSP integration means it reads language server data rather than just raw files. MCP support lets you wire in external tools through a standard protocol.
v1.17.8 is current as of June 17, 2026, with 14,000+ commits on the dev branch and 825 total releases. This isn't a toy project.
Why the Model-Agnostic Pitch Is Working
For a lot of engineering teams, the first question about AI coding tools is about cost and lock-in. Claude Code requires a Claude Pro subscription. Codex CLI runs on usage-based OpenAI billing. At 50 engineers, the numbers add up.
OpenCode's free/MIT baseline changes that calculus. Teams on AWS Bedrock or Azure OpenAI through enterprise contracts can point OpenCode at existing infrastructure and pay API costs instead of per-seat fees. Teams with privacy constraints can route it to a local Ollama instance and keep code entirely on-premises.
That's a real structural advantage. It's the reason 7.5 million developers are actively using it.
Where the Benchmark Reality Gets Complicated
The Terminal-Bench 2.1 leaderboard measures agents completing real terminal-driven development tasks: editing files, running commands, fixing failures. June 2026 scores:
- Claude Fable 5: 88.0% (first to break 85%)
- Codex CLI + GPT-5.5: 83.4%
- Claude Code + Opus 4.8: 78.9%
- Gemini CLI + Gemini 3.1 Pro: 70.7%
OpenCode isn't independently benchmarked because it's model-agnostic. Feed it Fable 5 and you get near-Fable-5 performance. Feed it GPT-5.5 and you're close to the Codex CLI line. The 9 to 14 point spread across the leaderboard is real and meaningful on complex multi-step tasks.
This is where I'd push back on the "just swap models" framing. If you configure OpenCode with Fable 5 to hit top-of-chart performance, you're paying Anthropic API rates. At that point, Claude Code's flat $20/month may be competitive or cheaper on heavy agentic workloads.
The model-agnostic story is strongest when you're using mid-tier or local models by design, not when you're trying to squeeze out maximum performance.
What You Can't Get from a Provider-Agnostic Tool
Claude Code ships features that don't port to OpenCode's architecture. Agent View is a fleet dashboard for monitoring all running Claude Code sessions. The /goal command runs a task autonomously to completion. Routines let you define multi-step workflows you can trigger with one command.
These features exist because Anthropic builds Claude Code end to end on a single model with full state visibility. OpenCode can't build Agent View because it can't consistently track session state across providers. Tight coupling limits portability. It also enables differentiated features that a provider-neutral agent can't ship.
The same logic applies to Codex CLI's optimization for GPT-5.5's agentic capabilities. That optimization doesn't transfer cleanly to other models.
When to Use Each
I reach for Claude Code when the work requires deep multi-step reasoning, 20-plus tool calls, and session continuity. The fleet management features alone have saved me real time on longer autonomous tasks.
OpenCode makes sense when cost or privacy constraints are actual requirements rather than hypothetical concerns. A team with existing enterprise cloud contracts, code that can't touch third-party servers, or developers who want to mix local models for cheap quick tasks with API calls for complex ones.
The star count gap tells you something about design preferences, not quality. A lot of developers want the agent to be their constant and the model to be a variable they control. That's a reasonable position. The question is whether "any model" is what you need, or whether "the best model, fully integrated" is what the work requires.
For serious agentic sessions, I haven't found a compelling reason to give up the integration advantages. But I'm watching how the OpenCode enterprise adoption story develops, because the cost and privacy arguments are genuinely hard to dismiss.