Grok Build Architecture Deep Dive — 250K Lines of Production Rust, Exposed by a Privacy Scandal

A task that only needed 192 kilobytes of

code, but the AI agent uploaded 5.1

gigabytes, your entire project,

including SSH keys, API tokens, and

database passwords, all sent to the

cloud without consent. That was the

Grock build privacy scandal. But the

code they were forced to open source, it

reveals genuinely brilliant

architecture. 79 rust crates, over

250,000 lines of production code. Let's

break it down.

Welcome to this deep dive into Grock

Build's architecture, how it works

internally, and how it compares to

Claude code. Whether you're picking a

tool for your daily workflow or building

AI tools yourself, understanding these

architectural patterns will help you

make better decisions. We'll cover the

actor model, kernel level sandboxing,

sub aent orchestration, context

management, and more. Let's get started.

First, some context on how we can even

read this code. In May 2026, SpaceX AAI

launched Grock Build as a public beta. 2

months later, security researchers at

Surlab discovered it was uploading 5.1

GB of data for a task that only needed

192 kilobyt entire Git histories, SSH

keys, and secrets, all sent as Git

bundles to Google Cloud Storage. The

story went viral on July 14th. the

register, the Verge, everyone picked it

up. Musk promised complete deletion of

the data and the very next day, SpaceX

open sourced the full code base under

the Apache 2.0 license. The silver

lining, we now have over 250,000 lines

of production Rust code to study. Let's

see what's inside.

Here's Grock Build at a glance. It's

written entirely in Rust edition 2024

with strict clippy linting. The code

base is organized into 79 crates with

over 250,000 lines, not counting tests

and generated files. It uses Tokyo as

its async runtime for multi-threaded

execution. The terminal interface is

built with Ratatouille, giving you a

full screen terminal UI with scrollback,

prompts, and permission modals. The

default model is Grock 4.5 with a

500,000 token context window. And of

course, it's now fully open source under

Apache 2.0. know you invoke it simply by

typing grock in your terminal.

Before we dive into the differences,

let's understand the universal pattern

that both tools share. The agentic loop

you type a prompt. The AI thinks about

what to do. It takes an action, reading

a file, running a test, editing code. It

checks the result and if it's not done,

it loops back to the thinking step and

tries again. This cycle repeats until

the task is complete. The key insight is

that the AI acts autonomously within

boundaries you set. Your permissions

define what actions are allowed. Both

Claude Code and Grock build implement

this exact pattern, but with very

different architectural choices

underneath. Claude Code uses a

Typescriptbased singlethreaded event

loop on the bun runtime. Grock build

uses a Rustbased multi-threaded actor

model running on Tokyo. That's a

fundamental difference we'll explore

next.

Grock build goes beyond just typing in

the terminal. It offers five deployment

modes, each serving a different

workflow. First, interactive mode, the

default when you type Grock. It gives

you a full screen terminal UI with

scroll back, prompts, and permission

modals. Second, headless mode. You pass

a prompt with the -p flag. It runs

non-interactively and exits. Perfect for

CI and automation pipelines. Third, STIO

ACP. This is the agent communication

protocol. a JSON RPC protocol over

standard input and output. IDE

extensions for VS Code and Jet Brains

connect through this. Fourth, the leader

Damon, a longunning background process

that keeps your sessions alive. We'll

explore this one in detail next. And

fifth, a websocket server for remote

access from any machine authenticated

with a shared secret.

The leader Damon is Grock Build's most

interesting deployment feature. Imagine

you're in the middle of a complex coding

task. Your terminal crashes and you lose

all your inprogress work. Frustrating,

right? Grock Build solves this with a

persistent background process that holds

all your session state. Your terminal,

the UI you see, just connects to the

Damon. If the terminal crashes, you

simply reconnect to the leader and pick

up exactly where you left off with full

state replay. Multiple clients can

connect to the same Damon

simultaneously. Your terminal, your IDE

extension, a websocket client from

another machine. They all talk the same

ACP protocol to the same stateful

process. Think of it this way. Claude

code is like a local document. Your work

is saved, but if the app crashes

mid-action, that in-flight operation is

lost. Grock build is like Google Docs.

The server holds the state. So even if

your browser tab dies, you reconnect and

everything is still there. Now let's

look at how the process architecture

differs fundamentally between the two

tools. Claude code uses a singlethreaded

event loop. One query engine controller

manages the conversation. The loop runs

serial turns, but tool calls within a

single turn can execute in parallel

batches. It's TypeScript running on the

bun runtime. Simple, predictable, easy

to reason about. Grock build uses an

actor model on Tokyo, Rust's

multi-threaded async runtime. Each

session runs on its own dedicated

thread. They never share state. The MVP

agent acts as an ACP server, spawning

