# Grok-Build-Speicher über Sitzungen hinweg: Einstellungen und Einschränkungen
> 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.
Source: https://ailoot.ai/blog/de/grok-build-memory/
Canonical: https://ailoot.ai/blog/de/grok-build-memory/
Language: de
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-111
Revision: sha256-286192197b5c5ab39a3effa5cb040580a74cd116939aa1521fd4f3653bba1fe4
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](https://ailoot.ai/docs/).
## 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:**
```bash
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:
```toml
[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/`:
| Speicherort | Geltungsbereich | Inhalt |
|----|----|----|
| `~/.grok/memory/MEMORY.md` | Global | Fakten und Präferenzen für all Ihre Projekte |
| `~/.grok/memory/` + Projektverzeichnis mit Hash + `/MEMORY.md` | Projekt | Konventionen und Kontext für ein bestimmtes Repository |
| `~/.grok/memory/` + Projektverzeichnis mit Hash + `/sessions/` | Sitzungen | Zusammenfassungen 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:
| Taste | Aktion |
|----|----|
| `↑`/`↓` oder `j`/`k` | In der Liste navigieren |
| `/` | Liste filtern |
| `y` | Pfad zur ausgewählten Datei kopieren |
| `x` | Ausgewählte Notiz löschen (zum Bestätigen erneut drücken) |
| `t` | Speicher aktivieren oder deaktivieren |
| `Esc` | Fenster 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](https://ailoot.ai/blog/de/agents-md-claude-md-one-instruction-file/). 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](https://ailoot.ai/blog/de/claude-memory-claude-md-auto-memory/). Einen Vergleich der Tools selbst finden Sie unter [Grok Build oder Claude Code](https://ailoot.ai/blog/de/grok-build-vs-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
- Grok Build, offizieller Leitfaden „Cross-Session Memory“ (Benutzerhandbuch, Kapitel 13):
- Grok Build, xAI-Repository auf GitHub:
Für systematisches Arbeiten ist die Kombination **KI-Klon + Second Brain + Context Engineering** nützlich.
[Ailoot öffnen](https://ailoot.ai/).
## 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.
## Ailoot · Das Unternehmen und sein Projektportfolio
Ailoot baut auf bewährte Betriebserfahrung, einen großen Kundenstamm, stabilen Service und kontinuierliche KPI-Kontrolle.
Das Unternehmen und sein Projektportfolio: Millionen von Kunden; monatliche Umsätze in Milliardenhöhe.
Ailoot nutzt diese Betriebserfahrung für den API-Zugang zu KI-Funktionen in Kundenprodukten, Agenten, Anwendungen und Automatisierungen.