AI Blog

Claude Code vs Codex CLI vs Antigravity CLI vs opencode: pick the contract, not the score

The top two terminal coding agents are 0.4 points apart on Terminal-Bench 2.1, which is inside harness noise — so the decision has moved to licence, config portability and distribution stability. Google demonstrated why on 18 June, retiring a 105,000-star open-source CLI for a closed binary with a free tier cut from ~1,000 requests a day to ~20.

By Agentic AI Wiki 16 min read

On Terminal-Bench 2.1 the two leading terminal coding agents are separated by four tenths of a point — 89.5% against 89.1% — which is inside the noise band of the harness that measured them. The axis everyone still argues about has closed, and the axis that decides what a switch costs you was demonstrated in public on 18 June, when Google shut off a 105,000-star open-source CLI and replaced it with a closed Go binary that cut the free tier from about a thousand requests a day to roughly twenty and broke CI pipelines on the way past. Pick your terminal agent on its contract, not its score.

At a glance

Four tools that all live in a terminal, all read a project instructions file, all speak MCP, and all resolve to a different answer to the question what happens to my setup when the vendor changes its mind.

ToolSource & licenceModelDistributed as
Claude Code Proprietary, under Anthropic's commercial terms Anthropic only; Opus 5 default since 24 July 2026 @anthropic-ai/claude-code on npm
Codex CLI Apache-2.0, written in Rust OpenAI only; GPT-5.6 default since it went GA on 9 July 2026 @openai/codex on npm
Antigravity CLI Closed-source, written in Go Google only The agy binary
opencode MIT, written in TypeScript Provider-agnostic — Anthropic, OpenAI, Google, or a local model opencode-ai on npm
Four terminal coding agents compared on five contract axes A matrix comparing Claude Code, Codex CLI, Antigravity CLI and opencode across five axes: source and licence, model choice, config portability, free-tier stability, and whether a version can be pinned in CI. opencode scores strongest on every axis except integration depth; Codex CLI is open under Apache 2.0 but model-locked; Claude Code and Antigravity CLI are both closed, with Antigravity the weakest on free-tier stability and pinnability. Nobody wins this table. That is the finding. Source& licence Modelchoice Configportability Tierstability Pin inCI Claude Code Proprietary Anthropic only Own schema Paid plans npm Codex CLI Apache-2.0 OpenAI only AGENTS.md ChatGPT plans Fork Antigravity CLI Closed binary Google only Rewritten twice 1,000 → ~20/day No opencode MIT Any provider AGENTS.md Your own key Fork strong workable weak Missing from this table: integration depth, harness maturity, and how good the default model is — the three axes on which the two closed tools lead, and the reason people keep choosing them. A contract you can exit is worth something. It is not worth everything.
The axes that decide your exit cost. Note which two tools lead on the axes this table leaves out.

The model axis closed, and almost nobody updated their comparison

Terminal-Bench 2.1 runs 89 tasks in a real shell. On the Terminus 2 harness, GPT-5.6 Sol at extra-high reasoning effort completes 89.5% of them; Claude Opus 5 at max effort completes 89.1%. Those are the default models of Codex CLI and Claude Code respectively.

Four tenths of a point across 89 tasks is under half of one task. It is smaller than the run-to-run spread you get from re-running the same harness against the same weights, and agentic benchmarks are noisy in a specific, well-documented way: a single flaky container, one retried network call, one non-deterministic sort in a fixture, and the ranking flips. Anyone quoting this gap as a reason to standardise a team on one vendor is reading a coin toss as a signal — the arithmetic is in eval variance and statistical power.

The convergence is not a fluke of one benchmark. Both defaults are frontier models released within a fortnight of each other, trained on similar objectives, and evaluated on a harness that both vendors optimise against. The interesting consequence is what it does to the decision: if the models are interchangeable on your workload — and you should verify that on your tasks rather than on anyone's leaderboard — then everything left in the choice is harness, ergonomics and terms.

Benchmark scores are the most quoted and least durable input to this decision. They change every six weeks. The licence does not.

What Google did in June is the most useful datapoint of the year

Timeline of the Gemini CLI retirement and the Antigravity CLI replacement A four-stop timeline running from Google I/O on 19 May 2026, where the consolidation under the Antigravity brand was announced, to the 18 June 2026 shutdown for free, Pro and Ultra users, to the replacement by a closed-source Go binary named agy, to the consequences: a free tier cut from about 1,000 requests a day to roughly 20, a rewritten settings schema, and broken CI pipelines. Thirty days from announcement to a broken build 19 MAY 2026 Announced at I/O Tooling consolidates under Antigravity 18 JUN 2026 Gemini CLI stops serving Free, Pro and Ultra tiers cut off REPLACEMENT agy — a Go binary Closed source, async-first FALLOUT Rewritten schema Pipelines break 105,000 stars The open repo the ecosystem built on 1,000 → ~20 Free-tier requests per day, after the swap Enterprise exempt Code Assist licence holders keep the legacy CLI No fork path A closed binary cannot be pinned None of this was a capability decision. Every part of it was a licensing and distribution decision. Those are the terms your CI depends on, and they are not in any benchmark.
Announcement to shutdown in thirty days. Every step was a licensing decision, not a capability one.

