Auto Dream

Anthropic hat ein Feature in Claude Code eingebaut, ohne es öffentlich anzukündigen. Es heißt Auto Dream und löst das Kernproblem von Auto Memory: Notizen verrotten, wenn sie sich anhäufen.

Problem: Auto Memory war ein echter Fortschritt. Claude fing an, eigene Projektnotizen zu führen. Nach 20 oder mehr Sessions wird das Notizbuch aber hässlich. Einträge fangen an, sich zu widersprechen. Relative Datumsangaben wie "gestern" verlieren jede Bedeutung. Alte Debugging-Tipps zeigen auf Dateien, die im Refactoring gelöscht wurden. Was hilfreiches Gedächtnis sein sollte, wird zum Hintergrundrauschen, das Claude aus der Bahn wirft.

Quick Win: Prüfe, ob Auto Dream bei dir aktiv ist. Öffne eine beliebige Claude Code-Session und starte /memory. Schau im Selektor nach "Auto-dream: on". Wenn der Flag da ist, räumt Claude bereits zwischen Sessions deine Memory-Dateien im Hintergrund auf.

# Check your current memory state
/memory
 
# Look for:
# Auto-dream: on

Du siehst den Toggle und er ist aktiv? Gut. Ab und zu geht Claude durch die Projektgedächtnisdateien, schmeißt Veraltetes raus, behebt Widersprüche und sortiert den Rest um. Noch kein Toggle? Lies weiter. Ein manueller Auslöser funktioniert trotzdem.

Warum "Dreaming"? Der REM-Schlaf-Aspekt

Der Name wurde nicht zufällig gewählt. Die Analogie passt wirklich.

Dein Gehirn saugt den ganzen Tag Rohdaten auf und parkt sie als Kurzzeitgedächtnis. REM-Schlaf geht dann die Ereignisse des Tages durch, behält die wichtigen Verbindungen, lässt den Rest fallen und archiviert alles im Langzeitgedächtnis. Zu wenig REM und du hast Schwierigkeiten, dauerhafte Erinnerungen zu bilden. Informationen kommen an, werden aber nie konsolidiert.

Auto Memory spielt die Rolle von Claude's wachem Gehirn. Es hält fest, was während der Arbeit passiert: Debugging-Muster, Build-Befehle, Architekturentscheidungen, deine Eigenheiten. Jede Session stapelt mehr Einträge. Ohne einen Aufräumdurchgang werden diese Notizen aber genauso unordentlich wie ein nicht-konsolidiertes Kurzzeitgedächtnis. Alte Widersprüche bleiben bestehen. Veraltete Einträge verschwinden nie. Das Signal ertrinkt mit jeder Session ein bisschen mehr im Rauschen.

Auto Dream übernimmt die REM-Rolle. Es schaut, was Auto Memory gesammelt hat, behält die noch relevanten Teile, löscht alles Abgelaufene und formt den Rest in ordentliche Themen-Dateien mit einem sauberen Index um. Ohne Auto Dream lief Claude Code quasi im Schlafentzug. Notizen häuften sich an. Der Aufräum-Durchgang kam nie.

Die vier Phasen eines Dream Cycles

Auto Dream durchläuft jedes Mal eine vierphasige Routine. Jede Phase hat ihre eigene Aufgabe, und zusammen verwandeln sie einen zerstreuten Stapel Session-Notizen in organisiertes Projektwissen.

Phase 1: Orientierung

Claude öffnet das Memory-Verzeichnis und katalogisiert, was bereits da ist. Es liest MEMORY.md (den Index), schaut sich die Liste der Themen-Dateien an und skizziert den aktuellen Stand.

Die Frage, die diese Phase beantwortet: "Was weiß ich bereits, und wie ist es abgelegt?"

Phase 2: Signal sammeln

Als Nächstes durchsucht Auto Dream deine Session-Transkripte (die JSONL-Dateien, die Claude lokal für jede Session aufbewahrt). Jede von vorn bis hinten zu lesen ist nicht drin. Bei einem Projekt mit Hunderten von Sessions wäre das absurd was Tokens und Zeit angeht. Der Durchlauf ist eng begrenzt. Er sucht nur nach bestimmten Mustern:

• Nutzerkorrekturen: Stellen, wo du Claude gesagt hast, dass es falsch liegt, oder es in eine neue Richtung gelenkt hast
• Explizite Speicherungen: Wenn du sagst "remember this" oder "save to memory"
• Wiederkehrende Themen: Muster, die in vielen Sessions aufgetaucht sind
• Wichtige Entscheidungen: Architekturwahlen, Tool-Auswahl, Workflow-Änderungen

