Blog

Grok-Build-Speicher über Sitzungen hinweg: Einstellungen und Einschränkungen

Markdown

Wie Sie den Speicher aktivieren, wo Notizen gespeichert werden und wie /flush, /remember, /dream und /memory funktionieren. Priorität der Einstellungen, Überprüfung und Löschen von Einträgen.

Vollständigen Artikel lesen

Grok Build, der Terminal-Agent von xAI, verfügt über einen sitzungsübergreifenden Speicher: Er kann sich Projektkonventionen, Entscheidungen und erfolgreiche Debugging-Schritte merken und sie dann ohne erneute Hinweise zum Kontext einer neuen Sitzung hinzufügen. Die Funktion ist standardmäßig deaktiviert und experimentell – sie lässt sich mit einer einzigen Einstellung aktivieren.

Diese Beschreibung basiert auf dem offiziellen Leitfaden im Repository xai-org/grok-build mit Stand vom 20. September 2026. Der Autor des Originalartikels hat das Produkt nicht ausgeführt: Die Funktionsweise wurde anhand der Dokumentation beschrieben, nicht durch persönliche Tests.

Praktische Informationen zur Arbeit mit Ailoot finden Sie in der Dokumentation.

Was speichert Grok Build über Sitzungen hinweg?

Das Wichtigste

Ohne Speicher erhält eine neue Grok-Build-Sitzung keine Informationen aus vorherigen Sitzungen: weder Konventionen, die Sie erklärt haben, noch getroffene Entscheidungen – sofern sie nicht in einer Anweisungsdatei im Repository festgehalten wurden. Ist der Speicher aktiviert, durchsucht der Agent gespeicherte Notizen und fügt relevante Einträge automatisch zum Kontext einer neuen Sitzung hinzu. Die Notizen werden als gewöhnliche Markdown-Dateien gespeichert, die Sie lesen und bearbeiten können.

Beispielsweise haben Sie dem Agenten in einer Sitzung erklärt, dass das Projekt eine Einrückung mit zwei Leerzeichen verwendet, Datenbankmigrationen mit einem separaten Befehl ausgeführt werden und ein bestimmtes Modul Zahlungen verarbeitet. In einer neuen Sitzung müssen Sie diese Informationen erneut angeben.

Bei aktiviertem Speicher kann Grok Build:

  • sich an zuvor erklärte Projektkonventionen erinnern;
  • bereits erfolgreiche Debugging-Schritte verwenden;
  • Architekturentscheidungen in spätere Sitzungen übernehmen;
  • vermeiden, erneut nach Dingen zu fragen, die bereits beantwortet wurden.

Die Funktion ist experimentell und standardmäßig deaktiviert. Solange Sie sie nicht aktivieren, ändert sich das Verhalten des Agenten nicht.

Wie aktivieren Sie den Speicher?

Das Wichtigste

Für einen einzelnen Lauf setzen Sie die Umgebungsvariable GROK_MEMORY=1. Damit der Speicher dauerhaft aktiviert bleibt, fügen Sie einen Abschnitt [memory] mit enabled = true zu ~/.grok/config.toml hinzu. Damit gespeicherte Notizen zu Beginn der Arbeit hinzugefügt werden, starten Sie nach dem Aktivieren des Speichers eine neue Sitzung mit /new.

Einmalig für einen einzelnen Lauf:

GROK_MEMORY=1 grok

Die Variable gilt nur für diesen Lauf. Mit dem Befehl export GROK_MEMORY=1 bleibt sie in der aktuellen Shell gesetzt und aktiviert den Speicher für alle folgenden grok-Läufe aus dieser Shell – bis die Terminalsitzung endet oder Sie export GROK_MEMORY=0 ausführen.

Dauerhaft über die Konfiguration. Fügen Sie dies zu ~/.grok/config.toml hinzu:

[memory]
enabled = true

Innerhalb einer Sitzung, ohne Neustart: Öffnen Sie /memory und drücken Sie t.