At I/O on 19 May 2026 Google announced it was consolidating developer tooling under the Antigravity brand. On 18 June the Gemini CLI stopped serving requests for free, Pro and Ultra users. Organisations holding Gemini Code Assist licences were exempt and could keep the legacy CLI; everyone else moved to Antigravity CLI, a closed-source Go binary invoked as agy, with a migration tool that converts old extensions into plugins and rewrites settings.json into a new schema.

The functional replacement is, by most accounts, a better tool: faster, async-first, and it carries the skills, hooks and subagent mechanisms across. That is not the point. The point is the shape of what happened to everyone downstream:

  • An open repository with 105,000 stars stopped being the artifact. Forking it, pinning it, or auditing it are no longer available options, because the thing you now run is a binary.
  • The free tier fell from roughly a thousand requests a day to about twenty. Any workflow whose economics depended on the old number — CI checks, batch triage, anything running unattended — did not degrade. It stopped.
  • A config schema change broke pipelines silently. Not a capability regression, not a model change: a rewrite of the file your automation reads.
  • Thirty days of notice. Enough to migrate an individual developer. Not enough to re-qualify an agent across a large engineering organisation, which is a re-evaluation exercise rather than a package upgrade.

None of this appeared on a benchmark, and all of it was foreseeable from the licence. That is the argument of this post compressed into one event.

The four layers, and which one you are actually choosing

The four layers of a terminal coding agent, and who owns each A stack diagram with four layers. The model layer and the harness loop are owned by the vendor and are replaceable or not depending on licence. The configuration surface — project instructions, permission rules, MCP servers, hooks and subagents — sits between the vendor and your repository and is where switching cost accumulates. The repository and CI layer is yours and outlives every agent you install. Where the switching cost actually lives Model Swappable in two of the four. Scores now sit within a point of each other. VENDOR Harness loop Planning, tool dispatch, compaction, retries. Closed in two of the four. VENDOR Configuration surface Project instructions file · permission allow / deny rules · MCP servers hooks · subagents · skills · slash commands You author it. The vendor defines its schema. It does not transfer. Your repository and CI Tests, setup scripts, review gates. Outlives every agent you install. YOURS above: replaceable in an afternoon below: the part that survives a migration The two layers everyone benchmarks are the two that cost least to change. The layer nobody benchmarks is the one that decides whether you can leave.
The layers everyone benchmarks are the cheap ones to change. The layer nobody benchmarks decides whether you can leave.

A terminal coding agent is four layers stacked, and they have wildly different replacement costs.

The model is the layer with the most attention and the least stickiness. Swapping it is a config line in the two tools that permit it and impossible in the other two — but as of this summer it is also the layer where the options are closest together.

The harness loop — how the agent plans, dispatches tools, compacts context when the window fills, decides when to stop — is where the real capability differences now live, and it is genuinely hard to evaluate from outside. A benchmark score is a joint measurement of model and harness that reports a single number, which is precisely why two vendors can trade the lead by tuning scaffolding rather than weights.

The configuration surface is the one that costs you. Project instructions, permission allow and deny rules, MCP server definitions, hooks, subagents, skills, slash commands: you author all of it, the vendor defines its schema, and none of it transfers. A team six months into Claude Code has a CLAUDE.md per package, a permission policy tuned against real incidents, a dozen MCP servers wired up, and hooks enforcing house style. Moving that is not an install — it is a rewrite, performed by the people least interested in doing it.

Your repository and CI is the layer that outlives every agent you install, and the one worth investing in first. A checked-in setup script, a fast test suite and a review gate make every agent better and belong to you regardless of which vendor is in favour — which is the same conclusion background coding agents reaches from the other direction.

The four, on the axes that persist

Source and the right to keep running it

Codex CLI (Apache-2.0) and opencode (MIT) can be forked, pinned, audited and patched; Claude Code and Antigravity CLI cannot. In normal times this is abstract. It becomes concrete the day a vendor retires a flag your automation depends on, changes a default mid-week, or ends a tier. Note the asymmetry Codex carries: the harness is open, so you can pin it, but the models it talks to are OpenAI's, so pinning the harness does not pin the behaviour. Only opencode makes both halves yours, and only by accepting that you own the integration work the other three do for you.

Model choice, and what it is actually worth

opencode's design principle is that no model vendor owns it — Anthropic, OpenAI, Google or a local model, selected per session. Now that the leading models sit within a point of one another, that flexibility buys less capability than it did a year ago and more resilience than it did: a provider outage, a price change or a rate-limit cut becomes a config edit rather than a migration. The three single-vendor tools all deliver a tighter experience, because a harness tuned to one model family can assume things a portable one cannot.

Config portability, and the AGENTS.md exception

Codex CLI and opencode both read AGENTS.md — the convention OpenAI contributed to the Linux Foundation's Agentic AI Foundation alongside Anthropic's MCP and Block's goose. It is the one part of the configuration surface with a genuine cross-vendor story, and it is the cheapest hedge available: keep your durable project instructions in a plain, vendor-neutral file, and keep only the tool-specific mechanics in the tool-specific config. Everything below that line — permission schemas, hook formats, subagent definitions — remains proprietary in all four, which is why the honest advice is to write less of it, not to write it more portably.

