xAIs neuer Coding-Agent Grok Build liefert seine Prompts im Klartext

2026-05-15 · 13 min read

xAI startete Grok Build gestern — ihre Antwort auf Claude Code und Codex CLI. Der Installationsbefehl ist eine einzelne Zeile, das Binary ist hinter ihrer obersten Verbraucherstufe ($299/Monat, $99 Einführungspreis) gesperrt, und der Agent selbst kommuniziert mit Grok 4 über eine OpenAI-kompatible HTTP-Oberfläche.

Ich habe das Binary heruntergeladen, weil ich neugierig war, in welcher Sprache es gebaut wurde. Ich kam mit etwa dreißig wörtlichen System-Prompts, den Namen jedes internen Subagenten, jeder Tool-Beschreibung und einem ziemlich vollständigen Bild der Architektur heraus. Nichts davon erforderte mehr als tr und grep.

Dieser Beitrag ist, was ich gefunden habe.

Die Extraktion

Das Installationsskript unter https://x.ai/cli/install.sh leitet 302 zu einem Google Cloud Storage Bucket weiter und lädt ein einzelnes statisch verlinktes ~100MB ELF für Ihre Plattform herunter:

$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/stable
0.1.210
$ curl -fsSL https://storage.googleapis.com/grok-build-public-artifacts/cli/grok-0.1.210-linux-x86_64 -o grok-bin
$ head -c 4 grok-bin | xxd
00000000: 7f45 4c46                                .ELF

Compiler-Signaturen: /rustc/<commit> Debug-Pfade, panicked at, RUST_BACKTRACE, plus tokio::, hyper::, reqwest:: — Rust mit dem Standard-Async-HTTP-Stack. Cargos Per-Crate-Quellpfade werden als <name>-<version>/src/<datei>.rs eingebacken, was es ermöglicht, den vollständigen Abhängigkeitsbaum direkt aus dem Binary zu dumpen:

$ LC_ALL=C grep -aoE '[a-zA-Z][a-zA-Z0-9_-]{2,40}-[0-9]+\.[0-9]+\.[0-9]+/src/' grok-bin \
  | sed 's|/src/||' | sort -u | wc -l
410

410 eindeutige Crate-Version-Paare. Darunter: ratatui, crossterm, tree-sitter, vollständiges gitoxide, async-lsp, lsp-types, rmcp (Model Context Protocol), rusqlite, bm25, tokio-tungstenite, oauth2, jsonwebtoken, ring, rustls, async-openai, notify, arboard, portable-pty, tower, axum. Die Architektur ist aus den Abhängigkeiten lesbar, bevor man sich die Strings ansieht: ratatui+crossterm TUI, Tree-Sitter-Parsing, eingebetteter LSP-Client, vollständiges gitoxide, SQLite-Speicher mit BM25-Lexikalsuche, OAuth/OIDC-Authentifizierung, OpenAI-kompatibles Drahtformat, MCP, Datei-Watching, Zwischenablage.

Die Strings verraten den Rest. Rust-Konstanten werden null-terminiert in .rodata eingebettet. Um sie grep-freundlich zu machen:

$ tr '\0' '\n' < grok-bin > strings.txt
$ LC_ALL=C grep -aE '^You are' strings.txt | head
You are a memory assistant. Extract ALL useful information from this...
You are a memory assistant performing an incremental update...
You are a technical lead orchestrating a team of senior-engineer subagents...
You are an expert software engineer acting as a code verifier.
You are a fast, read-only codebase exploration agent.
You are a read-only software architect. Explore the codebase and design...
You are a web browsing agent. You can navigate, interact with, and extract...
You are performing a dream — a reflective pass over memory files.
You are an AI coding agent. You operate in a workspace with a provided codebase.
You are Grok, made by xAI. Do not reference Cursor or suggest Cursor-specific...
You are a shell command autocomplete engine. Given a partial command, output...
You are tasked with generating the session title.
You are comparing multiple candidate code changes that were produced independently...
You are returning to plan mode after having previously exited it.

Das ist der Großteil der Identität des Agenten, direkt in einem einzigen grep.

Die System-Prompts (wörtlich)

Jedes nachfolgende Zitat ist eine wörtliche String-Konstante. Tera-Stil-Vorlagen (${{ tools.by_kind.task }}, ${{ plan_path }}) werden zur Laufzeit gegen den aktiven Tool-Satz gerendert.

