Grok 4.5 Isn't Open Source. The Apache 2.0 Release Has a Privacy Catch.

SpaceXAI open-sourced Grok Build, and three versions of the story immediately started circulating:

1. "Grok 4.5 is open source now."


2. "You can run the whole Grok stack offline."


3. "The privacy problem is solved because the code is public."

The first two are wrong. The third is directionally useful, but nowhere near proven.

I cloned the July 21 public repository, checked 2,847 tracked files, traced the current telemetry and session-upload controls, and compared that source with the wire-level report from Grok Build 0.2.93.

Here's what I found.

TL;DR

• 
  NO, Grok 4.5 is not open source. SpaceXAI released the Grok Build agent harness and terminal UI, not the model weights.


• 
  The release is real Apache 2.0 code. I can inspect, modify, fork, redistribute, and use the first-party code commercially under the license terms.


• 
  Local models are supported. I can point Grok Build at a custom base_url, including a local inference endpoint.


• 
  Local-first is not the same as offline by default. Model inference, authentication, telemetry, trace uploads, remote sessions, plugins, and MCP servers are separate network paths.


• 
  The old repository-upload finding was real for 0.2.93. SpaceXAI reportedly disabled it, but I would still wire-test the exact binary I deploy.

What actually became open source

SpaceXAI's tested Grok Build 0.2.93 with controlled repositories and captured the tool's traffic.

The strongest result wasn't "a cloud model saw a file." Every cloud coding agent needs the relevant context.

The stronger result was a separate storage path:

• around 192 KB went through model-turn requests in one preserved run;


• about 5.10 GiB went through storage requests;


• a captured Git bundle reconstructed a file the agent was told not to read;


• the bundle also contained Git history.

The researcher did not prove that SpaceXAI trained on that data. Transmission and storage were demonstrated; training was not.

SpaceXAI reportedly disabled the whole-codebase upload server-side and said previously uploaded data would be deleted. The current source I audited contains no codebase_upload or git bundle string.

But here's the part I won't hand-wave: the current tree still contains session-trace upload, GCS storage, upload-queue, telemetry, and remote-settings code.

That doesn't prove the old behavior survives. It proves a static source search is not a substitute for a packet capture.

The "should I trust it?" decision tree

def should_you_run_grok_build(repo):

    if repo == "public or disposable":

        return "Try the official build, but inspect config and logs."



    if repo == "private but replaceable":

        return (

            "Disable telemetry and trace uploads, use canary secrets, "

            "and capture network traffic before real work."

        )



    if repo == "regulated or crown-jewel":

        return (

            "Pin an audited source commit, use a private/local model endpoint, "

            "block optional domains, and require a repeatable wire test."

        )



    return "Do not assume open source equals offline. Map every data path first."

What I'd do this week

For a personal public repo: I'd install the binary, turn off telemetry and trace upload explicitly, and use grok inspect before the first task.

For a private startup repo: I'd create a canary clone with fake secrets, run it behind a logging proxy, and verify the exact client version. I would rotate any real credential that an older affected build could have accessed.

For an enterprise: I'd fork and pin the source, define requirements in managed configuration, route inference through a controlled endpoint, and block remote session sharing unless the team needs it.

For a local-LLM setup: I'd test 50 real tasks, not five demos. I care about task completion, retry count, tool-call validity, latency, and total compute time.

For Grok 4.5 users: I'd keep model-cost monitoring. The Apache license doesn't change the $2/$6 token rates or the 2x long-context price.

The bigger picture

This release says something important about AI coding tools.

The model is only one layer. The agent harness decides which files are read, what context is assembled, which commands run, what gets persisted, and where the results go. That layer can create as much security and cost risk as the model.

Open-sourcing the harness moves the industry in the right direction because it makes those decisions inspectable. It also raises the standard: now that I can read the code, I expect vendors and teams to explain the effective runtime configuration too.

If you need one route across Grok, OpenAI, Anthropic, and local-compatible endpoints, that's roughly what .

Bottom line

Grok Build is a meaningful Apache 2.0 release. Grok 4.5 is still closed, local-first still needs configuration, and privacy still has to be verified at runtime.

I'd use the source. I wouldn't outsource my trust to the word "open."

Would you trust an open-source agent with a private repository if the model endpoint and runtime policy were still controlled remotely?