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 official announcement is precise: it open-sourced the coding agent and TUI.

The public repository includes:

• the agent loop that assembles context and dispatches tools;
• file reading, editing, search, and shell tools;
• the full-screen terminal interface and inline diff viewer;
• skills, plugins, hooks, MCP servers, and subagents;
• headless mode and Agent Client Protocol support;
• workspace, checkpoint, and session code.

The distinction looks like this:

Layer Open now? Can I self-host it? Grok Build agent loop Yes Yes Terminal UI Yes Yes File and shell tools Yes Yes Skills, plugins, MCP, hooks Yes Yes Grok 4.5 weights No No A different local model Bring your own Yes, if compatible

The repository says its first-party code is Apache 2.0. Third-party and vendored components keep their original licenses. It also says external contributions aren’t currently accepted.

That last point surprised me. I can fork it, but I shouldn’t assume SpaceXAI will merge my pull request. This is open source as inspectable and reusable code, not yet a normal community-maintained upstream.

The model is still the expensive part

The open-source license removes the harness license fee. It doesn’t remove model inference cost.

Grok 4.5 is still an API model. SpaceXAI currently lists:

Token type Short context At or above 200K prompt Input / 1M $2.00 $4.00 Cached input / 1M $0.30 $0.60 Output / 1M $6.00 $12.00

Here is the first pain translation.

10M input x $2/M = $20
2M output x $6/M = $12
Monthly model bill = $32

Enter fullscreen mode Exit fullscreen mode

Scale that to 100M input and 20M output:

100M input x $2/M = $200
20M output x $6/M = $120
Monthly model bill = $320

Enter fullscreen mode Exit fullscreen mode

And a long-context agent request can double the simple estimate:

300K input x $4/M = $1.20
50K output x $12/M = $0.60
One request = $1.80

Enter fullscreen mode Exit fullscreen mode

At 50 such runs per workday, that theoretical maximum becomes:

$1.80 x 50 x 22 workdays = $1,980/month on one developer

Enter fullscreen mode Exit fullscreen mode

That isn’t a measured average Grok Build bill. It’s what the published long-context rates imply for that workload. My point is simpler: open-source software and free inference are different claims.

Yes, I can point it at a local model

The official docs expose a custom model configuration:

[models]
default = "local-coder"

[model.local-coder]
model = "your-local-model-id"
base_url = "http://127.0.0.1:8000/v1"
name = "Local Coder"
env_key = "LOCAL_MODEL_KEY"

Enter fullscreen mode Exit fullscreen mode

After changing the config, I can inspect what Grok Build discovered:

grok inspect
grok -p "Explain this repository" -m local-coder

Enter fullscreen mode Exit fullscreen mode

This is the part of the release I find genuinely exciting. Grok Build can become an open agent shell around a local model, a company gateway, or another compatible API.

But I would test tool calling before celebrating. A local model that can answer coding questions may still fail the agent loop: malformed tool arguments, weak recovery after shell errors, context loss, or excessive retries can make the setup unusable.

The privacy catch is four separate switches

I expected /privacy opt-out to be the master switch.

It isn’t.

The current source documentation treats these as separate:

Control What it controls /privacy Coding-data sharing preference [features] telemetry Product analytics [telemetry] trace_upload Session trace upload External OpenTelemetry A separate stream to my collector

The user guide explicitly says /privacy does not change telemetry or trace upload.

So my conservative config starts like this:

[features]
telemetry = false

[telemetry]
trace_upload = false
mixpanel_enabled = false

Enter fullscreen mode Exit fullscreen mode

I also checked how the current source resolves those values. With no requirement, environment variable, local config, or remote setting, telemetry falls back to disabled. But remote settings can affect the resolved value, and trace upload follows telemetry when it isn’t set explicitly.

That is why I would set both values myself instead of relying on a fallback.

What the old privacy report proved

The original wire-level analysis 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."

Enter fullscreen mode Exit fullscreen mode

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 TokenMix helps with. Disclosure: I work on the research side. The full source-audited breakdown is in the original Grok Build article.

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?