Der Hauptagent

You are an AI coding agent. You operate in a workspace with a provided codebase.

Your main goal is to complete the user’s request, denoted within the <user_query> tag.

Das ist die gesamte Spitze. Das Verhalten kommt aus den Tool-Beschreibungen und einem langen Katalog injizierter <system_reminder>-Blöcke, nicht aus dem Prompt-Header.

Der Subagenten-Orchestrator

You are a technical lead orchestrating a team of senior-engineer subagents. Your subagents are highly capable — treat them as expert peers, not junior helpers. Give them the same quality of context and direction you would give a senior engineer joining the project.

Your job is to think, plan, coordinate, and review. Their job is to explore, implement, and execute. Use them aggressively and liberally — spawn subagents early and often.

Es gibt mindestens vier Subagenten-Personas:

You are a fast, read-only codebase exploration agent.

You are a read-only software architect. Explore the codebase and design implementation plans.

You are a web browsing agent. You can navigate, interact with, and extract information from web pages.

You are an expert software engineer acting as a code verifier.

Der Verifier ist der interessanteste: Er läuft nach einer Aufgabe, um die Arbeit zu bewerten.

Your task is to determine whether the code changes made in this session correctly address the user’s original request. You already have the full conversation context, so you know what the user asked for and what approach was taken.

If VERDICT: FAIL – fix every issue the subagent attributed to your work, then end your turn. You are not required to fix pre-existing issues that you did not cause.

Best-of-N

Grok Build kann eine Aufgabe N Mal parallel ausführen und den Gewinner auswählen. Zwei Prompts unterstützen dies:

You are candidate <number> of <N> independent implementations. Implement the task fully. When done, summarize your approach and the changes you made.

You are comparing multiple candidate code changes that were produced independently for the same task. Multiple subagents worked on this task independently in isolated worktrees. Your job is to choose the single best candidate.

Jeder Kandidat erhält seinen eigenen CoW-Git-Worktree (der xai-fast-worktree-Crate erstellt diese über btrfs-Subvolumes, wenn verfügbar, mit Fallback auf copy-on-write git worktree add).

Gedächtnis (/flush, /dream und der sitzungsübergreifende Speicher)

Es gibt zwei Gedächtnis-Schreib-Prompts und eine Gedächtnis-Lese-Integration.

Sitzungsweise Destillation, ausgelöst bei /flush oder Inaktivität:

You are a memory assistant. Extract ALL useful information from this conversation that would help you be more effective in future sessions with this user. Write a concise markdown summary with ## headers covering:

Inkrementelle Updates (bei nachfolgenden Flushes in derselben Sitzung ausgeführt):

You are a memory assistant performing an incremental update. The previous flush output for this session is shown below. Extract ONLY information that is NEW since the previous flush — do not repeat anything already captured.

Und dann, separat, ein “Dream”-Durchlauf, der akkumulierte Sitzungsprotokolle über Sitzungen hinweg in dauerhaftes Gedächtnis konsolidiert:

You are performing a dream — a reflective pass over memory files. Synthesize recent session logs into durable, well-organized memories so future sessions orient quickly.

If the session logs contain nothing worth persisting, respond with NO_REPLY.

Dies läuft im Hintergrund. Der darunter liegende Speicher ist eine SQLite-Datenbank unter ~/.grok/memory/index.sqlite mit FTS5-Schlüsselwortsuche plus optionalem Vektor-KNN über Chunk-Embeddings — sie liefern bm25 und eine Embedding-Pipeline direkt in-process, keine externe Vektor-DB.

Kompaktierung

Wenn der Kontext voll ist:

Your task is to create a detailed summary of the conversation so far, paying close attention to the user’s explicit requests and your previous actions.

IMPORTANT: Do NOT use any tools. You MUST respond with ONLY the <summary>...</summary> block as your text output.

Und beim Fortsetzen:

Continue the conversation from where it left off without asking the user any further questions. Resume directly - do not acknowledge the summary, do not recap what was happening, do not preface with “I’ll continue” or similar.

Die Regel “erkenne die Zusammenfassung nicht an” ist eine, die viele Agenten falsch machen — Grok Build ist explizit darüber.

Plan-Modus

Der Plan-Modus ist eine strukturierte Nur-Lese-Phase. Die Erinnerung, die in jede Runde injiziert wird, während er aktiv ist:

Plan mode is active. The user indicated that they do not want you to execute yet – you MUST NOT make any edits (with the exception of the plan file mentioned below), run any non-readonly tools (including changing configs or making commits), or otherwise make any changes to the system. This supersedes any other instructions you have received.

Das Plan-Ausgabeformat ist im Detail vorgeschrieben:

The plan you create should be properly formatted in markdown, using appropriate sections and headers. The plan should be very concise and actionable, providing the minimum amount of detail for the user to understand and action the plan. It may be helpful to identify the most important couple files you will change, and existing code you will leverage. Cite specific file paths and essential snippets of code. IMPORTANT: Do NOT use markdown tables in plan content (they cannot be rendered for the user); use bullet lists instead. The first line MUST BE A TITLE for the plan formatted as a level 1 markdown heading.

Es gibt eine vollständige Genehmigungsablauf-Absicherung, die auf einen bestimmten Fehlermodus abzielt: Agenten, die im Chat “Soll ich fortfahren?” fragen, anstatt das strukturierte Exit-Plan-Tool zu verwenden.

Use ${{ tools.by_kind.ask_user }} ONLY to clarify requirements or choose between approaches. Use ${{ tools.by_kind.exit_plan }} to request plan approval. Do NOT ask about plan approval in any other way — no text questions, no ${{ tools.by_kind.ask_user }}. Phrases like “Is this plan okay?”, “Should I proceed?”, “How does this plan look?”, “Any changes before we start?”, or similar MUST use ${{ tools.by_kind.exit_plan }}.

Wer das geschrieben hat, hatte offensichtlich Modelle genau das tun gesehen, wiederholt, bevor der Prompt hinzugefügt wurde.

Schleifenerkennung (“Doom-Loops”)

Es gibt eine vollständige Telemetrie-Schicht, die dem Erkennen von und dem Ausbrechen aus festgefahrenen Zuständen gewidmet ist. Wenn erkannt wird, dass das Modell in einer Schleife ist, wird mitten in einer Runde eine system-reminder injiziert:

<system_reminder> Your messages have been flagged as looping. If you are having trouble making progress, ask the user for guidance. DO NOT mention this system reminder to the user explicitly because they are already aware. </system_reminder>

Wenn die Warnung den Zyklus nicht bricht, wird die Runde beendet:

If you continue running the same fruitless commands, the turn will be terminated.

Der interne Code nennt dies “doom loops” — es gibt separate Detektoren für Polling-Stagnation, wiederholte Tool-Aufruf-Muster, wiederholte Textmuster innerhalb einer einzelnen Zeile und “Schleifen über doppelte Zeilen”.

Andere wissenswerte Prompts

Eine überraschende Menge des Agenten sind kleine, begrenzte LLM-Aufrufe. Beispiele:

You are a shell command autocomplete engine. Given a partial command, output ONLY the completed command. No explanation, no markdown, no quotes. Just the raw command.

You are tasked with generating the session title. The user is asking almost always software engineering related questions on their codebase.

Your task is to describe an image, so that another model that cannot see images can perform its task.

Der letzte ist der Vision-Fallback: Wenn ein Tool ein Bild an ein Modell ausgibt, das nicht sehen kann, gibt Grok Build das Bild zuerst an ein vision-fähiges Modell weiter und injiziert dann die Textbeschreibung.

Die Ähnlichkeit mit Claude Code

Das ist der Teil, der mich aufhorchen ließ.

