xAI open-sourced Grok Build on July 15, 2026 — a terminal-based coding agent powered by Grok 4.6, with a fullscreen terminal UI, native subagent support, plan mode, and deep git worktree integration. On paper, it reads like a direct clone of Claude Code’s feature list. That’s not an accident: the entire category of “agentic CLI” has converged on the same shape over the past year — plan first, delegate to subagents, isolate work in worktrees, expose everything over MCP. What’s interesting isn’t the shape, it’s what each vendor does differently inside it. I ran Grok Build against Claude Code for a week on a real refactor — splitting a monolithic Express service into modules — and want to walk through where they actually diverge.
The shape is identical, and that’s the story
Both tools start a task in a planning phase where every file edit is blocked until you approve the plan. Both let you comment on individual plan steps or rewrite the whole thing before a single line of code changes. Both delegate large tasks to subagents that run in parallel, each with its own context window, and both can launch those subagents in their own git worktrees so parallel work doesn’t collide on the same files. This convergence tells you something: after a year of trial and error across the industry, “plan → isolate → parallelize → verify” has become the accepted architecture for agentic coding, the same way REST converged on verbs-and-resources. If you’re evaluating a new agentic CLI tool six months from now, expect it to look like this too.
Where Grok Build actually differs
The most concrete difference I found is subagent concurrency: Grok Build explicitly documents support for up to eight parallel subagents on a single task, versus Claude Code’s more conservative default fan-out. For the module-splitting refactor — extract eight route handlers into eight separate files, each needing its own test file and import updates — Grok Build’s higher parallel ceiling meant it finished the mechanical extraction pass noticeably faster wall-clock, because more of the independent file-pairs were literally running at once rather than queuing.
But faster isn’t the same as better, and this is where the week got interesting. With eight subagents running truly in parallel against the same monorepo, two of them made incompatible assumptions about a shared utility function’s new signature — one subagent updated the function to take an options object, another assumed it still took positional arguments, and neither one’s context window included the other’s in-progress edit. Claude Code’s more conservative default concurrency meant fewer of these collisions in the same session, simply because there was more sequential ordering and thus more opportunity for a later subagent to see an earlier one’s finished output before starting. Neither failure mode is intrinsic to the model — it’s a scheduling and context-sharing tradeoff, and it’s the one thing I’d tell any tech lead evaluating these tools to test explicitly before trusting either one on a shared codebase: give it a task that requires touching a common interface from multiple angles at once, and see whether it catches its own inconsistency before you do.
Extensibility: near-parity, one real gap
Grok Build bundles skills, agents, hooks, and MCP servers behind a single install and supports a marketplace model alongside self-hosting from any git repo — functionally very close to Claude Code’s plugin and MCP story. I wired both tools to the same Postgres MCP server and a Sentry MCP server for the refactor, and both picked up the tool definitions without friction. The gap I found wasn’t in the extensibility mechanism itself, it was in maturity of the surrounding ecosystem: Claude Code’s MCP marketplace has had roughly a year more time to accumulate community-maintained servers for niche internal tools, so for any team already running custom internal MCP servers, migration cost is close to zero either way — but if you’re starting from scratch and want to lean on pre-built integrations, Claude Code currently has the deeper catalog.
What this means for tool selection
Grok Build being open-sourced changes the calculus more than any individual feature does. Self-hosting from any git repo means a platform team can fork it, strip telemetry, add internal auth, and ship it as an approved internal tool without waiting on a vendor roadmap — that’s a real option for regulated environments where “the agent CLI’s source code is auditable” is a procurement requirement, not a nice-to-have. If that constraint doesn’t apply to you, the honest answer after a week of side-by-side use is that the choice comes down to which model’s output you trust more for your specific stack, not which CLI wrapper is objectively better — the wrapper architecture has converged enough that it’s no longer the differentiator.
Hands-on takeaway
If you’re a tech lead deciding whether to standardize your team on one agentic CLI, don’t evaluate based on the feature list — plan mode, subagents, and worktree isolation are table stakes now, not differentiators. Evaluate based on two things instead: how the tool behaves when multiple subagents need to agree on a shared interface mid-task (this is where real bugs come from), and whether self-hosting or auditability is an actual requirement for your environment. Everything else is close enough to a wash that model quality on your specific codebase should decide it, not the terminal UI.