Dieser Schalter gilt nur für die aktuelle Sitzung und wird nicht in die Konfiguration geschrieben. Sie können damit den Speicher aktivieren oder deaktivieren. Beim Deaktivieren wird der Zugriff auf die Speicherwerkzeuge entfernt, die Dateien bleiben jedoch auf der Festplatte; durch erneutes Aktivieren wird der Speicher wieder geöffnet. Der Schalter kann eine erzwungene Deaktivierung des Speichers für den gesamten Prozess über GROK_MEMORY=0 nicht aufheben: /memory bleibt während der gesamten Sitzung nicht verfügbar.

Wenn Einstellungen an mehreren Stellen festgelegt sind, gilt folgende Priorität:

  • GROK_MEMORY=0 deaktiviert den Speicher für den gesamten Prozess zwingend und hat die höchste Priorität.
  • Ein explizites enabled = false in der Konfiguration deaktiviert den Speicher, selbst wenn eine verwaltete Remote-Einstellung ihn aktiviert.
  • Der Speicher lässt sich mit GROK_MEMORY=1, mit enabled = true in der Konfiguration oder durch eine verwaltete Remote-Einstellung aktivieren.
  • Ist nichts festgelegt, ist der Speicher deaktiviert.

Notizen werden beim ersten Zug einer Sitzung hinzugefügt. Wenn Sie den Speicher mitten in der Arbeit aktiviert haben und der Agent gespeicherte Projektinformationen nutzen soll, führen Sie /new aus. Ob der Speicher aktiviert ist, können Sie in der Ausgabe von grok inspect prüfen.

Was zeichnet Grok Build auf, und wo?

Das Wichtigste

Notizen werden unter ~/.grok/memory/ als Markdown-Dateien gespeichert: eine globale MEMORY.md für alle Projekte, eine separate MEMORY.md für jedes Projekt und Sitzungsprotokolle. Die automatische Zusammenfassung am Sitzungsende wird ohne Modellaufruf erstellt; ausführliche Notizen entstehen mit /flush und /remember, und /dream ordnet unterschiedliche Einträge nach Themen.

Die Verzeichnisstruktur von ~/.grok/memory/:

SpeicherortGeltungsbereichInhalt
~/.grok/memory/MEMORY.mdGlobalFakten und Präferenzen für all Ihre Projekte
~/.grok/memory/ + Projektverzeichnis mit Hash + /MEMORY.mdProjektKonventionen und Kontext für ein bestimmtes Repository
~/.grok/memory/ + Projektverzeichnis mit Hash + /sessions/SitzungenZusammenfassungen und Protokolle einzelner Sitzungen

Dem Namen des Projektverzeichnisses wird ein kurzer Hash der Repository-Kennung hinzugefügt. Zur Identifizierung wird der Remote origin im Format „Organisation/Repository“ verwendet oder, wenn kein Git-Repository vorhanden ist, der Verzeichnispfad. Daher teilen Klone und Worktrees (separate Arbeitskopien von Git-Branches) denselben Projektspeicher: Was der Agent sich in einer Kopie merkt, ist auch in einer anderen verfügbar.

