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

SpaceXAI open-sourced Grok Build, its coding agent and terminal UI, under Apache 2.0, but the release does not include Grok 4.5 model weights, and users must pay API inference costs. A developer who cloned the repository found that the privacy controls are fragmented, with the `/privacy` command not affecting telemetry or trace upload, requiring separate configuration to disable them.

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?