# The Grok Build name does not identify one runtime

Why Grok Build’s open terminal harness and later web/mobile Build Mode need separate runtime descriptions despite sharing a product-family name.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-19
Original announcement: https://x.ai/news/grok-build-for-everyone
Canonical URL: https://retrivium.ai/retrospectives/grok-build-surface-runtime-differences/

The earlier open Grok Build harness and the August consumer expansion appear in the same product history. A useful retrospective keeps their surfaces distinct instead of treating every mention of Grok Build as one interchangeable runtime.

## The dated path

- 2026-07-15: [Grok Build is Now Open Source](https://x.ai/news/grok-build-open-source).

- 2026-07-28: [Introducing Build Mode](https://x.ai/news/grok-build-mode).

- 2026-08-19: [Grok Build expands to web and mobile on every plan](https://x.ai/news/grok-build-for-everyone).

## The surface defines the available operations

A terminal workflow can interact with a repository and local environment under its own configuration. A consumer creation interface exposes a different set of operations and artifact-handling choices. Our interpretation is that the later expansion changes who can create an artifact and where they interact with it, without proving identical internals. A reader should identify the actual surface before applying a capability claim, an instruction or an assumption about where the generated work executes.

## Open code and consumer availability are different facts

Publishing a harness can make one implementation inspectable, while broad access to a product makes an interface available to more users. Neither fact automatically establishes that the hosted service runs the same version or exposes the same permissions. This is a source-interpretation boundary, not a claim of hidden incompatibility. The dated milestones support a history of expanding workflows. A stronger claim about code parity or deployment architecture would need its own evidence rather than an inference from the common name.

## A counterfactual with an identical task

Ask two surfaces to produce an equivalent small application, then inspect the artifacts, execution state and available review operations. Differences can arise from the surface contract even if some underlying model capability is shared. The comparison should state what each environment permits rather than assume that a missing operation is a model failure. It should also distinguish a live preview from an exported or published artifact, since those objects can have different lifetimes and different access conditions even within one product family.

## What infrastructure documentation should identify

A useful record names the surface, version where available, execution context and resulting artifact type. This allows an operator or researcher to compare like with like. The July harness and preview milestones provide context for the August expansion without collapsing their roles. The broader historical lesson is that agent products grow through several interfaces, not merely through successive model names. Precise runtime descriptions make that growth understandable and prevent a successful demonstration on one surface from becoming an unsupported promise about another surface with a different contract.

## Technical background

Related engineering context: [Local agent environment](/journal/aider-local-model-editing-start/); [Runtime boundaries](/journal/read-only-container-writable-caches/).