Dieser enge Durchlauf ist bewusst gewählt. 500 Transkripte vollständig zu lesen würde Tokens für kaum neue Erkenntnisse verbrennen. Enge Grep-artige Abfragen holen die hochwertigsten Bits raus, ohne den Overhead.

Phase 3: Konsolidierung

Das ist das Herzstück. Claude faltet neue Informationen in bestehende Themen-Dateien ein und erledigt die wichtige Pflege:

• Relative Datumsangaben werden in absolute Datumsangaben umgeschrieben. "Gestern haben wir entschieden, Redis zu nutzen" wird zu "Am 2026-03-15 haben wir entschieden, Redis zu nutzen." Das verhindert, dass zeitliche Bezüge mit zunehmendem Alter der Erinnerungen verwirrend werden.
• Widersprochene Fakten werden gelöscht. Vor drei Wochen von Express auf Fastify gewechselt? Der alte "API uses Express"-Eintrag verschwindet.
• Veraltete Erinnerungen werden bereinigt. Debugging-Notizen, die auf eine Datei zeigen, die im Refactoring gelöscht wurde, nützen nichts mehr. Weg damit.
• Überlappende Einträge werden zusammengeführt. Drei Sessions, die alle die gleiche Build-Befehl-Eigenart gemeldet haben, schrumpfen auf eine einzige saubere Notiz zusammen.

Phase 4: Bereinigen und indizieren

Die letzte Phase konzentriert sich auf MEMORY.md. Diese Datei wird unter 200 Zeilen gehalten, weil 200 die Grenze für das ist, was beim Start geladen wird. Phase 4 aktualisiert MEMORY.md so, dass es den aktuellen Zustand der Themen-Dateien widerspiegelt:

• Entfernt Links zu Themen-Dateien, die nicht mehr existieren
• Fügt Verweise auf neue Themen-Dateien hinzu, die bei der Konsolidierung entstanden sind
• Behebt Lücken zwischen dem Index und dem, was die Dateien tatsächlich sagen
• Sortiert Einträge nach Relevanz und Aktualität um

Themen-Dateien, die bei der Konsolidierung keine Änderungen brauchten, werden in Ruhe gelassen. Auto Dream schreibt nicht bei jedem Durchlauf alles neu. Die Änderungen sind chirurgisch präzise.

Der vollständige System-Prompt

Hier ist der eigentliche System-Prompt, der Auto Dream antreibt. Das ist, was Claude bekommt, wenn ein Dream Cycle startet:

# Dream: Memory Consolidation
 
You are performing a dream - a reflective pass over your memory files.
Synthesize what you've learned recently into durable, well-organized
memories so that future sessions can orient quickly.
 
Memory directory: `~/.claude/projects/<project>/memory/`
This directory already exists - write to it directly with the Write tool
(do not run mkdir or check for its existence).
 