Einträge werden auf vier Arten erstellt:

  1. Automatische Zusammenfassung am Sitzungsende. Wenn eine Sitzung endet, speichert Grok Build eine kurze Dienstzusammenfassung im Tagesprotokoll: die Anzahl der Nachrichten, bis zu fünf erste inhaltliche Gesprächswechsel sowie Datum und Uhrzeit. Die Zusammenfassung wird aus Metadaten erstellt, ohne Modellaufruf oder Verzögerung. Sehr kurze Sitzungen werden übersprungen: Gibt es weniger als drei inhaltliche Gesprächswechsel oder weniger als 50 Byte Text von Ihnen, wird kein Eintrag erstellt. Die Zusammenfassung enthält keine verwendeten Tools, Dateipfade oder Befehle. Automatische Zusammenfassungen lassen sich mit der Einstellung session.save_on_end = false deaktivieren.
  2. /flush – eine ausführliche Notiz auf Anfrage. Mit diesem Befehl fasst das Modell die wichtigsten Punkte der aktuellen Sitzung zusammen: Entscheidungen, Muster, Debugging-Schritte und API-Erkenntnisse. Die Zusammenfassung wird in ein datiertes Protokoll geschrieben und für künftige Sitzungen indiziert. Laut Dokumentation sollte /flush vor der Kontextkomprimierung, am Ende einer erfolgreichen Debugging-Sitzung und nach der Entdeckung wichtiger Muster ausgeführt werden.
  3. /remember – eine ausdrückliche Bitte, sich etwas zu merken. Geben Sie /remember always open PR links after sending ein oder sagen Sie dem Agenten: „Merke dir, dass …“ Vor dem Schreiben des Eintrags öffnet sich eine Überprüfungsansicht: Die Notiz wird erst nach Ihrer Bestätigung gespeichert, und im Feed erscheint Memory saved to ~/.grok/memory/MEMORY.md. Projektinformationen kommen in die Projektdatei MEMORY.md; Informationen, die für alle Projekte gelten, kommen in die globale Datei.
  4. /dream – Konsolidierung. Der Befehl ordnet verstreute Protokolle und Notizen nach Themen und entfernt Duplikate, damit die Suche genauer wird. Wie bei /flush übernimmt das Modell die Konsolidierung: Es liest die gesammelten Einträge und ordnet sie neu nach Themen. Daher sollten Sie das Ergebnis regelmäßig mit /memory überprüfen. Es gibt auch einen automatischen Modus: Standardmäßig prüft Grok Build beim Start und einmal pro Stunde die Bedingungen und beginnt mit der Konsolidierung, wenn mindestens 24 Stunden vergangen sind und mindestens 5 Sitzungen vorliegen. Die Schwellenwerte lassen sich im Konfigurationsabschnitt [memory.dream] einstellen.

Notizen werden über einen SQLite-Index durchsucht: Standardmäßig kommt die Volltextsuche FTS5 zum Einsatz; wenn ein Embedding-Modell konfiguriert ist, wird die semantische Vektorsuche ergänzt.

Wie gelangt der Speicher in eine neue Sitzung?

Das Wichtigste

Beim ersten Zug einer Sitzung durchsucht Grok Build den Speicher nach Einträgen zum Projekt und fügt sie automatisch zum Kontext hinzu – Sie müssen den Agenten nicht daran erinnern. Nach einer automatischen Kontextkomprimierung wird die Suche wiederholt. Ältere Sitzungseinträge werden zur Aktualitätsprüfung markiert.

Für die anfängliche Einfügung gilt der Auswahlgrenzwert min_score = 0.9, den Sie im Abschnitt [memory.initial_injection] ändern können. Nach einer automatischen Kontextkomprimierung durchsucht der Agent den Speicher erneut, um Informationen wiederherzustellen, die zusammen mit älteren Gesprächswechseln möglicherweise aus dem Kontext entfernt wurden.

Sie können den Agenten auch direkt fragen: „Woran erinnerst du dich?“ Die Antwort wird nach Quelle gegliedert: globale Präferenzen, Projektwissen und Sitzungsverlauf.

Sitzungseinträge enthalten Aktualitätsmarkierungen. Je älter ein Sitzungseintrag ist, desto deutlicher wird er mit dem Hinweis markiert: „Prüfe, ob dies noch aktuell ist, bevor du dich darauf verlässt.“ Die globalen und projektbezogenen MEMORY.md-Dateien erhalten solche Markierungen nicht: Ihr Inhalt ist für die langfristige Nutzung gedacht, daher müssen Sie seine Richtigkeit selbst überwachen.

Wie können Sie Notizen ansehen, bearbeiten und löschen?

Das Wichtigste

