Getting started with Grok Build's plan mode

Published 2026-05-18 by Owner

Grok Build entered beta on May 14 for SuperGrok Heavy subscribers. This walks through a first session and, more importantly, where a brand-new agent should sit next to a tool you already trust. For what shipped and the pricing, see xAI ships Grok Build.

Who should try it now

Try it now if you already pay for SuperGrok Heavy and you have a self-contained task — a refactor, a test suite for one module, a mechanical migration — that an agent can run end to end without constant steering.

Wait for general availability if you would be subscribing only to evaluate it, or if you need editor or Git-host integration. Grok Build is terminal-only during the beta: no IDE extension, no pull-request surface, no shared team state. A $300/month subscription is a steep way to run one trial.

Install and check the version

xAI distributes Grok Build through its own CLI installer. A beta installer and its flags change week to week, so take the install and authentication steps from the official page rather than a copied snippet:

# Official source of truth for install + auth:
#   https://x.ai/news/grok-build-cli
grok --version
grok --help

grok --help is the authoritative list of subcommands for the build you actually installed. Read it before your first run — the beta’s command surface is still moving, and a guide that hardcodes flags will be wrong within a release.

Use plan mode deliberately

The one behavior xAI has documented and committed to is plan mode. For any non-trivial task, Grok Build drafts an execution plan and stops. You get three moves before a single line is written:

• Approve the plan as-is and let the agents execute.
• Comment on a specific step so the agent revises that step only, leaving the rest intact.
• Rewrite the plan yourself and hand the edited version back.

Use the comment and rewrite paths on your first few runs even when the plan looks fine. The point of plan mode is not speed — it is catching a wrong assumption before eight agents act on it in parallel. A bad plan executed by eight workers is eight times the cleanup.

Review the diff before it lands

Grok Build presents completed work as a reviewable diff rather than writing straight to your branch. Read the whole diff, not the summary. An eight-agent run produces more change per session than a single-threaded agent, and the characteristic failure mode of parallel agents is a plausible-looking diff that quietly crosses a boundary you cared about — a renamed export, a touched config, a “helpful” refactor you did not ask for.

Apply the change only after you have read it end to end. If you applied and regret it, recover through your own version control — a branch or a commit you made before the run — not through the agent. Make that commit before you start; an agent is not a backup.

Run it beside your current agent, not instead of it

For the first week, do not replace your main tool. Give Grok Build the same task you would give the agent you already use, on its own branch, and compare the two diffs:

git switch -c grok-trial
# run Grok Build on the task, review, apply
git switch -c main-agent-trial main
# run your usual agent on the same task
git diff grok-trial main-agent-trial

Comparing diffs on identical work tells you more in an afternoon than a week of reading launch posts. You are looking for two things: which agent’s output you would actually merge, and which one needed less correcting to get there. The second matters more — raw capability is cheap, low-supervision capability is not.

This is the same parallel-run discipline that works for any new agent. The workflow in Running parallel coding sessions with Claude Code Agent View applies directly: let the newcomer prove itself on real work, next to a known quantity, before you trust it on its own.