140,000 stars. 850 contributors. 11,000 commits. 6.5 million developers using it every month. Zero IDE integration.
OpenCode is a terminal coding agent. It runs in your shell. It has no VS Code extension, no JetBrains plugin, no web UI. When it launched in March 2025 as a Go-based alternative to Aider and Cline, the conventional wisdom was that terminal-only was a deliberate niche — the kind of thing a few vim users would love and the rest of the market would ignore.
The rest of the market did not ignore it. Between January and April 2026, OpenCode crossed Cline, crossed OpenHands, and closed the gap on Aider despite Aider's two-year head start. I've been using it daily since February. Here's why the terminal won and what OpenCode's architecture got right that the IDE-bound tools missed.
The definition: what a terminal coding agent actually is
A terminal coding agent is a command-line process that reads your codebase from disk, talks to an LLM, writes diffs to files, and commits changes via git. The interface is whatever your terminal supports — text, a TUI, keybindings. There is no editor integration because the editor is wherever you want it to be.
That sentence contains the entire argument for terminal agents. The editor is wherever you want it to be. It can be Neovim on a remote dev box, VS Code on a laptop, Helix in a tmux session, or no editor at all if you're doing a batch migration. The agent doesn't care. It operates on files, not on buffers.
Your editor (anything) ←→ Files on disk
↑
OpenCode (terminal)
↓
LLM (75 supported models)
This decoupling is the thing. It's also the thing that Cline and Cursor explicitly rejected. Both bet that deep IDE integration — selection-aware context, inline diffs, click-to-apply — would be the defining UX. They weren't wrong about the UX. They were wrong about the market.
Why IDE integration stopped being a moat
I watched this happen in real time. In January 2026, Cline was the highest-starred AI coding agent with deep IDE integration. By April, it had been passed by three terminal-first tools. The stars were the symptom; the cause was workflow.
Three workflow shifts happened in the six months after late 2025:
First, remote dev environments became table stakes. GitHub Codespaces, Gitpod, and self-hosted dev containers became how serious teams worked. Every engineer I know who ships to production now SSHs into a box they didn't provision, edits files with whatever editor is installed, and commits from a terminal. An IDE-bound agent requires you to also forward your IDE to the remote box, which most people don't bother doing. A terminal agent is already there.
Second, Claude Code normalized the terminal for AI coding. Anthropic's own tool shipped as a CLI. Millions of developers who had been skeptical of terminal workflows used one every day because Anthropic's did. OpenCode rode that wave directly.
Third, multi-machine workflows got normal. You write code on your laptop, deploy to a cloud box, run agents on a local workstation for heavy jobs. An IDE extension has to run where the IDE runs, which is one place. A terminal agent runs anywhere you have a shell, which is everywhere.
The result wasn't that IDE extensions died — they didn't. It was that they stopped being the default answer. A developer asking "what coding agent should I use" in January 2026 got pointed to Cline. The same question in April got pointed to OpenCode, Aider, or Claude Code, depending on budget and taste.
The architecture decision that made OpenCode fast
I ran OpenCode against Aider and Cline on the same task for a week. The task was mid-complexity: refactor a Next.js app to use Server Actions across 34 files. Aider and Cline averaged 18-24 seconds per file. OpenCode averaged 6.
The difference was the language. OpenCode is written in Go. Aider is Python, Cline is TypeScript running in the VS Code extension host. For a tool that spends its time reading files, parsing diffs, and piping text to an LLM, Go's concurrency primitives and fast startup matter more than they should. OpenCode opens the repo, loads a file tree, and is ready to accept a prompt in under 150ms. Cline, running inside VS Code's extension host, takes 1.2-2 seconds to become responsive because it has to wait for the TypeScript runtime and the extension API.
// opencode/session/session.go — the core session loop, simplified
func (s *Session) Run(ctx context.Context, prompt string) error {
plan := s.planner.Plan(prompt)
for _, step := range plan.Steps {
go s.execute(ctx, step)
}
return s.wait(ctx)
}
Each step runs in its own goroutine. Reading files, calling the LLM, writing diffs — they happen in parallel when they can, which is often. Aider's equivalent loop is synchronous Python. Cline's is callback-driven TypeScript that runs inside VS Code's single extension host thread. For a task that touches 34 files, that throughput difference compounds.
The second architectural call was model routing. OpenCode supports 75 models via OpenRouter, direct Anthropic, direct OpenAI, Ollama for local models, and a custom-endpoint mode. You can route planning to Claude Opus 4.7 and execution to Claude Haiku 4.5 via a single config flag. On that Next.js refactor, I saved roughly 60% on token cost by routing the mechanical edits to Haiku while keeping the planning on Opus.
# opencode.config.yaml
models:
planner: anthropic/claude-opus-4-7
executor: anthropic/claude-haiku-4-5
fallback: openrouter/qwen-2.5-coder-32b
This is a pattern I also wrote about in
Post not found or has been removed.
— route the expensive model to the expensive problem, the cheap model to the mechanical work. OpenCode bakes it into the config.
The two UX decisions that actually matter
I've written a lot of agents. What I underestimated about OpenCode was how much of its appeal came from two specific UX choices that look small on paper.
The first is dual-mode agents. OpenCode has a Build mode and a Plan mode. Build mode writes diffs immediately. Plan mode produces a written plan and waits for your approval before touching a file. You switch between them with a keystroke. I did not think this mattered. It matters enormously. The friction of approving a plan before execution is exactly low enough that you do it for anything bigger than a one-file change, and the errors it catches are exactly the kind of errors that would otherwise cost you 40 minutes of git reset --hard.
The second is multi-session. You can run multiple OpenCode sessions in parallel on different branches of the same repo. Each session has its own model config, its own conversation state, its own plan. I typically run two: one on the branch I'm actively reviewing, one on a long-running migration that needs attention every few hours. Aider doesn't support this cleanly. Cline doesn't support it at all because it's tied to a single VS Code window.
These sound like small wins. In practice they eliminate two of the three biggest sources of friction in agent-based coding: "did I just blow up a file" and "do I have to context-switch my agent every time I context-switch my task."
Where Aider still wins and where OpenCode doesn't try
OpenCode is not strictly better than Aider. Aider is older, more stable, and has the best git integration I've seen in any coding agent. If your workflow is "make a small edit, review the diff, commit immediately, repeat," Aider is tighter. Its --commit flag does exactly what you want without you needing to think about it.
OpenCode is better for larger refactors, multi-file edits, and anything involving model routing. It's also better if you want to hand off to a teammate — the session state is serializable and portable, so you can pass an in-progress agent session to a colleague along with the branch.
Neither of them is Cline. Cline still wins for a specific flow: you're editing inside VS Code, you want to see inline suggestions, you want selection-aware context. For that workflow Cline is unmatched. It's just not the workflow that most developers optimized for in 2026.
What to actually do with this
If you're still on an IDE-bound coding agent, try a week with a terminal one. Not as a lifestyle change — as a benchmark. The terminal tools got fast enough that the context you lose from not having IDE integration is smaller than the speed you gain from cold-starting an agent in 150ms instead of 1.5 seconds.
If you're building a coding agent, the lesson from OpenCode isn't "write it in Go." The lesson is that the bottleneck is no longer model quality or prompt engineering. It's startup time, routing flexibility, and the ability to survive in the workflows developers actually use, which are increasingly remote, multi-machine, and terminal-primary. If your agent doesn't run on an SSH-only dev box, you're losing the next generation of users.
The OpenCode repo:
The open source AI coding agent.
English | 简体中文 | 繁體中文 | 한국어 | Deutsch | Español | Français | Italiano | Dansk | 日本語 | Polski | Русский | Bosanski | العربية | Norsk | Português (Brasil) | ไทย | Türkçe | Українська | বাংলা | Ελληνικά | Tiếng Việt
Installation
# YOLO
curl -fsSL https://opencode.ai/install | bash
# Package managers
npm i -g opencode-ai@latest # or bun/pnpm/yarn
scoop install opencode # Windows
choco install opencode # Windows
brew install anomalyco/tap/opencode # macOS and Linux (recommended, always up to date)
brew install opencode # macOS and Linux (official brew formula, updated less)
sudo pacman -S opencode # Arch Linux (Stable)
paru -S opencode-bin # Arch Linux (Latest from AUR)
mise use -g opencode # Any OS
nix run nixpkgs#opencode # or github:anomalyco/opencode for latest dev branch
Tip
Remove versions older than 0.1.x before installing.
Desktop App (BETA)
OpenCode is…
This is the final part of the series. Part 1 covered the Skills paradigm and how Karpathy's observations became a loadable format. Part 2 covered OpenClaw and why local-first agents beat cloud ones. All three projects tell the same underlying story — 2026 was the year the agent stopped being a product and started being a primitive.
The best coding agent is the one that boots before you finish typing the first word of your prompt.
For anyone who's made the switch from IDE to terminal agents recently — what was the specific task that convinced you? I'm collecting these because the narrative is still forming and I think the tipping point for most people was a single workflow, not a gradual preference shift.
Sources:
- OpenCode - Official site
- OpenCode repository - GitHub
- Best Open Source AI Coding Agents in 2026 - Open Source AI Review
- Aider - Official site
- Cline - GitHub
- OpenHands - GitHub
Top comments (0)