# Grok 4.5 Isn't Open Source. The Apache 2.0 Release Has a Privacy Catch. > Source: > Published: 2026-07-22 02:48:44+00:00 SpaceXAI open-sourced Grok Build, and three versions of the story immediately started circulating: 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. `base_url` , including a local inference endpoint.SpaceXAI's [official announcement](https://x.ai/news/grok-build-open-source) is precise: it open-sourced the coding agent and TUI. The public repository includes: 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 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 ``` Scale that to 100M input and 20M output: ``` 100M input x $2/M = $200 20M output x $6/M = $120 Monthly model bill = $320 ``` 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 ``` At 50 such runs per workday, that theoretical maximum becomes: ``` $1.80 x 50 x 22 workdays = $1,980/month on one developer ``` 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. 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" ``` After changing the config, I can inspect what Grok Build discovered: ``` grok inspect grok -p "Explain this repository" -m local-coder ``` 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. 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 ``` 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. The original [wire-level analysis](https://gist.github.com/cereblab/dc9a40bc26120f4540e4e09b75ffb547) 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: 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. ``` python 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." ``` **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. 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](https://tokenmix.ai) helps with. Disclosure: I work on the research side. The full source-audited breakdown is in the [original Grok Build article](https://tokenmix.ai/blog/grok-build-open-source-2026-local-models-privacy). 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?