Der Befehl /memory öffnet eine Übersicht aller Speicherdateien mit Vorschauen. Sie können die Dateien in jedem Texteditor bearbeiten – die Änderungen werden bei der nächsten Suche übernommen. Die Aufforderung „Vergiss …“ funktioniert ohne Garantie; um einen bestimmten Eintrag zuverlässig zu entfernen, bearbeiten Sie die Datei.

Der Befehl /memory öffnet in einer Sitzung ein Fenster mit allen Speicherdateien, gruppiert nach Geltungsbereich: global, Projekt und Sitzungen (in umgekehrter chronologischer Reihenfolge). Die Dateiliste befindet sich links, rechts sehen Sie eine schreibgeschützte Vorschau der ausgewählten Datei.

Nützliche Tasten in der Übersicht:

TasteAktion
↑/↓ oder j/kIn der Liste navigieren
/Liste filtern
yPfad zur ausgewählten Datei kopieren
xAusgewählte Notiz löschen (zum Bestätigen erneut drücken)
tSpeicher aktivieren oder deaktivieren
EscFenster schließen

Das Fenster kann einzelne Notizen und Sitzungsdateien löschen, nicht jedoch die erzeugten MEMORY.md-Indizes (global und projektbezogen).

Als zweite Möglichkeit können Sie die Dateien direkt bearbeiten. Sie befinden sich unter ~/.grok/memory/ und lassen sich mit jedem Editor öffnen. Änderungen im Verzeichnis werden nachverfolgt: Erstellte und geänderte Dateien werden neu indiziert, gelöschte Dateien beim nächsten Suchvorgang aus dem Index entfernt.

Die Aufforderung „Vergiss snake_case“ funktioniert ohne Garantie: Das Modell sucht nach passenden Einträgen und entfernt sie, kann aber einige übersehen. Um das Löschen sicherzustellen, öffnen Sie die Datei (ihren Pfad können Sie bequem mit y in /memory kopieren) und entfernen Sie den Eintrag manuell. Sie können den Speicher auch vollständig über die Kommandozeile leeren: grok memory clear für den Projektspeicher, grok memory clear --global für den globalen Speicher und grok memory clear --all für beides.

Worin unterscheidet sich der Speicher von einer Anweisungsdatei im Repository?

Das Wichtigste

Sie schreiben eine Anweisungsdatei wie CLAUDE.md oder AGENTS.md und legen sie im Repository ab – das Team teilt sie über Git. Der Grok-Build-Agent pflegt Speichernotizen und legt sie unter ~/.grok/memory/ außerhalb des Repositorys ab: Sie sind persönlich und werden nicht über Git geteilt.

Eine Anweisung im Repository wird mit allen geteilt, die am Projekt arbeiten, und ist im Code sowie in der Änderungshistorie sichtbar. Der Speicher wächst im Laufe der Sitzungen, wird auf Ihrem Rechner gespeichert und nicht von selbst veröffentlicht.

Der Speicher ersetzt keine Anweisungsdatei. Allgemeine Projektregeln, die das ganze Team und jeder Agent kennen muss, gehören weiterhin ins Repository. Wir haben einen separaten Leitfaden zur Verwendung einer gemeinsamen Anweisungsdatei für Claude Code, Codex und Cursor: AGENTS.md und CLAUDE.md gemeinsam verwenden. Der Speicher bewahrt persönlichen Kontext: Ihre Präferenzen, was bereits ausprobiert wurde und welche Entscheidung getroffen wurde.

Claude unterscheidet ähnlich: Wie sich der Speicher von CLAUDE.md unterscheidet, erklären wir im Artikel Claude-Speicher und CLAUDE.md. Einen Vergleich der Tools selbst finden Sie unter Grok Build oder Claude Code.

Einschränkungen und Überprüfung der Speicherfunktion

Das Wichtigste