Distribution stability, which is the one June actually tested

This is where the four separate most sharply and where past behaviour is the only evidence available. Antigravity CLI arrives with a demonstrated willingness to retire a tool, close the source and cut a free tier inside thirty days. Claude Code and Codex CLI have both shipped breaking changes but neither has removed a distribution channel out from under its users. opencode has no tier to cut, because you bring your own key — its failure mode is maintainer attention rather than a business decision, which is a different risk and a smaller one for a codebase with hundreds of contributors and north of 150,000 stars.

Read the axes together and the ranking inverts depending on your horizon. On a six-week horizon the two closed tools are ahead on every dimension a developer feels daily. On a two-year horizon the only questions that have mattered historically are "can I still run this" and "did the terms change", and on those the ordering is exactly reversed.

When to pick which

SituationPickBecauseWhat it costs you
Individual developer, interactive work, already paying a vendor Claude Code or Codex CLI Deepest harness, best ergonomics, one bill you already pay A config surface you will rewrite if you ever leave
Unattended runs in CI Codex CLI or opencode Open source means a pinnable version and a fork path if terms move More setup; you own the integration
Regulated, air-gapped or data-residency constrained opencode Point it at a local or in-region model; nothing else here can Weaker default model, more assembly
Standardising a large engineering org Two, deliberately A second working setup is the only real hedge against a thirty-day notice Two config surfaces to maintain
Already inside Google's stack with Code Assist licences Antigravity CLI Integration depth and an enterprise channel that was explicitly exempted in June A closed binary, and a vendor that has shown its notice period

What to do regardless of which one you pick

The choice matters less than four decisions that sit underneath it, and all four are portable.

Keep your durable instructions vendor-neutral. Architecture, conventions, the commands that build and test, the things a new contributor needs — those belong in AGENTS.md or an equivalent plain file that any tool can read. Tool-specific config should be thin enough to rewrite in an afternoon, and if it is not, that is a measurement of your exit cost rather than a sign of sophistication.

Pin the version in CI and treat an agent upgrade as a change. A terminal agent invoked by automation is a production dependency with a model inside it, and a floating version means your build behaviour changes when a vendor ships on a Tuesday. Version pinning plus a small eval suite you re-run on upgrade is the same discipline as model deprecation and migration, applied one layer up.

Own the permission boundary yourself. Every one of these tools has an allow/deny mechanism and every one of them expresses it differently. The controls that actually hold — a sandbox, a default-deny egress policy, a push-only token, no self-merge — live outside the agent and survive a swap. Configuring safety inside a vendor's schema is configuring it in the one place that does not transfer.

Run a second tool on something real, once a quarter. Not a bake-off — a working setup on a live repository, by someone who will notice if it breaks. That afternoon is the difference between a thirty-day notice being an inconvenience and being a quarter of unplanned work, and June demonstrated that the notice period is a real parameter rather than a hypothetical.

FAQ

Which terminal coding agent is the most capable in 2026?

On Terminal-Bench 2.1 the top two defaults are separated by 0.4 points — 89.5% for GPT-5.6 Sol at extra-high effort, 89.1% for Claude Opus 5 at max effort, both on the Terminus 2 harness. That gap is inside normal run-to-run variance, so the honest answer is that Claude Code and Codex CLI are equivalent at the top of the range and you should decide on other grounds.

What happened to Gemini CLI?

Google announced the consolidation at I/O on 19 May 2026 and stopped serving Gemini CLI requests for free, Pro and Ultra users on 18 June 2026. Organisations with Gemini Code Assist licences were exempt. The replacement is Antigravity CLI, a closed-source Go binary invoked as agy, with a migration tool that rewrites the old settings file into a new schema.

Is opencode a real alternative to the vendor CLIs?

Yes, with a trade. It is MIT-licensed, provider-agnostic, and reads AGENTS.md, so it is the only one of the four where both the harness and the model are your choice. In exchange you own integration work the vendor tools do for you, and the out-of-the-box experience is less polished.

Does an open-source CLI protect me from a model vendor's decisions?

Only partly. Codex CLI is Apache-2.0, so you can pin and fork the harness — but it talks to OpenAI models, so pricing, availability and model deprecation remain the vendor's call. Full independence requires both an open harness and a model you can point somewhere else, which today means opencode.

What should live in AGENTS.md rather than in tool-specific config?

Anything a new human contributor would also need: architecture notes, conventions, build and test commands, what not to touch. Keep tool-specific mechanics — permission schemas, hook formats, subagent definitions — as thin as you can, because that layer is proprietary in all four tools and is what a migration actually costs.

Should a team standardise on one terminal agent?

Standardise the durable layer — the instructions file, the test suite, the permission boundary, the CI gates — and keep a second tool working on a real repository. June showed that a notice period can be thirty days, which is enough time to migrate a person and not enough to re-qualify an organisation.

Further reading

On this wiki:

Project sources: