Grok WorldGrok Build CLI field station
SIGNAL LOCKED
NAV

GROK BUILD CLI / 14

Plan Grok Build work with the live model catalog

Model-aware planning starts from live evidence and continuity. Model, effort, subagents, and authority are separate controls, and none should silently widen another.

CHANNELCONFIGURATION CONTROL / INTERMEDIATE / 17 MIN
SOURCES CHECKED2026-10-21
ORIGINOFFICIAL DOCS / PRIMARY

Start from a dated, account-specific catalog

The authenticated grok.com runtime captured on 2026-10-22 with Grok Build 1.0.67 (2fe064390d07) lists four models in grok models: grok-4.7 (marked default), grok-4.7-build-fast, grok-4.6, and grok-4.5. The command prints only IDs and the default marker, so effort support comes from xAI’s model documentation: grok-4.7 and grok-4.6 accept low, medium, high, and xhigh with default high; grok-4.5 accepts low, medium, and high with default high and treats an xhigh request as high.

grok-4.7-build-fast (Grok 4.7 Fast) is the same Grok 4.7 model served at higher output speed. xAI offers it only in Grok Build and Cursor, not on the public xAI API, and bills it through your plan at 2x the standard token rates (1.5x for long-context requests). Its effort levels are not documented separately, so treat them as inferred from grok-4.7.

This is a release/account snapshot, not a promise about every account or a future build: the 2026-08-10 capture with Grok Build 1.0.0 returned only grok-4.5. Record grok --version, then run grok models immediately before automation or evaluation. If the live result differs, the live account catalog wins; do not invent a remembered model ID or effort level.

grok --version
grok models

Route continuity first

Keep work in the current Grok session and repository when it already holds relevant decisions, tool results, and uncommitted state. Switch CLI or start a new session only for a concrete native workflow, an explicitly requested independent review, or a boundary the current session cannot satisfy.

For this catalog, use low for mechanical inventory or formatting, medium for bounded ordinary work when you intentionally override the default, high for ambiguous architecture, hard debugging, security-sensitive review, or the unchanged model default, and xhigh only on grok-4.7 or grok-4.6 for the hardest single problems where answer quality matters more than latency. More effort spends more reasoning on the same model; it does not create subagents. grok-4.7-build-fast trades cost for output speed on the same model; it is not a deeper tier.

  • Continuity first: account for context-transfer and verification cost before switching.
  • Effort != delegation: configure --agents or subagents separately, and use --no-subagents when the task must stay single-agent.
  • Permission invariant: model and effort selection never upgrades sandbox, tools, approval, or credentials.

Use one-shot mode without widening authority

The released -p/--single option is a single-turn prompt: it prints the response to stdout and exits. It is not a model preset, permission flag, or delegation mode.

For read-only analysis, state both the read-only sandbox and plan permission mode. For an authorized implementation, keep the workspace sandbox and normal default permission decisions. Selecting high or xhigh effort never justifies --always-approve or a permission bypass.

grok --model grok-4.7 --reasoning-effort low --sandbox read-only --permission-mode plan -p "Inspect the repository and report evidence only."

grok --model grok-4.7 --reasoning-effort high --sandbox workspace --permission-mode default -p "Implement the scoped change, run affected tests, and report the diff."

grok --model grok-4.7 --reasoning-effort xhigh --sandbox read-only --permission-mode plan -p "Find the root cause of the failing test and report evidence only."

Ask Knowledge MCP for catalog evidence first

After connecting AI Worlds Knowledge MCP, call worlds_list_cli_models with grok-build before requesting a plan. Read its capture date, supported efforts, availability warning, selectors, and sources; then compare the result with grok models on the actual account.

Call worlds_plan_cli_work with the active CLI and only the CLIs actually available. Workstreams default to read-only; use execution_intent may-edit only for an already-authorized implementation. Its output is advisory: inspect its assignments, dependencies, model fallback, permission boundary, and verification gate. The tool does not launch Grok, grant permission, or prove live entitlement.

worlds_list_cli_models
{"products":["grok-build"]}

worlds_plan_cli_work
{"task":"Inventory the repository, implement the bounded fix, and verify it","current_cli":"grok-build","available_clis":["grok-build"],"workstreams":[{"id":"implementation","goal":"Implement the bounded fix and run affected tests","execution_intent":"may-edit"}],"strategy":"continuity-first","risk_tolerance":"low","execution_environment":"local-workspace","require_independent_review":false}

Fail closed on catalog or capability drift

If an explicit selector is absent from the live catalog, stop before launching it. Either use an ID returned by grok models or omit --model and retain the live default. If effort support cannot be confirmed, omit the override rather than guessing.

Re-run the repository tests after any write and verify the resulting diff. A successful model response is not proof that the task passed, and a model change must never rewrite project policy or expose credentials.

  • Treat malformed or empty model output as uncertainty, not permission to use a stale ID.
  • Keep model, effort, delegation, and permission evidence in separate plan fields.
  • Record the effective effort: an xhigh request on grok-4.5 runs as high.
  • Recheck the catalog after CLI updates, account changes, or policy changes.

Keep durable configuration narrow

The settings reference documents models.default as the model for new sessions and models.default_reasoning_effort as the default effort for that default model; --model and --reasoning-effort/--effort apply to the current launch, while /model and /effort are TUI controls. Prefer a one-run choice until a team has validated a shared default.

Custom model entries can use model.<id>.env_key to name an environment variable. Prefer that indirection to literal credentials in api_key or extra_headers, and restrict the logs, debug files, environment, and child processes that can read it.