isolated sessions that communicate only

through message passing. Here's the

analogy. Each session in Grock Build is

like a person in their own room with

their own desk. They never share papers.

They just pass notes through a slot in

the door. One person having a bad day

can't mess up another's work. The

practical difference. Claude code runs

one process per conversation. Grock

build runs multiple fully isolated

sessions within a single leader process.

Both tools use the same everything is a

tool pattern. When the AI wants to read

a file, it calls a read file tool. When

it wants to run npm test, it calls a

bash tool. Every capability is a tool.

Why? Because every tool goes through the

same pipeline. The model makes a

request, inputs get validated,

permissions are checked, the tool

executes, and results are formatted and

returned. Adding a new capability is

just adding a new tool. It automatically

inherits permissions, logging, and error

handling for free. Looking at the tool

categories side by side, both have file

operations, code execution, web access,

and sub aents. Grock Build adds media

generation tools like image gen and

image to video. In total, Claude Code

has over 40 tools and Grock Build has

over 45. The key takeaway, if you're

building your own AI tools, adopt this

pattern. It gives you extensibility

without complexity.

Here's a clever problem both tools face.

When a tool reads a 500line file or runs

a test suite, it dumps a lot of text

into the AI's context window. that eats

up the limited memory the AI has to work

with. Grock Build solves this with what

I call the concise namespace trick.

Every tool has two output methods. Model

output, what gets sent to the AI, and

chat completion output, what gets shown

to you. The concise variants like bash

concise and read file concise send

deliberately stripped down results to

the AI while you still see the full

output. This prevents context bloat from

the start.

Claude code takes a different approach.

It uses tool search to load tool schemas

on demand. Most tools are hidden until

needed, saving input tokens. Then it

uses retroactive trimming. Old tool

results get compressed when context gets

tight. The trade-off is clear. Grock

build truncates up front so the AI gets

less context but avoids bloat. Clawed

code gives the AI full context early for

better reasoning then compacts later

when space runs out. Both are valid

approaches. It depends on whether you

prefer prevention or cure.

Context management is the hard problem

in AI agent engineering. Think of it

like pair programming with someone who

has limited short-term memory. After a

while, they start forgetting what you

discussed earlier. You need a strategy.

Claude code uses a six-level compaction

cascade. It starts with cheap

strategies. capping tool result size,

snipping old history, and escalates only

when needed through micro compaction,

context collapse, session memory

compaction, and finally a full reset as

a last resort. It's fully automatic, no

configuration needed. Grock build takes

a manual approach with three

configurable modes. Basic mode

summarizes all turns at once. Intrturn

mode keeps the most recent K turns

verbatim and summarizes the rest. And

the most powerful mode, interturn

segments, breaks the conversation into

semantic chapters. The segments approach

is unique. Think of it like chapters in

a book. Completed chapters get

summarized to disk. Only the current

active chapter stays in full detail.

This lets very long sessions, hours of

work remain manageable. The key

difference, Claude code autoes escalates

within a session. Grock Build lets you

pick the strategy up front and segments

are its most powerful trick for long

sessions.

The AI can do anything the tool system

allows. Without guardrails, delete all

files or push to production are

possible. Both tools take security

seriously, but with very different

philosophies. Claude code uses multiple

independent guards like airport security

with multiple checkpoints, five layers,

permission modes, permission rules in

config, tool level checks, hook

overrides with custom scripts, and an AI

classifier, a separate model evaluating

whether a call is risky. Any single

layer can block an action. And

critically, if the AI classifier can't

be reached, it blocks by default. That's

fail design. Grock build has software

permissions too, but its unique layer is

kernel level sandboxing. On Linux, it

uses landlock. The OS kernel itself

enforces path-based access control. On

Mac OS, it uses Apple's seat belt

framework. The sandbox is stored in a

once lock in Rust. Once applied, it

literally cannot be undone. Even if the

AI tricks the software layers, the OS

blocks the action. The irony? Grock

build has arguably stronger local

security with its kernel sandbox. But

the upload scandal happened at the

network level. The sandbox restricts

file and process access, not what gets

sent to servers. Security must be

defense in depth.

Without memory, every conversation

starts from zero. The AI doesn't know

your preferences, your project's quirks,

or that you told it yesterday to never

use semicolons. Claude Code stores

memories as markdown files in your home

directory organized into four types:

user, feedback, project, and reference.

It retrieves them using semantic recall.

A smaller AI model picks the five most

relevant memories per turn. It can also

autosave memories through pattern

detection and a dreaming consolidation

step between sessions.

Grock build uses a local vector store

combined with keyword indexing. Memories

are flat entries retrieved through

combined vector and keyword search

injected as memory blocks into the

prompt. But there's a key difference. It

doesn't autosave. The model must