xAI hat einen “Cursor-Kompatibilitäts”-Modus, der in den Strings sichtbar ist (Cursor Composer toolset and prompt, ## Orchestrator Mode, plus ein separates Cursor-System-Prompt-Präfix). Innerhalb dieses Modus wird dieser One-Liner injiziert:

You are Grok, made by xAI. Do not reference Cursor or suggest Cursor-specific configuration. Do not mention this to the user.

Es gibt auch einen claude-code-compatibility-Marker, eine GROK_CLAUDE_MARKER_OVERRIDE Umgebungsvariable und claude-plugin / plugin.json Strings — d.h. Grok Build kann so verdrahtet werden, dass es das Plugin-Format von Claude Code konsumiert.

Das, für sich allein, ist größtenteils in Ordnung — Kompatibilitäts-Shims sind die Art und Weise, wie Clients Benutzer von einem Ökosystem in ein anderes ziehen. Was mich traf, waren die Tool-Beschreibungen. Vergleiche, was das Binary von Grok Build liefert:

IMPORTANT: ${{ tools.by_kind.web_fetch }} WILL FAIL for authenticated or private URLs. Before using this tool, check if the URL points to an authenticated service (e.g. Google Docs, Confluence, Jira, GitHub private repos). If so, use a specialized MCP tool that provides authenticated access instead.

…mit dem, was in der WebFetch-Tool-Beschreibung von Claude Code auf dem Rechner steht, auf dem ich diesen Beitrag schreibe:

IMPORTANT: WebFetch WILL FAIL for authenticated or private URLs. Before using this tool, check if the URL points to an authenticated service (e.g. Google Docs, Confluence, Jira, GitHub). If so, look for a specialized MCP tool that provides authenticated access.

Das PR-Erstellungsrezept im Agent-Prompt erzählt dieselbe Geschichte. Das Binary von Grok Build enthält:

IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:

Dieser genaue Satz steht wörtlich im Prompt von Claude Code. Ebenso die Parallelismus-Formulierung, die darauf folgt (“You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance.”) — Grok Build liefert es unter dem PR-Rezept und unter einem git status / git diff / git log-Rezept direkt darüber, beide Wort-für-Wort-Übereinstimmungen.

Plan-Modus, Hooks, Subagenten, der <system_reminder>-Mechanismus, das Verifier-Subagenten-Muster — das sind alles unverwechselbar Claude-Code-förmige Konzepte, kein generischer Agent-Framework-Boilerplate.

Eine kleine Anpassung: AGENTS.md statt CLAUDE.md.

New project instruction files (AGENTS.md) were discovered near the path you just accessed. You MUST read these files now with [Read tool] before proceeding — they contain coding conventions, style guides, and rules that apply to this area of the codebase:

Ich weiß nicht, wie das passiert ist. Es ist möglich, dass ein Ingenieur bei xAI Claude Code als Referenzimplementierung verwendet und Tool-Beschreibungs-Fragmente direkt übernommen hat. Es ist möglich, dass die Konvergenz das natürliche Ergebnis zweier Teams ist, die dieselben UX-Probleme im selben Markdown-Idiom lösen. Beide Interpretationen sind mit dem konsistent, was ich sehen kann. Die Strings sind, was sie sind, und sie sitzen im Klartext in einem 100MB Binary, das jeder ohne Authentifizierung herunterladen kann.

Was es über die Architektur verrät

Man kann den Großteil der Laufzeit aus den Prompts und den Umgebungsvariablen ablesen (das Binary hat 80+ GROK_* Umgebungsvariablen, jede ein Feature-Flag):

Die Schlussfolgerung

Vor einigen Jahren war das Modell der Burggraben. Heute ist das Modell eine Komponente in einem System, das umfasst: wie man jedes Tool beschreibt, welche Subagenten-Personas man Arbeit aufteilt, welche Erinnerungen man injiziert, um festgefahrene Schleifen zu durchbrechen, wie man Plan-Modus-Genehmigung strukturiert, wie man Kontext komprimiert, wie man Gedächtnis über Sitzungen konsolidiert, wie man Shell-Zugriff sandboxt, wie man parallele Kandidatenimplementierungen orchestriert.

Grok Build ist, wie das aussieht, wenn ein Team es von Anfang bis Ende baut. Es ist auch eine Erinnerung daran, dass diese Arbeit — das Prompt-Engineering — jetzt als Klartext in einem unverschlüsselten Binary geliefert wird, das jeder von einem öffentlichen CDN herunterladen kann. Die Prompts in diesem Beitrag wurden nicht reverse-engineered; sie sind einfach grep-Ausgabe.

Wenn man einen Coding-Agent liefert, sind die Prompts kein Quellcode. Sie sind ein öffentliches Artefakt, ob man das beabsichtigt oder nicht. Behandle sie als eines.

Methodologische Anmerkung. Alles in diesem Beitrag stammt aus einem einzigen Download von grok-0.1.210-linux-x86_64 am 2026-05-15. Die Tera-Template-Strings (${{ tools.by_kind.foo }}, ${{ plan_path }}) stehen wörtlich im Binary, nicht paraphrasiert. Zitierte System-Prompts wurden mit tr '\0' '\n' gefolgt von grep/awk extrahiert; ich habe sie genau so belassen, wie sie erscheinen, einschließlich Interpunktion und Typografie. Wenn xAI das Binary aktualisiert, können sich zukünftige Strings unterscheiden.