Grok Build 0.1: The Coding Model Behind the grok-code-fast Aliases

If you wired grok-code-fast-1 into an editor or agent last year and never touched the config again, you may already be running Grok Build 0.1 without knowing it. xAI's model documentation lists grok-code-fast-1, grok-code-fast and grok-code-fast-1-0825 as aliases of grok-build-0.1. A request to the old name resolves to the new model: xAI retired grok-code-fast-1 on 15 May 2026 and routes its traffic to Grok Build 0.1.

A note on names: xAI, the company behind Grok, was renamed SpaceXAI in July 2026 after SpaceX acquired it. This guide uses the xAI name throughout.

That is convenient, and it is also the single most important thing to know about this model. A silent model swap behind a stable name changes output style, token usage and failure behaviour without a diff anywhere in your repository. This guide covers what is published about Grok Build 0.1, what it costs, and how to check whether the swap helped or hurt your workload.

What is actually published

xAI describes Grok Build 0.1 as a coding model for agentic software engineering and workflow tasks. OpenRouter, where it is listed under the SpaceXAI name, calls it a fast coding model trained specifically for agentic software engineering. xAI's release notes introduced it in May 2026 as an early-access model, and it appeared in the OpenRouter catalogue the same month.

The documented specification is short:

• Context window — 256,000 tokens.
• Input — text and images; output is text.
• Features — reasoning, function calling and structured outputs.
• Regions — us-east-1 and us-west-2.
• Weights — not published. This is an API-only model.

What is not published, in anything I could find, is a parameter count, an architecture description or a vendor benchmark table. That is unusual for a 2026 coding model, when most labs lead with SWE-bench and Terminal-Bench numbers. It means you cannot shortcut the evaluation by reading a chart, which is arguably no loss: vendor charts on vendor harnesses were never a reliable predictor of how a model behaves in your loop.

Two price tiers, split at 200K

xAI prices Grok Build 0.1 per million tokens in two bands:

• Prompt under 200K tokens — $1.00 input, $0.20 cached input, $2.00 output.
• Prompt at or above 200K tokens — $2.00 input, $0.40 cached input, $4.00 output.

OpenRouter listed the lower band at the time of writing. Prices move, so check before you budget.

The detail that catches people is in xAI's wording: once a prompt reaches 200K tokens, the higher rate applies to all tokens in that request, not just the ones above the line. A 199K-token prompt and a 201K-token prompt differ by about 1% in size and 100% in price.

For an agent, that threshold is not a hypothetical. Transcripts grow every turn, and a session that starts at 40K tokens can cross 200K after a few dozen tool calls on a large repository. If you run long sessions, compact the context before it crosses the line rather than after. The token cost of long context covers when filling a large window pays for itself, and in this case the answer has a hard edge.

The cached-input rate is the other lever. At a fifth of the input price, a stable system prompt and tool schema that hit the cache every turn make a real difference over a long loop. Prompt caching explained covers how to structure prompts so the prefix actually stays cacheable.

No batch endpoint, generous rate limits

xAI's documentation says Grok Build 0.1 does not support the Batch API. If your plan was to run overnight bulk refactors at a discount, this is not the model for that job — you pay the interactive rate for everything.

On the other side, the published default limits are high: 37 requests per second and 10 million tokens per minute. For a team running many concurrent agents, the bottleneck is more likely to be your own orchestration than the provider. Your account's actual limits may differ from the documented defaults, so read them from the console rather than assuming.

How to evaluate it without a benchmark table

With no vendor numbers to anchor on, the honest approach is to build your own comparison. If you were on grok-code-fast-1, you have a natural baseline: your logs from before the alias changed.

1. Pull ten to twenty completed agent tasks from your history, ideally ones with a clear pass condition such as a test suite going green.
2. Re-run them on grok-build-0.1, explicitly named, against the same starting commits and the same harness.
3. Record turns to completion, total input and output tokens, and whether you would merge the result unchanged.
4. Compute cost per completed task, not cost per token. A model that is cheaper per call but needs more calls is not cheaper.
5. Check how often a session crosses 200K prompt tokens, because those runs cost double.

How to benchmark LLMs on your own work has the full harness setup. If you want to compare against other agent-focused models, agentic coding models compared covers what separates them over a long loop.

Pin the name you mean

The alias arrangement is a good reason to audit every place you reference a Grok model. Aliases are useful when you want automatic upgrades and harmful when you need reproducibility. For production agents, CI jobs and anything you compare over time, call grok-build-0.1 directly so the next change is one you make on purpose.

Decision rule

• Use it for interactive agentic coding where prompts stay under 200K tokens and you value low per-token cost with high concurrency.
• Look elsewhere for bulk asynchronous work, since there is no batch discount, or for jobs that need open weights or self-hosting.
• Watch closely if your sessions routinely run long. Budget for the higher band or add compaction before 200K.

The model may well be an upgrade over what it replaced. The point is to know rather than assume, and an alias makes assuming very easy.