In 2024, the default surface for AI coding tools was the IDE. Cursor defined the market. Copilot lived in a VS Code panel. Continue.dev was a sidebar. Every major AI coding experience was a thin layer on top of an existing editor.
Then 2026 happened. Today, the top four entries on SWE-bench Verified are all terminal-based agents. OpenAI previewed GPT-5.6 Sol last week and led with Terminal-Bench 2.1 as the headline metric — not an IDE benchmark. Claude Code has 135,000 GitHub stars and ships features weekly. Gemini CLI crossed 105,000 stars in its first year. JetBrains — the company that is an IDE — shipped Junie CLI in beta. Cursor, the IDE company that defined this market, released a standalone cursor-agent binary.
The terminal didn't just win the coding agent market. It made the IDE optional.
This wasn't supposed to happen. The IDE is objectively a better editing surface — syntax highlighting, inline diffs, project trees, debugger integration. Every developer experience metric favors it. And yet, when you look at where the best coding agents actually live, it's the terminal. Every. Single. One.
Why the Terminal Won
The explanation isn't about developer preference. It's about access.
An IDE extension runs inside a sandboxed process managed by the host application. It can access files the editor has open. It can call APIs the extension framework exposes. It can suggest diffs that the developer accepts or rejects one at a time. The IDE extension model is designed for assistance — the developer drives, the AI suggests.
A terminal agent runs as a process with the same access the developer has. It can read any file on the system. It can execute any shell command. It can manage git workflows, run tests, spin up processes, write output to disk, and chain operations across dozens of steps without asking permission each time. The terminal model is designed for autonomy — the agent drives, the developer supervises.
That distinction is everything. Coding agents in 2026 aren't autocomplete tools. They're autonomous workers that explore codebases, write implementations, run verification, and iterate until a task is done. That workflow requires unrestricted access to the system — and the terminal is the only surface that provides it without fighting the host application's extension API.
Consider what Claude Code does in a typical session. It reads files, runs grep to find patterns, executes tests, inspects build output, modifies multiple files in sequence, runs a linter, and commits changes. Every one of those operations is a natural shell command. Every one of them would require a custom API integration in an IDE extension — if the extension framework even supports it. The terminal doesn't have an extension API because the terminal is the API.
The Benchmark Proof
The shift isn't anecdotal. The benchmarks tell the same story.
As of June 2026, the SWE-bench Verified leaderboard — which tests whether an agent can solve real GitHub issues end-to-end — is dominated by terminal-based tools:
- Claude Code / Fable 5: 95.0% (export-suspended as of June 12)
- OpenAI Codex CLI / GPT-5.5: 88.7%
- Claude Code / Opus 4.8: 88.6%
- Gemini CLI / Gemini 3.1 Pro: 80.6% — and it's free
On Terminal-Bench 2.1, which specifically tests command-line workflows requiring planning, iteration, and tool coordination, Codex CLI leads at 83.4% with GPT-5.6 Sol previewing even higher. Claude Code / Fable 5 follows at 83.1%.
Zero IDE-only tools appear at the top of either leaderboard. The best IDE-based agent — GitHub Copilot with multi-model support — doesn't have a Terminal-Bench entry at all. That's not an oversight. It's because the benchmark measures the kind of autonomous, multi-step terminal workflows that IDE extensions architecturally can't perform.
The Feature Gap Compounds
Once the terminal won on access, it started winning on features too — because terminal agents iterate faster.
Claude Code's June 2026 release train shipped ten major features in three weeks: nested sub-agents up to five levels deep, fallback model chains for resilience, a community tool marketplace, per-agent cost attribution, scoped permissions, streaming agent logs, agent checkpointing with resume, inline cost budgets per agent, custom agent templates, and multi-repo orchestration. None of these would be possible inside an IDE extension framework — they all require process-level control over how agents spawn, communicate, and manage state.
IBM's Bob V2, released June 24, made the architecture explicit. It separates three components: the Agent (the agentic loop — all reasoning and code generation), the Harness (shared infrastructure: authentication, logging, feature flags, telemetry), and the Clients (IDE, shell, and more — with no duplicated logic). The key insight: the agent is client-agnostic. The IDE is just one client among many. It's not the center of the system.
Databricks went further. Their Omnigent project, open-sourced June 13 under Apache 2.0, wraps any terminal agent — Claude Code, Codex, others — in a uniform API. The pitch is direct: "messages and files in, text streams and tool calls out." They're building what they call a meta-harness — a layer above individual coding agents that handles sandboxing, policy enforcement, and live collaboration. Omnigent treats the terminal agent as a pluggable component, not a product.
This is the pattern: terminal agents are becoming composable infrastructure. IDE extensions are not.
The IDE Didn't Die — It Became a View
Here's the nuance most people miss: the IDE isn't going away. It's being demoted.
When Claude Code runs in a terminal and connects to VS Code via the VS Code extension, the IDE becomes a rendering layer — a place to view file changes, inspect diffs, and read code. But the agent's reasoning, tool calls, and execution happen in the terminal process. The IDE is a window into the agent's work, not the platform the agent runs on.
This maps to a broader architectural principle. The harness — the system that manages agent state, tool calls, permissions, and execution — lives at the process level. The UI is a client of the harness, not the other way around. When Bob V2 explicitly separates "the agent" from "the clients" and says the agent "behaves identically across every client," it's formalizing a pattern that Claude Code, Codex CLI, and Gemini CLI already implement implicitly.
The implication for IDE vendors is uncomfortable. If the agent's intelligence lives in the terminal, the IDE becomes interchangeable. A developer who runs Claude Code in the terminal with VS Code attached could switch to Neovim, Zed, or JetBrains with no change to the agent's capabilities. The value migrates from the editor to the harness.
This is why JetBrains shipped Junie CLI despite owning a suite of IDEs. They recognized that if the terminal becomes the default surface, an IDE company without a terminal agent is a phone manufacturer without an app store. The terminal isn't a threat to JetBrains' IDEs — it's a new layer they had to occupy to stay relevant.
The Pricing Model Shifted Too
The move to the terminal also changed how coding agents are priced — and who controls the relationship with the developer.
IDE-based tools typically charge a flat subscription. GitHub Copilot moved to usage-based AI credits on June 1 (1 credit = $0.01), retiring premium requests. Claude Code Pro costs $17/month with annual billing. Cursor Max starts at $100/month. These are the old models — predictable, but with hard ceilings.
The terminal agents introduced a different model: BYOK (Bring Your Own Key). Cline, Aider, Continue.dev, and Junie CLI all let developers use their own API keys. The agent is free; you pay for inference. Gemini CLI gives you Gemini 3.1 Pro for free — 60 requests per minute, 1,000 per day — no subscription required.
This fundamentally changes the economics. A developer running Aider with an API key pays for actual token usage, which can be 10x cheaper than a $20/month subscription for light-to-moderate use. For heavy users, the calculus flips — but the point is that the developer chooses. The terminal agent doesn't lock you into a pricing model.
And then there's Gemini CLI, which is free. Not freemium. Not free-with-limits-that-actually-matter. Genuinely free for the vast majority of developers, backed by a frontier model with an 80.6% SWE-bench Verified score. That's not a pricing strategy — it's a distribution strategy. Google wants developers running Gemini in their terminals, building workflows around it, and eventually upgrading to paid API tiers or Vertex AI for production use. They're giving away the surface to capture the stack.
The Verification Imperative
Autonomy without verification is a liability. The terminal agents that lead the market all solved this — and it's a key reason IDE-based tools fell behind.
xAI's Grok Build shipped a /goal mode on June 22 that's instructive. You give the agent an objective, it builds a checklist, executes each item, and — critically — verifies its work before declaring success. Verification can mean reviewing code, inspecting a webpage to confirm behavior, or executing scripts to test results. The agent runs until the task is completed and verified. You can pause, resume, or clear at any point.
That verification loop is only possible in the terminal because verification requires executing code, running tests, and inspecting output — all of which need shell access. An IDE extension can suggest a fix, but it can't independently verify that the fix works. The terminal agent can, because it has the same access a developer has.
This is the verification gap I wrote about in Harness Engineering: the difference between an agent that produces output and an agent that produces verified output. The terminal solved it by giving the agent the tools to check its own work. The IDE couldn't — not because the models weren't smart enough, but because the runtime didn't allow it.
What This Means for Your Infrastructure
If you're building agent infrastructure for your team or company, the terminal's victory has concrete architectural implications:
Treat the IDE as a client, not a platform. Design your agent harness as a standalone process that can run with or without an IDE attached. The IDE should connect to the harness, not the other way around. This gives you the flexibility to swap editors, run agents in CI/CD pipelines, or deploy agents on remote servers without re-architecting.
Build your tool layer around shell access, not extension APIs. If your agent needs to interact with internal systems — databases, deployment pipelines, monitoring dashboards — expose them as CLI tools or MCP servers that a terminal agent can call directly. Don't build IDE-specific integrations. They'll be slower to ship, more constrained, and obsolete when your team switches editors.
Standardize on MCP for tool integration. Every terminal agent worth using supports MCP. Claude Code, Codex CLI, Gemini CLI, and the open-source agents (Cline, Aider, dreb) all consume MCP servers natively. An MCP server you build today works across all of them. An IDE-specific integration works with exactly one editor.
Design for multi-agent orchestration. The terminal isn't just where one agent runs — it's where multiple agents coordinate. Claude Code's nested sub-agents (up to 5 levels deep), Databricks' Omnigent meta-harness, and IBM Bob V2's background task model all point to the same pattern: production agent systems run multiple agents in parallel, and the terminal is the natural orchestration surface for that.
The Contrarian View (And Its Limits)
Most people still think the IDE is where AI coding happens. The marketing from Microsoft, JetBrains, and even Cursor reinforces this — their landing pages show screenshots of beautiful diffs in IDE panels. But the actual production workflows have moved. The developers spending $100-200/month on Claude Code Max aren't doing it for the IDE integration. They're doing it because the terminal agent can do things the IDE agent fundamentally can't.
That said, the terminal isn't universal. For specific workflows — rapid inline code completion, visual refactoring previews, pair-programming with tight feedback loops — the IDE still offers genuine value. The IDE isn't dead for assisted coding. It's dead for agentic coding. Those are increasingly different activities, and the gap between them is widening every month.
What to Do This Week
If you haven't already moved your primary coding workflow to a terminal agent, here's the pragmatic path:
- Install two terminal agents and compare them on a real task. Claude Code and Codex CLI are the obvious choices. Gemini CLI is the free option if budget is a constraint. Give each one a non-trivial issue from your backlog — something that requires reading code across multiple files, writing tests, and running the build. The difference between terminal agents and IDE extensions becomes obvious within the first task.
- Write a GEMINI.md or CLAUDE.md or AGENTS.md for your project. These files — the equivalent of system prompts for terminal agents — define coding conventions, project structure, testing commands, and constraints. They're how you turn a generic terminal agent into one that understands your codebase. If you've been maintaining this context in your head or in scattered wiki pages, now's the time to codify it.
- Identify one MCP server your team needs and build it. If your agents need access to internal systems — a CI/CD pipeline, a monitoring dashboard, a feature flag service — wrap it as an MCP server. That investment works across every terminal agent you'll use for the next two years.
- Re-evaluate your IDE spend. If your team is paying for IDE-based AI subscriptions and using terminal agents for real work, you may be paying for two tools when one suffices. The terminal agent's capabilities have surpassed the IDE's for anything beyond inline completion.
The Pattern Beneath the Pattern
The terminal's victory over the IDE is one instance of a broader trend in agent infrastructure: the runtime that gives agents the most access wins.
The IDE constrained agents to what extension frameworks allowed. The terminal gave agents the same access developers have. The sandbox — projects like Tencent's Cube (open-sourced April 2026 with sub-60ms cold starts) and Google's Agent Substrate on Kubernetes — gives agents even more: isolated, reproducible, checkpointable environments that can be spawned and destroyed at will.
Each layer of the stack is being rebuilt around the assumption that agents need real access to real systems to do real work. The terminal was the first surface to deliver that. It won't be the last — but it was the one that broke the IDE's monopoly on AI-assisted development.
The terminal ate the IDE. Not because terminals are better editors. Because the terminal is where agents can actually be agents.