You can swap the model inside a coding agent, but what actually determines its behavior is the harness: how context is assembled, how model responses are parsed, how tool calls are dispatched, and how failures are handled. On July 15, xAI announced that Grok Build is now open source, publishing the complete source of the coding agent and its TUI on GitHub. This is not the “closed core, open shell” style of open-sourcing — the announcement states that the published code spans the full mechanics from context assembly to tool-call dispatch.
What was open-sourced: four blocks forming a complete agent loop
The codebase reads naturally as four blocks. The first is the agent loop itself: how context is assembled, how model responses are parsed, and how tool calls are dispatched — the heart of a harness, and the reason the same model performs differently when the harness changes. The second block is the tools: reading, editing, and searching code, plus executing commands, with each tool’s input and output contract in the source. The third is the terminal UI: rendering, input handling, plan review, and the inline diff viewer that let a human inspect what the agent intends to change. The fourth is the extension system: how skills, plugins, hooks, MCP servers, and subagents are loaded and invoked.
Together, the four blocks are a complete cross-section of a working coding agent — something rarely available in this space, where comparable products are either closed-source or publish only an SDK layer. Read side by side, they also show the division of labor: the loop explains why the same model performs differently under different harnesses; the tools define the agent’s real attack surface, since reading, writing, and command execution are all high-privilege operations; the TUI is where human judgment enters the flow, with plan review and inline diffs acting as interception points; and the extension system decides where the ecosystem’s boundaries sit.
Why open source: reliable harnesses grow out of source code
The official argument is worth quoting as stated: open-sourcing is the most direct path to a robust and reliable harness. Two implications sit underneath that sentence. First, harness reliability is not something documentation can guarantee — docs can describe an extension format, but load priority, error-handling paths, and permission boundaries, the details that actually determine behavior, exist only in the source. Second, the announcement positions the source itself as the definitive reference for the extension ecosystem: wherever docs lag or read ambiguously, the code is the authority.
For adopters, the practical gain is auditability. Whether a hook can modify the prompt, which context an MCP tool receives, and what a subagent inherits from its parent are now questions you answer by reading code, rather than by behavioral guesswork or support tickets.
Local-first: self-compiled, local inference, one config.toml
The announcement’s other headline is a fully local-first path: you can compile Grok Build yourself, point it at local inference, and drive all configuration from a single config.toml. For privacy-sensitive or cost-sensitive setups this is the dividing line — data can stay on the machine entirely, with no cloud quota to pay for. A single config.toml driving all configuration adds a third layer: setup has one source of truth, agent behavior becomes reproducible and version-controlled, and teams can exchange a whole config file instead of reconstructing an environment from verbal descriptions.
Local-first is not automatically safe, though, and the boundary is yours to draw: a locally running agent can still read the wrong directory, execute a dangerous command, or leak environment variables. Open source gives you the ability to audit those behaviors; the audit itself remains your job. Sandbox isolation, command allowlists, and secrets handling should each be verified before real deployment.
Who should read this codebase
Three audiences benefit most. Builders learning agent loop design should read the first block: the trade-offs in context assembly and tool dispatch are the hardest parts to learn from documentation alone. Extension authors should read the fourth block: how all five extension mechanisms are loaded and invoked, with the source as the definitive reference. Local-first operators should read the configuration path: the compile-it-yourself, local-inference combination is a complete alternative to cloud dependence.
Two practical cautions: the announcement does not state license terms or a version number, so confirm the license before depending on the code; and rather than forking the whole repository into a maintained branch, most teams get more leverage from treating it as harness study material — comparing its context assembly and tool contracts against their own. Models change every quarter; harness design patterns persist. That is where this source release holds long-term value.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.