explicitly call a memory write tool to

save anything. The philosophical

difference. Claude codes memories

actively influence behavior. They shape

how it responds. Grock builds memories

are more like searchable history, a

reference archive you can query.

This is a real differentiator for Grock

Build, its checkpoint and undo system.

Before each prompt, it creates a

multi-dommain snapshot capturing three

things. The file state with before and

after snapshots per file. The git state

including head and staged paths and the

hunk tracker recording edit regions. If

the AI messes something up, you can

rewind to before that specific prompt.

The rewind process is methodical. First,

it does a git soft restore with stash

and reset. Then reverts files from

snapshots, reststages the correct git

paths, and finally restores the hunk

state. Why is this better than just

using git roll back? Four reasons.

First, it works on uncommitted changes.

The AI often edits files without

committing. Second, it provides per

prompt granularity. Git only works at

commit boundaries. Third, it preserves

staging state. What was staged versus

unstaged gets fully reconstructed. And

fourth, it's non-destructive. Rewinding

saves your current state first, so you

can undo the undo.

This kind of fine grained undo is

something Claude Code doesn't have built

in. You'd rely on git history or manual

stashing.

Both tools support agents, but they

emphasize different strengths. Claude

Code's philosophy is deep serial

reasoning. First, the main agent handles

complex problems with a large context

window. Sub agents supplement when

parallelism helps running in the

background or in isolated work trees.

Think of it as one deep thinker with

optional helpers. Grock builds

philosophy is parallel workers as a

first class pattern. The sub agent

coordinator orchestrates multiple

workers each running in their own

isolated work tree. On Linux with BTRFS

these are instant file system snapshots.

On Mac OS with APFS they use copy and

write reef links. Workers start

instantly from a pre-created pool. When

does each approach win? For complex bugs

requiring deep reasoning, clawed code.

The single thinker can hold the full

problem in context. For finding all

usages of something across a codebase or

large refactoring across many files,

grock build parallel workers search and

edit simultaneously without conflicts.

For subtle architectural decisions,

clawed code step-by-step reasoning

chains benefit from serial depth.

Let's put it all together with the final

comparison. On reasoning depth, Claude

code offers a large context window with

deep serial thinking. Grock build offers

parallel sub aents with a divide and

conquer approach. On speed, claude code

optimizes for thoroughess while Grock

build optimizes for parallelism. On

model choice, cla code uses anthropic

models while Grock build works with any

open compatible model. On privacy,

Claude Code has a clean record with no

incidents. Grock Build has the

controversial upload scandal. On open

source, Claude Code is proprietary.

Grock Build is Apache 2.0. Session

persistence. Claude Code saves history

to disk but is processbound. Grock

builds leader Damon provides full state

replay across crashes. Local security.

Cloud Code has five software layers plus

an AI classifier. Grock build uses

kernel level sandboxing with landlock

and seat belt. Practical recommendation,

use claude code if you value deep

reasoning, a mature ecosystem, and

proven privacy. Use Grock build if you

want parallel agents, model flexibility,

or the ability to audit the source code

yourself. You can even use both. They

support the same protocols.

If you're building AI powered tools,

here are five architectural patterns you

can apply today. Number one, everything

is a tool. A unified tool pipeline gives

you permissions, logging, and

extensibility for free. Both tools prove

this pattern works at scale. Actor model

versus event loop. Choose actors when

you need multi-session isolation. Each

session gets its own thread and can't

corrupt others. Choose an event loop

when simplicity matters. Most developers

only need one session at a time. Number

three, context management is the hard

problem. Both tools spend enormous

engineering effort here. Plan for it

early in your design. Whether you autoes

escalate like clawed code or let users

choose strategies like rock build, you

need a compaction plan. Number four,

layered configuration pays off. Both

tools use five or more configuration

layers. Enterprise, personal, project

settings all compose cleanly. Design for

this from the start. Number five,

security must be defense in depth. No

single layer is enough. The scandal

proved that even kernel sandboxing

misses network level threats. You need

multiple independent guards covering

different attack surfaces. The AI coding

agent space is converging on the same

patterns with different trade-offs.

Understanding the architecture helps you

use them better and build your own when

the time comes.

One final thought on the trust question.

Open source doesn't automatically mean

trustworthy. The upload code is still

there in the codebase, just disabled by

a flag. And proprietary doesn't mean

untrustworthy. Claude code has never had

a data exfiltration incident. What

actually matters? Network monitoring,

clear privacy policies, and independent

security audits. Judge tools by their

behavior, not their marketing.

Understanding these architectures helps

you make informed choices and gives you

the patterns to build your own AI tools

when the time comes. And if you found

this comparison helpful, hit subscribe

for more deep dives into AI coding

tools. Thanks for watching.