Die Funktion ist experimentell: Befehle und Einstellungen können sich ändern. Damit Notizen nach der Aktivierung beim ersten Zug hinzugefügt werden, starten Sie eine neue Sitzung mit /new. Einige Einträge werden vom Modell erstellt. Überprüfen Sie die Notizen daher regelmäßig und bitten Sie den Agenten, sich keine Geheimnisse zu merken.

Beachten Sie die folgenden Einschränkungen:

  • Experimenteller Status. Befehle, Schwellenwerte und Verhalten können sich in künftigen Versionen ändern. Schlagen Sie im Speicherleitfaden des Repositorys nach, wenn etwas nicht wie erwartet funktioniert.
  • Erste Einfügung in eine neue Sitzung. Starten Sie nach dem Aktivieren des Speichers mit /new, damit gespeicherte Notizen beim ersten Zug hinzugefügt werden.
  • Das Modell entscheidet, was wichtig ist. Das Modell erstellt die Zusammenfassung für /flush und wählt aus, was in die Notiz kommt. Öffnen Sie alle ein bis zwei Wochen /memory, überprüfen Sie die gesammelten Inhalte und löschen Sie Unnötiges.
  • Bitten Sie den Agenten nicht, Geheimnisse zu speichern. Schlüssel, Tokens und Passwörter gehören nicht in langfristige Notizen: Die Dateien unter ~/.grok/memory/ werden als Klartext gespeichert. Falls etwas Sensibles aufgezeichnet wurde, entfernen Sie es durch Bearbeiten der Datei.
  • Der Projektspeicher wird zwischen Repository-Kopien geteilt. Wenn sich der Agent in einem Klon etwas merkt, das in einem anderen veraltet ist, berücksichtigen Sie beim Aufräumen das gemeinsam genutzte Verzeichnis.

Wenn der Speicher nicht funktioniert:

  1. Prüfen Sie die Ausgabe von grok inspect, um sicherzustellen, dass der Speicher aktiviert ist.
  2. Prüfen Sie, ob GROK_MEMORY=0 oder die Konfiguration ihn deaktiviert.
  3. Führen Sie zur Diagnose RUST_LOG=debug GROK_LOG_FILE=/tmp/grok.log grok aus und prüfen Sie die Speicher betreffenden Zeilen in /tmp/grok.log.

Kurze Zusammenfassung

Der Speicher in Grok Build wird mit GROK_MEMORY=1 oder mit [memory] enabled = true in ~/.grok/config.toml aktiviert. Damit Notizen nach dem Aktivieren beim ersten Mal hinzugefügt werden, starten Sie eine neue Sitzung mit /new. Der Agent schreibt Notizen nach ~/.grok/memory/: Sitzungszusammenfassungen ohne Modellaufruf, ausführliche Zusammenfassungen mit /flush, ausdrückliche Einträge mit /remember nach Ihrer Bestätigung und nach Themen geordnete Notizen mit /dream. Notizen können Sie über /memory und durch direktes Bearbeiten der Dateien ansehen und aufräumen. Die Funktion ist experimentell. Prüfen Sie daher Schwellenwerte und Befehle anhand des offiziellen Leitfadens und kontrollieren Sie die Notizen regelmäßig.

Quellen

Für systematisches Arbeiten ist die Kombination KI-Klon + Second Brain + Context Engineering nützlich.

Ailoot öffnen.

Weitere Details

Fragen und Antworten

Warum erscheinen gespeicherte Notizen nach der Speicheraktivierung nicht?

Gespeicherte Notizen werden beim ersten Zug einer neuen Sitzung eingefügt. Starte nach dem Aktivieren neu und prüfe den gemeldeten Zustand mit grok inspect. Ein mit GROK_MEMORY=0 gestarteter Prozess kann den Speicher nicht über den Sitzungsschalter einschalten.

Löscht das Abschalten des Speichers seine Dateien?

Nein. Es entzieht den Zugriff auf die Speichertools, lässt aber Markdown-Notizen auf dem Datenträger. Prüfe oder bearbeite die gespeicherten Notizen separat, wenn du einen Eintrag entfernen musst.

Alle Artikel