Point It at a Local Model and Nothing Leaves? — I Read the Published Grok Build Source

2026年8月19日

Once you are running AI on your own machine, you start looking at the tools that help you write code and wondering whether those could run on a local model too. The kind of thing called an agent, living in a terminal. So when I heard that xAI had released a coding agent called Grok Build as open source, it looked like something I could try.

The configuration did indeed let you point it at a local model. But I stopped short of installing it. Does using it require an account? And if you point it at a local model, does anything actually leave the machine?

Released as open source means you can read it and find out. So I read it before installing.

This is as of July 2026. Throughout, I refer to xAI’s coding agent by its proper name, Grok Build.

To be clear up front: I did not run it

This article is not the result of running anything. It is what I put together from the published source code, the official documentation, and published reports. This blog normally leads with numbers I measured myself; this time there are none. I would rather say so plainly.

The reason I did not run it is that partway through reading I decided not to install it on this machine. The reason is further down.

Let me also bound what I read. The repository has over 3,400 files and I have not read all of them. What I looked at was authentication and the parts concerned with sending things outward.

Can you use it without an account?

This was my first question. If the point is to keep everything on your own model, you would rather not hold an account with the other party.

The official getting-started documentation is explicit. On first launch a browser opens and you are asked to sign in at grok.com. The sequence is described as “once you authenticate, the full-screen interface appears." There is nowhere any procedure for using it without authenticating.

Some alternatives exist: passing a key called XAI_API_KEY as an environment variable for environments without a browser, and using a workplace identity provider. Either way, you are still identifying yourself to the other party.

The install script, as far as I read it, does not demand authentication. It does look for credentials internally, but what it finds only changes the text it prints; the download itself comes from somewhere anyone can reach. Installing, in other words, appears not to require identifying yourself.

How far can you point it at a local model?

This part I genuinely admired. Write the endpoint into the configuration file and it will use a model you are running locally, as it is.

You can specify the endpoint address (base_url), the model name, a key, and things like the context length. There are three conversational formats to choose from, including OpenAI-compatible. So anything with an OpenAI-compatible endpoint, such as Ollama or llama.cpp, should broadly connect.

I did find one trap that anyone running AI at home is likely to hit. Register a new model without stating the context length and it is treated as 200,000 tokens by default.

That number is used to decide when a conversation has grown long enough to summarise and compress. Connect a local model while that assumption sits at 200,000, and the tool will let the conversation accumulate well past what the model can handle before it thinks about compressing.

I have measured context length on a 12GB graphics card before. Speed fell away and flattened at around 32,768 tokens. Turning on compression of the area that holds the conversation (the KV cache) took the same 12GB card to 65,536 tokens. Four times.

That number differs from machine to machine, which is exactly why this is a setting to determine by measuring your own. It is not the sort of field to leave at its default.

So does pointing it at a local model mean nothing leaves?

This was the real question. And this is where my decision changed.

Reading through the source, there are mechanisms for sending things outward that are separate from the path the conversation with the AI travels. Three dedicated directories, standing on their own.

The third one concerned me most. Reading it, the upload happens once per conversational turn. A file description even uses the phrase “signal that the send for one turn has completed." It does not appear to be built to batch things up at convenient points; it follows the exchange.

The contents named for sending were the conversation record, the compressed file that consolidates memory, and the changes in the directory being worked on. There are even tests showing that if a send fails it does not give up but retries once connectivity returns.

Is there a setting to stop it?

There is, and it is only fair to say so.

The configuration file has an option to turn analytics off entirely and another to turn off only the sending of records. Environment variables can do it too. That it is built to be switchable is itself a sign that nothing is being hidden.

One other thing caught my eye while reading. Inside the command that opens the privacy-related screen, a developer has left a comment to the effect that this screen does not change the main analytics switch.

In other words, what the screen called “privacy" controls and the setting that stops the sending are in different places. What the name suggests and what it actually governs do not line up. That struck me as easy to get wrong.

For what it is worth, the destination for cloud uploads is baked in when the software is built, with a note that without it the upload does not run. Build it yourself and you can have a non-sending state, is the reading. It is natural to assume the official prebuilt distribution has it baked in.

Comparing this against what was reported

While researching I learned that several reports appeared in July 2026: that whole working repositories were being uploaded, and that the privacy toggle did not stop it. One report captured the traffic and analysed it.

I have not verified any of that. I did not record traffic myself, so I cannot state whether those reports are correct.

What I can say is that mechanisms consistent with those reports genuinely exist in the published source. A component that uploads to cloud storage, a design that sends once per turn, working-directory changes among the contents, and a developer’s own comment that the privacy screen does not touch the main switch. What I read agrees with what was reported.

In fairness, xAI is reported to have disabled data retention by default on 12 July 2026, and to say that what had been retained until then has been deleted. The situation is moving.

Why I decided not to put it on this machine

My working machine has things on it. The private key for the server this blog is published from, keys for a few services, and drafts that have not gone out yet.

Something with a real mechanism for uploading working-directory changes, enabled by default, with past reports that turning it off did not stop it. I could not justify running that on the machine where the keys live.

This is not specific to Grok Build. An AI agent’s job is to read files on your machine and hand them to a model. Being able to read them means being able to hand them over. A key file left where it can be read will be read, misconfiguration or not. That much is the same whoever is on the other end.

If I do try it, I will set up a disposable environment or a rented cloud machine. Somewhere with no keys and no drafts, and I can run it freely.

The best thing about reading it

That was a run of critical observations, but what I was left with afterwards is somewhere else entirely.

Because it is published, it could be checked.

If the inside were not visible, I would have read the news and stopped at “well, perhaps." Instead I could follow, with my own eyes, where the sending components are, when they fire, and where the setting to stop them lives. The decision to publish is what makes that possible.

If your reason for running AI locally is that you do not want your own material leaving the house, then performance cannot be the only yardstick for choosing a tool. Whether you can see inside it is a perfectly good yardstick too.

In summary: where you point it does not settle whether things leave

• Grok Build can be pointed at a local model. Anything with an OpenAI-compatible endpoint should connect
• But starting to use it requires an account. Installing does not
• There are three outbound mechanisms separate from the conversation. One of them uploads to cloud storage once per turn, and what it sends includes working-directory changes
• Settings to stop it exist, but the default is to send. A comment in the source notes that the “privacy" screen does not change the main switch
• Omit the context length and it is treated as 200,000 tokens. With a local model, measure your own machine and set it
• I have not verified the reports, but the mechanisms they describe do exist
• And it could be checked precisely because it is published

“I pointed it at a local model, so nothing leaves" does not follow. Where you point it and what the tool itself sends are two things that have to be checked separately. Next time I want to set up a machine with no keys on it and write about actually running this.

Sources

Checked 30 July 2026, against the main branch of the public repository. Software gets updated. The behaviour described here may change in later versions. If you are considering installing it, check against the version in front of you.