AIREITERSpaceXAI, das frühere xAI, hat den Quellcode seines Terminal-Coding-Agenten Grok Build auf GitHub unter der Apache-2.0-Lizenz veröffentlicht. Das klingt zunächst größer, als es ist: Open Source sind die in Rust geschriebene Agent-Harness und die TUI, nicht das Modell selbst. Hinter Grok Build arbeitet weiterhin grok-build-0.1 als kostenpflichtige, geschlossene API. Hinzu kommt ein ungünstiger Zeitpunkt: Nur wenige Tage vor dem Release wurde bekannt, dass das Tool komplette Git-Repositories in einen Cloud-Speicher hochgeladen hatte – und der entsprechende Upload-Code steckt weiterhin im nun veröffentlichten Repository.
„Grok Build Open Source“ stimmt also, und der Schritt ist nützlich: Der Client lässt sich nun genau prüfen. Das bedeutet aber nicht automatisch, dass die Nutzung standardmäßig privat ist. Wer Grok Build vor Mitte Juli 2026 in einem privaten Repository eingesetzt hat, sollte zuerst Einstellungen und Aufbewahrungsoptionen kontrollieren, statt nur den Code zu klonen. Hier ist, was der Release tatsächlich verändert.
Grok Build: Was jetzt offen ist – und was weiterhin geschlossen bleibt
Das Repository xai-org/grok-build enthält einen Vollbild-Coding-Agenten für das Terminal. Er kann Codebasen lesen, Dateien bearbeiten, Befehle ausführen, das Web durchsuchen und Aufgaben interaktiv oder ohne Benutzeroberfläche abarbeiten. Auf GitHub wird das Projekt als zu 99,6 % in Rust geschrieben und unter Apache 2.0 lizenziert geführt. Stand 16. Juli 2026 verzeichnet es 8,1k Stars und 1,3k Forks. Die Historie besteht aus einem einzigen zusammengefassten Commit mit dem Titel „Publish harness and TUI open-source“ – sichtbar ist also der ausgelieferte Client, nicht seine Entwicklungsgeschichte.
Die eigentliche Intelligenz liegt nicht im Repository. Grok Build nutzt grok-build-0.1, und dieses Modell bleibt hinter der kostenpflichtigen API des Unternehmens. Genau diese Unterscheidung wird leicht verwechselt:
- grok-1 (2024) erschien mit offenen Gewichten – das Modell ließ sich herunterladen und selbst ausführen.
- grok-build (2026) ist ein Open-Source-Client – das Tool kann gelesen und verändert werden, ruft aber weiterhin ein proprietäres Modell über das Netzwerk auf.
Für ein vollständig lokales, selbst gehostetes Grok bringt dieser Release daher nichts. Wer hingegen nachvollziehen oder erweitern möchte, wie das Tool mit den eigenen Dateien arbeitet, gewinnt deutlich mehr Kontrolle.
Der Datenschutzvorfall im Hintergrund
Die Open-Source-Veröffentlichung kam nicht aus dem Nichts. Laut einem Bericht von The Hacker News leitete ein unter dem Namen cereblab auftretender Forscher Grok Build am 14. Juli 2026 über einen abfangenden Netzwerk-Proxy und dokumentierte, welche Daten der Client übermittelte.
Das Ergebnis: Der Client packte das vollständige getrackte Git-Repository inklusive kompletter Commit-Historie und lud es hoch – in einen Google-Cloud-Storage-Bucket namens grok-code-session-traces. Bei einem Test mit einem 12-GB-Repository gingen laut Bericht 5,10 GiB nach außen, während der eigentliche Modellverkehr nur etwa 192 KB betrug. Betroffen waren auch Dateien, die der Agent nie geöffnet hatte: Selbst eine bewusst platzierte Testdatei unter src/_probe/never_read_canary.txt wurde übertragen. Inhalte aus .env-Dateien gingen ebenfalls ungeschwärzt mit, darunter Testwerte mit den Bezeichnungen API_KEY und DB_PASSWORD.
Die naheliegende Opt-out-Einstellung half dabei nicht. Der Schalter „Improve the model“ regelt, ob Daten zum Training des Modells verwendet werden – nicht, ob Code den Rechner verlässt. Demselben Bericht zufolge trat das Verhalten in Version 0.2.93 auf; auch in Build 0.2.99 war der Upload-Code noch vorhanden.
Die dokumentierte Reaktion des Unternehmens: Am 13. Juli deaktivierte es die Uploads serverseitig, statt ein Client-Update auszurollen. Kommuniziert wurde über soziale Medien und nicht über einen formellen Sicherheitshinweis. Zusätzlich kam ein /privacy-Befehl hinzu, mit dem sich die Aufbewahrung deaktivieren lässt. Elon Musk erklärte, bereits hochgeladene Daten würden „completely and utterly deleted.“ Eine CVE wurde nicht vergeben.
Was sich dank des offenen Codes nun überprüfen lässt
Hier liegt der praktische Nutzen des Releases. Zuvor ließ sich nur mit einem Proxy zwischen Client und Netzwerk feststellen, was Grok Build tatsächlich versendet. Jetzt ist der Client öffentlich einsehbar: Die Logik für Paketierung und Upload kann direkt im Quellcode geprüft werden, statt sie allein aus dem Netzwerkverkehr abzuleiten.
Beim Lesen des Codes wird auch klar, was ein serverseitiger Fix verschleiert: Uploads zu deaktivieren ist nicht dasselbe, wie die Funktion aus dem Code zu entfernen. Der Upload-Pfad ist im veröffentlichten Tree weiterhin vorhanden – er wurde auf Unternehmensseite abgeschaltet, nicht aus dem Client gelöscht. Ein serverseitiges Flag kann wieder aktiviert werden; nicht vorhandener Code kann dagegen nicht ausgeführt werden. Gerade bei sensiblen Projekten sind „Vertraut uns, es ist deaktiviert“ und „Die Funktion existiert nicht mehr“ zwei sehr unterschiedliche Zusagen. Open Source macht diesen Unterschied überprüfbar.
Wer einen Coding-Agenten prüft, der mit einem Cloud-Modell kommuniziert, sollte vor allem diese Punkte abklären:
- Welche Daten verlassen wann den Rechner? Werden nur tatsächlich gelesene Dateien übertragen oder das gesamte Repository?
- Stoppt das Datenschutz-Opt-out wirklich ausgehenden Netzwerkverkehr? Oder verhindert es lediglich Modelltraining?
- Lässt sich die Aussage selbst verifizieren? Etwa per Proxy-Mitschnitt, Quellcode oder nur über eine Richtlinienseite?
- Wie geht das Tool mit Secrets um? Werden
.env-ähnliche Dateien vor dem Upload auf sensible Inhalte geprüft und bereinigt?
Grok Build installieren und starten
Am schnellsten geht es über den offiziellen Installer. Er lädt ein vorkompiliertes Binary herunter, das als grok ausgeliefert wird:
# macOS / Linux / Git Bash
curl -fsSL https://x.ai/cli/install.sh | bash
grok --version
# Windows PowerShell
irm https://x.ai/cli/install.ps1 | iexWer den Open-Source-Client selbst aus dem Repository bauen möchte, benötigt Rust – die Version ist in rust-toolchain.toml festgelegt, sodass rustup sie verwaltet – sowie protoc für die Proto-Codegenerierung. Das Bauen wird unter macOS und Linux unterstützt:
cargo run -p xai-grok-pager-bin # launch the TUI
cargo build -p xai-grok-pager-bin --release # release binary
cargo check -p xai-grok-pager-bin # validate the buildBeim ersten Start authentifiziert sich Grok Build über den Browser statt über einen eingefügten API-Key. Intern heißt das Artefakt xai-grok-pager, in den offiziellen Builds wird es als grok ausgeliefert. Das hilft bei der Orientierung im Crate-Aufbau.
Was die Nutzung kostet
Der Client ist durch Open Source kostenlos, die Modellausführung jedoch nicht: grok-build-0.1 wird nutzungsbasiert abgerechnet. Laut OpenRouter-Eintrag kostet das Modell 1 $ pro Million Input-Token und 2 $ pro Million Output-Token. Es bietet ein Kontextfenster von 256K Token, unterstützt Text- und Bildeingaben und wurde dort mit dem 21. Mai 2026 als Veröffentlichungsdatum gelistet. Prompt Caching kann die effektiven Input-Kosten bei wiederholtem Kontext um ungefähr 60–80 % senken – relevant für Coding-Agenten, die während einer Sitzung dieselben Dateien wiederholt mitsenden.
Da grok-build-0.1 eine Standard-Chat-Completions-API spricht, ist es nicht nur direkt über SpaceXAI erreichbar, sondern auch über Modellrouter und API-Gateways. Das ist praktisch, wenn bereits mehrere Anbieter hinter einem Key laufen. AIReiter ist ein solches Anthropic-kompatibles Gateway, das neben anderen Modellen auch zu Grok routen kann. Unabhängig vom gewählten Weg sollten die aktuellen Tokenpreise vorab an der jeweiligen Quelle geprüft werden, denn Gateway-Preise können von denen des Anbieters abweichen.
Lohnt sich Grok Build jetzt?
Das nüchterne Fazit: Grok Build ist einen Test wert – unter klaren Bedingungen.
Was dafür spricht. Der Client ist schnell: native Rust-Implementierung, Vollbild-TUI und Mausunterstützung. Er steht tatsächlich unter Apache 2.0, kann also gelesen und geforkt werden. Außerdem ist grok-build-0.1 mit seinem 256K-Kontext gezielt auf agentisches Programmieren ausgelegt. Bei Einzelprojekten, Wegwerf-Repositories und öffentlichen Codebasen bringt der jüngste Vorfall in der Praxis wenig Risiko mit sich.
Warum Vorsicht angebracht ist. Der Upload-Code befindet sich weiterhin im veröffentlichten Tree; deaktiviert wurde er serverseitig, nicht entfernt. Das Modell bleibt geschlossen, sodass ein Netzwerkdienst weiterhin mit allem betraut wird, was der Client versendet. Bei privaten Unternehmens-Repositories oder Projekten unter NDA sollte Grok Build wie jedes Tool behandelt werden, das erst kürzlich eine weitreichende Standardübertragung von Daten ausgeliefert hat.
So prüfst du es vor dem Einsatz mit echtem Code. Da der Client jetzt offen ist, lässt sich das Repository per git clone herunterladen und nach dem Upload-Pfad sowie dem Bucket-Namen grok-code-session-traces durchsuchen – statt den Fix ungeprüft zu glauben. Für einen Live-Test kann Grok Build auf ein Wegwerf-Repository losgelassen werden, während der Netzwerkverkehr über einen abfangenden Proxy läuft. Alternativ lässt sich die Domain des Storage-Buckets an der Firewall blockieren. Dann lässt sich beobachten, ob neben Modelltraffic weitere Daten den Rechner verlassen. Mit /privacy wird die Aufbewahrung deaktiviert; für private Repositories sollte das Tool außen vor bleiben, bis das Verhalten selbst überprüft wurde.
Wer Coding-CLIs früher verglichen und Grok Build als geschlossen abgeschrieben hat, muss diese Einschätzung nun aktualisieren. Ähnlich wie sich Codex und Claude Code bei Offenheit und Workflow unterscheiden, hat sich Grok Build von proprietär zu Open Source entwickelt. Das Modell dahinter hat sich dadurch zwar nicht verändert, aber die Überprüfung des Clients sieht nun anders aus.
Häufige Fragen
Gibt es ein Open-Source-Grok-Modell?
Teilweise. Der Client von Grok Build ist seit Juli 2026 unter Apache 2.0 Open Source. Die Gewichte von grok-1 wurden bereits 2024 veröffentlicht. grok-build-0.1, das Modell hinter dem heutigen Grok Build, ist jedoch nicht offen und läuft ausschließlich über die kostenpflichtige API von SpaceXAI.
Ist Grok Build kostenlos?
Das Tool selbst ist kostenlos: Das Binary lässt sich installieren, der Open-Source-Client ohne Kosten bauen. Die Nutzung ist es nicht, weil Grok Build grok-build-0.1 aufruft und dieses Modell tokenbasiert abgerechnet wird. Ein lokales Modell ist nicht enthalten.
Wie viel kostet grok-build-0.1?
OpenRouter listet 1 $ pro Million Input-Token und 2 $ pro Million Output-Token bei einem Kontextfenster von 256K Token. Wiederverwendeter Kontext innerhalb einer Sitzung profitiert von Prompt Caching, das laut Eintrag die effektiven Input-Kosten deutlich senken kann.
Kann ich mit Grok eine App entwickeln?
Ja, genau dafür ist Grok Build gedacht. Das Tool ist ein agentischer Coding-Assistent für das Terminal: Es liest Codebasen, bearbeitet Dateien und führt Befehle aus. Wer lieber einen eigenen Agent-Loop entwickeln möchte, kann grok-build-0.1 auch direkt über seine API aufrufen.
Bleibt mein Code durch Open Source jetzt privat?
Nein. Open Source bedeutet, dass sich prüfen lässt, was der Client mit dem Code macht; es verhindert nicht automatisch das Senden von Daten. Nach dem Vorfall im Juli 2026 deaktivierte SpaceXAI den Upload kompletter Repositories serverseitig und ergänzte den Befehl /privacy. Wer Grok Build davor mit einem privaten Repository genutzt hat, sollte aber Einstellungen und Aufbewahrungsoptionen prüfen, statt davon auszugehen, dass der Release das Problem automatisch behoben hat.