xAI shipped Grok Build into broad beta between May 14 and 25. That makes four — four serious terminal-native coding agents from the four largest model labs, all with overlapping feature lists, all priced within shouting distance of each other, all telling platform teams they’re the obvious default. If you’re the person deciding which one gets the seat budget and which one gets wired into CI, the marketing pages won’t help. They all promise plan mode, subagents, MCP, and headless runs.
I’ve been driving all four in anger for the last month — Claude Code on a Go monorepo I maintain, Codex CLI on a Python service rewrite, Grok Build on a Terraform refactor, and Gemini CLI mostly to see if it had caught up. Here’s the honest read.
Why the terminal tier deserves its own bake-off
The CLI agents and the IDE agents are not the same product. Cursor, Copilot, and Windsurf live in an editor window. They assume you have a mouse, a file tree, and a human in the loop on every diff. The CLI tier — Claude Code, Codex CLI, Gemini CLI, Grok Build — runs in your shell. That means tmux, vim, ssh, and most importantly, CI pipelines.
The terminal-native shape unlocks two real things. One, you can pair it with your existing tooling — kubectl, terraform, psql, your custom scripts — without bolting it into an editor extension. Two, you can run it headless in GitHub Actions or Buildkite, where it’ll review PRs, fix lint failures, or open follow-up issues with no human at the keyboard. That’s a different deploy surface from the IDE tier, and it’s the one platform engineers actually care about. So this comparison stays in CLI land. If you want the IDE breakdown, that’s a separate post.
A short timeline so the version anxiety makes sense
Claude Code went GA in late 2024 and has had the longest road. It’s been through several major rewrites — most recently the move to Sonnet 4.6 and Opus 4.7 backends, with the 1M-context Opus variant available on higher tiers. It’s the maturest of the bunch and the one most other tools are explicitly cloning.
Codex CLI got a full rewrite in January 2026. The old TypeScript implementation was retired and OpenAI rebuilt it in Rust, swapped the default model to the GPT-5 reasoning series, and added proper sandboxing on macOS via Seatbelt and on Linux via Landlock. It’s a different product than what people remember from late 2024.
Gemini CLI hit 1.0 in March. It rides on Gemini 2.5 Pro for the heavy lifting and Flash for the cheap stuff, and Google leaned hard on the 1M context window as the differentiator. It’s free for personal use up to a generous quota, which makes it tempting as the “try first” option.
Grok Build is the newcomer — beta in mid-May, broader availability May 25. It’s pitched at the speed-and-parallelism end of the spectrum, with Grok 4 Heavy as the planning model and a faster cheaper variant for execution. Six weeks of production use isn’t a lot, but it ships features the others don’t yet have at parity.
Plan Mode is where they split philosophically
Plan Mode is the new dividing line. The idea is the same across all four: before the agent edits anything, it writes a plan in prose, you read it, you approve it. The implementations are different in ways that matter.
Grok Build is the strictest. The agent will not edit files until the plan is explicitly approved, and the plan is a structured artifact — files it’ll touch, commands it’ll run, subagents it’ll spawn. If you push back, it rewrites and re-presents. This is great when you don’t fully trust the model and bad when you just want it to fix a typo.
Claude Code’s plan mode shows you a plan but lets you skip it. You can also stay in plan mode and have it iterate on the plan alone. It’s more flexible and, in my experience, faster for small tasks where the ceremony of formal approval is overhead.
Codex CLI’s loop is plan-edit-apply but the planning step is much lighter — closer to a thinking trace than a contract. You see the proposed diffs in batches and approve each batch. The auto-approve flag exists and is dangerous; people who run with it on are the same people who lose afternoons.
Gemini CLI uses checkpointing. The agent works, hits a checkpoint, you confirm or rewind. It’s the least formal of the four. If you’ve used Aider, the rhythm is similar.
My take: Grok Build’s strict mode is the right default for unfamiliar codebases or anything touching infra. Claude Code’s flexible plan is better for daily-driver work where you already trust the agent. The other two land in between and I don’t have a strong opinion on which is better.
Subagents and worktrees — what “parallel” actually means
This is the area with the most marketing noise and the least operator understanding. All four claim subagents. Only two have real parallelism.
Grok Build spawns subagents into isolated git worktrees by default. Each subagent has its own working tree, its own context window, and runs concurrently. Three agents researching different parts of a codebase finish in roughly the time of one. This is the headline feature and it works — but only on tasks that decompose cleanly. Ask it to “refactor the auth layer and update the docs” and you’ll get two parallel agents that occasionally fight over the same file.
Claude Code has the Task tool and added worktree isolation earlier this year. The Task tool spawns subagents, but in my testing they execute serially much more often than the docs imply, and the orchestration overhead eats some of the gain on small tasks. On large research tasks it pulls ahead.
Codex CLI’s “sub-tasks” are sequential. You can chain them but they don’t run concurrently. This is fine and clear; OpenAI hasn’t pretended otherwise.
Gemini CLI has a plugin-driven multi-step model that’s more like an orchestrator pattern than subagents. It can call out to other tools and other Gemini instances, but you’re wiring it yourself.
For research-heavy work — “explore this codebase and tell me how X works” — Grok Build’s subagent shape is genuinely faster. For implementation work, the difference is smaller than the marketing claims and worktree management starts to matter more than parallelism. Which brings us to the next section.
Worktree-based isolation and what breaks
Worktrees are useful because they let an agent (or a subagent) make changes without polluting your main checkout. Grok Build creates them automatically and cleans up on success. Claude Code’s EnterWorktree/ExitWorktree tools are explicit and the cleanup is more conservative — if the agent made any changes, the worktree sticks around so you can review.
What breaks: tools that don’t understand worktrees. If you have a precommit hook that runs git rev-parse --show-toplevel and assumes that path, you’ll see weird state. If you have a build cache keyed on the repo root, you’ll see cache misses. Most of this is fixable, but if your stack has a lot of repo-root-aware tooling, you’ll discover it the hard way the first time an agent runs in a worktree.
Codex CLI and Gemini CLI don’t push worktrees as the default. You can use them, but you’re managing the lifecycle yourself.
Context window in the real world
The vendor numbers don’t tell you what happens at scale. Here’s what I observed:
Claude Code on Sonnet 4.5 with the standard 200K window handles repos up to roughly 1.5GB before retrieval gets sloppy. The 1M Opus variant on the Max tier handles much larger trees, but the cost per task triples and the latency on long-context turns is real.
Grok 4 Heavy ships a longer effective window than the standard models, and Grok Build’s subagent decomposition is partly designed around stretching it further by parallel-summarizing rather than stuffing everything in one window. On a 2GB Terraform monorepo it kept its head clearer than Claude Code on Sonnet did.
GPT-5 in Codex CLI has competitive raw context but tends to compress aggressively on long sessions. You’ll notice it forgetting earlier file reads after the third or fourth turn.
Gemini 2.5 Pro genuinely uses its 1M window better than the others use theirs at the equivalent length, but retrieval quality drops past ~600K tokens in my testing — it gets fuzzy, not wrong, but fuzzy.
If you have a monorepo over a gigabyte, none of these tools magically reads the whole thing. They all do retrieval underneath. The right question is which one’s retrieval matches the shape of your repo, and the only answer is to try them on your code.
Real cost per seat at each tier
The pricing tiers shake out roughly like this as of June 2026, and the rate-limit walls are what actually decide it:
The $20 tier — Claude Pro, ChatGPT Plus, Gemini Pro, basic Grok — gets you a real agent that you’ll hit the limit on by mid-afternoon if you’re using it as a daily driver. Fine for hobbyists or people who use it for two-hour bursts.
The $100 tier — Claude Max, ChatGPT Pro, equivalent Grok and Gemini Advanced bundles — is the actual professional tier. Claude Max in particular ships with 5-hour rolling limits that, in my experience, hold up for a full coding day if you’re not running parallel subagents constantly.
The $200–300 tier — Anthropic Max highest, OpenAI Codex Pro, SuperGrok Heavy — is for people who run agents headlessly in CI or who genuinely chew through context all day with subagents. If you’re not doing one of those two, you’re overpaying.
A specific thing that surprised people: running Grok Build with three concurrent subagents at full Grok 4 Heavy will burn through the $100 tier in about three hours of active use. The parallelism is a real productivity win but the bill scales with it. Claude Code’s serial-by-default Task tool ends up cheaper per task at the same tier even though it’s slower wall-clock.
For team standardization, the per-seat math usually says either Claude Max or ChatGPT Pro depending on which model your engineers already prefer. Grok Heavy is worth it for teams doing lots of parallel research or multi-repo work; Gemini Advanced is the cheapest credible option if your team is already on Google Workspace.
Headless mode for CI is where the real differences live
This is the part the marketing pages skip and the part that matters most for platform teams. Wiring an agent into GitHub Actions to act as a PR reviewer or autonomous bug-fixer is genuinely different across the four.
Claude Code has the most mature headless story. claude -p "review this PR" with --output-format json gives you structured output, deterministic exit codes, and the ability to pipe results into anything downstream. Auth is API-key-in-env-var or, for enterprise, OIDC-based auth against Anthropic’s auth service. The permission flags (--allowedTools, --disallowedTools) work cleanly. I have Claude Code running as a step in three different repos and it’s the only one I’ve never had to wrap in a babysitter script.
Codex CLI’s headless mode shipped properly after the Rust rewrite. JSON output is solid, sandboxing is the strongest of the four on Linux (Landlock-based), and exit codes are usable. The auth story is API key only as of this writing — no OIDC yet.
Grok Build has a headless mode and JSON output, but the subagent orchestration in headless mode is less stable than interactive. I’ve seen it deadlock on parallel subagents that race for the same lock; in interactive mode the UI breaks the deadlock, in headless it just hangs. Worth using for simple review tasks, not yet trustworthy for autonomous fixes.
Gemini CLI’s headless story is the weakest. The CLI works non-interactively but the output format is less structured and the auth flow assumes Google Cloud OAuth, which is annoying for non-GCP shops.
If you’re standing up an agentic CI today, Claude Code is the path of least resistance. Codex CLI is a close second if you’re already on the OpenAI API. The other two are interactive-first products that bolted on a headless mode.
MCP and tool ecosystem
All four support MCP servers, but the support quality varies. Claude Code defined the MCP integration shape and has the most servers and the most stable behavior. Codex CLI’s MCP support is solid after the rewrite. Grok Build added it later in beta and the server discovery story still has rough edges. Gemini CLI supports MCP but also has its own plugin format, which means some Google-flavored tools come as plugins instead of MCP servers and you end up with a split ecosystem.
For the “can I make it run kubectl/terraform/psql against staging” question — all four can, with the right MCP servers or custom tool definitions. None of them have a meaningfully better story here. The friction is in writing the tool definitions, which is roughly equivalent everywhere.
Safety and audit
If you’re procuring this for an org that cares about SOC 2, the audit surface matters. Claude Code and Codex CLI both have organization-level audit logs (Claude Code via the Anthropic Console, Codex via the OpenAI dashboard) that capture every tool call. Grok Build’s audit log exists but is less detailed as of June 2026. Gemini CLI’s audit goes through GCP audit logs if you’re on Workspace, which is either great or terrible depending on whether you have a GCP admin.
File-write confirmations and command allow-lists are present in all four. Network policy is best in Codex CLI thanks to the sandboxing. Secret redaction in logs is best in Claude Code; the others will happily echo your .env if you cat it.
The honest pick by role
Solo indie shipping fast on greenfield code — Grok Build. The plan mode keeps it honest, subagents genuinely speed up exploration, and the parallel research shape is well-suited to “throw a problem at it and let it cook.”
Senior IC on a complex existing codebase — Claude Code. The reasoning quality on Sonnet 4.6/Opus 4.7 is still the best for surgical edits in code you actually have to maintain. The maturity of the headless mode is a bonus if you want to put it in CI too.
Team standardized on OpenAI infra — Codex CLI. Especially after the Rust rewrite. The sandboxing is class-leading and the cost shows up on a bill you already have.
Google Cloud / Workspace shop — Gemini CLI. The 1M context is genuinely useful on large monorepos, and the Workspace integration matters more than the slight maturity gap if your auth and audit already go through Google.
And here’s the underrated answer: multi-CLI workflows beat single-vendor for serious teams. Several shops I work with run Claude Code as the IDE-coupled daily driver, Codex CLI in CI for the sandboxing, and Grok Build as the on-demand research/exploration tool. The CLIs compose because they’re all just programs in your shell. The vendor lock-in fear that drives single-CLI standardization mostly evaporates once you treat them as interchangeable tools rather than platforms.
If you want a single experiment to start with, pick the one that pairs with the model your team is already paying for, and add a second only when you hit a specific gap.