Session transcripts: `~/.claude/projects/<project>/`
(large JSONL files - grep narrowly, don't read whole files)
 
## Phase 1 - Orient
 
- `ls` the memory directory to see what already exists
- Read `MEMORY.md` to understand the current index
- Skim existing topic files so you improve them rather than creating
  duplicates
- If `logs/` or `sessions/` subdirectories exist (assistant-mode layout),
  review recent entries there
 
## Phase 2 - Gather recent signal
 
Look for new information worth persisting. Sources in rough priority order:
 
1. **Daily logs** (`logs/YYYY/MM/YYYY-MM-DD.md`) if present - these are
   the append-only stream
2. **Existing memories that drifted** - facts that contradict something
   you see in the codebase now
3. **Transcript search** - if you need specific context (e.g., "what was
   the error message from yesterday's build failure?"), grep the JSONL
   transcripts for narrow terms:
   `grep -rn "<narrow term>" <project-transcripts>/ --include="*.jsonl"
| tail -50`
 
Don't exhaustively read transcripts. Look only for things you already
suspect matter.
 
## Phase 3 - Consolidate
 
For each thing worth remembering, write or update a memory file at the
top level of the memory directory. Use the memory file format and type
conventions from your system prompt's auto-memory section - it's the
source of truth for what to save, how to structure it, and what NOT
to save.
 
Focus on:
 
- Merging new signal into existing topic files rather than creating
  near-duplicates
- Converting relative dates ("yesterday", "last week") to absolute dates
  so they remain interpretable after time passes
- Deleting contradicted facts - if today's investigation disproves an old
  memory, fix it at the source
 
## Phase 4 - Prune and index
 
Update `MEMORY.md` so it stays under 200 lines. It's an **index**, not a
dump - link to memory files with one-line descriptions. Never write memory
content directly into it.
 
- Remove pointers to memories that are now stale, wrong, or superseded
- Demote verbose entries: keep the gist in the index, move the detail into
  the topic file
- Add pointers to newly important memories
- Resolve contradictions - if two files disagree, fix the wrong one
 
---
 
Return a brief summary of what you consolidated, updated, or pruned. If
nothing changed (memories are already tight), say so.

Ein paar Details aus diesem Prompt sind es wert, hervorgehoben zu werden. Er sagt Claude ausdrücklich, eng zu greppen und vollständige Transkript-Lesevorgänge zu vermeiden. Er hält MEMORY.md unter der 200-Zeilen-Grenze. Und er weist Claude an, Widersprüche in der Quelldatei zu beheben, nicht nur darauf hinzuweisen. Der Prompt hat starke Meinungen darüber, wie Gedächtnis aussehen soll, deshalb kommt der Output so konsistent sauber raus.

Wann ein Dream Cycle startet

Zwei Dinge müssen gleichzeitig zutreffen, damit die Konsolidierung läuft:

1. Mindestens 24 Stunden sind seit der letzten Konsolidierung vergangen
2. Mehr als 5 Sessions haben seit der letzten Konsolidierung stattgefunden

Beide Gates sind erforderlich. Eine Marathon-Session über zwei Tage löst Auto Dream nicht aus (die Session-Anzahl ist zu niedrig). Zehn schnelle Sessions in zwei Stunden auch nicht (zu wenig Zeit vergangen). Das doppelte Gate verhindert, dass ruhige Projekte nutzlose Aufräumdurchläufe auslösen, und stellt sicher, dass aktive Projekte sauber bleiben.

Als Größenordnung: In einem beobachteten Durchlauf hat Auto Dream 913 Sessions an Gedächtnis in etwa 8 bis 9 Minuten abgearbeitet. Nicht kostenlos, aber die Arbeit passiert im Hintergrund, du spürst also keine Unterbrechung.

Sicherheitsgarantien

Auto Dream läuft innerhalb echter Leitplanken. Versehen sind schwer zu machen.

Projektcode bleibt read-only. Während eines Dream Cycles kann Claude nur in Memory-Dateien schreiben. Quellcode, Konfiguration, Tests und der Rest deiner Projektdateien sind gesperrt. Der Dream-Prozess ist auf das Memory-Verzeichnis beschränkt.

Eine Lock-Datei verhindert Überlappungen. Du hast zwei Claude Code-Instanzen auf demselben Projekt offen? Nur eine kann Auto Dream gleichzeitig ausführen. Eine Lock-Datei verhindert, dass zwei Konsolidierungsdurchläufe gleichzeitig laufen und Merge-Konflikte in den Memory-Dateien erzeugen.

Läuft im Hintergrund. Auto Dream blockiert deine Session nicht. Du arbeitest in Claude Code weiter, während es läuft. Die Konsolidierung findet in einem eigenen Prozess statt.

Einen Dream manuell auslösen

Auf den automatischen Trigger zu warten ist optional. Wenn du weißt, dass das Gedächtnis aufgeräumt werden muss, z.B. direkt nach einem großen Refactoring, kannst du eine Konsolidierung selbst erzwingen.

Der /dream-Befehl existiert, ist aber noch nicht bei jedem Account angekommen. Solange du wartest, sag Claude einfach, was du willst:

"dream"
"auto dream"
"consolidate my memory files"

Claude versteht die Absicht und geht denselben vierphasigen Ablauf durch. Nützlich nach größeren Projektänderungen, wenn frisches Gedächtnis wichtig ist und auf den nächsten automatischen Cycle zu warten zu langsam ist.

Vorher und Nachher: Eine echte Konsolidierung

So kann ein typisches Memory-Verzeichnis vor und nach einem Dream Cycle aussehen.

Vorher (Unordentlich, 30+ Sessions angesammelt)

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 280 lines, over the 200-line limit
├── debugging.md           # Contains 3 contradictory entries about API errors
├── api-conventions.md     # References Express (switched to Fastify 2 weeks ago)
├── random-notes.md        # Mix of stale and current info
├── build-commands.md      # "Yesterday" used 6 times with no dates
└── user-preferences.md    # Duplicates entries from MEMORY.md

Nachher (Konsolidiert)

~/.claude/projects/<project>/memory/
├── MEMORY.md              # 142 lines, clean index with links to topic files
├── debugging.md           # Deduplicated, only current solutions
├── api-conventions.md     # Updated to reflect Fastify migration
├── build-commands.md      # All dates absolute, no duplicates
└── user-preferences.md    # Merged with relevant MEMORY.md entries

Die random-notes.md-Datei ist weg. Ihr Inhalt wurde entweder in relevante Themen-Dateien überführt oder als veraltet gelöscht. MEMORY.md schrumpfte von 280 auf 142 Zeilen, wieder unter die 200-Zeilen-Startschwelle. Widersprüche sind behoben. Datumsangaben sind absolut.

Auto Memory vs Auto Dream: Zwei Schichten eines Systems

Diese zwei Features arbeiten zusammen, nicht gegeneinander. Stell sie dir als die Sammelschicht und die Pflegeschicht eines einzigen Memory-Setups vor.

Auto Memory ohne nachträgliche Bereinigung ist wie ein Mitschreiber, der nie zurückblättert. Umgekehrt gilt: Ohne etwas, das neue Notizen schreibt, hat ein Dream Cycle nichts zum Bearbeiten. Du willst beide am Laufen haben.

Vier Gedächtnissysteme: Das vollständige Bild

Mit dieser neuen Schicht hat Claude Code vier verschiedene Gedächtnismechanismen. So fügt sich das vollständige Set zusammen, aufbauend auf der Tabelle aus dem Auto Memory Deep-Dive:

Das stärkste Setup betreibt alle vier. CLAUDE.md trägt die Regeln, die du besitzt und kontrollierst. Auto Memory erfasst, was Claude auf der Arbeit aufschnappt. Session Memory trägt Gesprächsfäden über Neustarts hinweg weiter. Und der Dream Cycle hält das angesammelte Wissen aktuell, korrekt und organisiert.

Praktische Tipps

Lass die Automatisierung die meisten Projekte regeln. Die Standard-Gates (24h plus 5 Sessions) passen gut zur aktiven Entwicklung. Kein Babysitten nötig.

Erzwinge einen Dream direkt nach einem großen Refactoring. Die halbe Codebase umbenannt? Framework gewechselt? API umstrukturiert? Löse einen manuellen Cycle aus. Alte Einträge verwirren mehr als sie helfen, bis sie abgeglichen sind.

Schau dir den Output ab und zu an. Nachdem ein Dream Cycle abgeschlossen ist, überflieg MEMORY.md. Auto Dream ist gut, aber nicht unfehlbar. Eine Konsolidierungsentscheidung kann dir missfallen. Die Dateien sind einfaches Markdown. Bearbeite sie, wie es dir gefällt.

Kombiniere es mit guter Kontext-Hygiene. Ein Dream Cycle hält deine Memory-Dateien sauber, aber den aktiven Session-Kontext verwaltest du selbst. Sauberere Dateien bedeuten, dass Claude beim Start weniger Müll lädt, was dir mehr Platz für echte Arbeit im Kontextfenster lässt.

Nächste Schritte

• Leg zuerst CLAUDE.md an, falls noch nicht geschehen. Ein Dream Cycle konsolidiert Auto Memory, aber CLAUDE.md bleibt die höchstpriorisierte Quelle der Wahrheit.
• Lies über Auto Memory, um genau zu sehen, was Claude während Sessions aufzeichnet, das ist das Rohmaterial, mit dem Auto Dream arbeitet.
• Schau dir Session Memory an für Kontinuität auf Gesprächsebene zwischen Arbeitssessions.
• Sieh dir Context Engineering an, um zu verstehen, wie all diese Gedächtnissysteme zu einer bewussten Kontextstrategie zusammenwachsen.
• Beobachte das Claude Code Changelog für Updates am Gedächtnissystem, einschließlich wenn Auto Dream auf deinem Plan-Tier ausgerollt wird.
• Neu bei Claude Code? Folge der Installationsanleitung, um auf macOS, Windows oder Linux loszulegen, bevor du die Gedächtniskonfiguration anfasst.

Auto Dream ist das Stück, das Claude's Gedächtnis von einem wachsenden Notizenstapel in eine lebendige, gepflegte Wissensbasis verwandelt. Auto Memory sammelt das Rohmaterial. Auto Dream formt es zu etwas, das Claude wirklich nutzen kann. Das Nettoergebnis ist ein Claude, der sich nicht nur mehr über die Zeit merkt, sondern besser merkt.