Ich habe Claude Code's /dream zwei Wochen lang getestet

Ich habe Claude Code's /dream zwei Wochen lang getestet

Sitzung 34 bei meinem Laravel-Projekt hat mich gebrochen.

Ich hatte Claude gebeten, einen neuen Webhook-Handler fuer Stripe einzurichten. Einfache Aufgabe -- ich hatte das schon vorher bei genau diesem Projekt gemacht, und Claude hatte mir geholfen, die urspruengliche Zahlungsintegration ungefaehr in Sitzung 8 zu bauen. Die Antwort kam selbstsicher zurueck. Sauberer Code. Ordentliche Fehlerbehandlung. Ein Problem: Es hatte den Handler mit Sanctum-Middleware gebaut, die wir in Sitzung 15 entfernt hatten.

Ich starrte gute zehn Sekunden auf das Terminal. Dann ueberpruefte ich die Speicherdateien. Beide Eintraege standen drin -- "Auth verwendet Sanctum" aus Sitzung 8 und "Auth auf Custom JWT migriert" aus Sitzung 15 -- wie zwei Versionen der Geschichte, die friedlich nebeneinander existierten. Claude hatte die falsche gewaehlt. Es gab keine Moeglichkeit zu wissen, welche aktuell war, denn die Zeitstempel sagten Dinge wie "kuerzlich" und "in einer vorherigen Sitzung."

Das war der Moment, in dem ich aufhoerte, Autodream als interessantes Feature zu behandeln, das ich irgendwann mal testen wuerde, und anfing, es als etwas zu behandeln, das mein Workflow dringend brauchte.

Zwei Wochen spaeter, nachdem ich /dream auf fuenf aktiven Projekten ausgefuehrt hatte -- einem Laravel-Monolithen, einem Next.js SaaS-Dashboard, einem Python CLI-Tool, einem Claude Code Agent Swarm und einer Dokumentationsseite -- kann ich genau sagen, was Autodream gut macht, wo es mich ueberrascht hat und welcher blinde Fleck mich beinahe zwei Stunden Nacharbeit gekostet haette.

Das Gedaechtnisverfall-Problem ist schlimmer als man denkt

Wenn du Claude Code weniger als 15 Sitzungen lang bei einem einzelnen Projekt verwendet hast, bist du wahrscheinlich noch nicht auf diese Mauer gestossen. Geniesse die Flitterwochen. Fuer alle anderen -- die Entwickler, die 20, 30, 50+ Sitzungen auf komplexen Codebasen ausfuehren -- ist Gedaechtnisverfall kein theoretisches Problem. Es ist das, was stillschweigend das Urteilsvermoegen deines KI-Programmierpartners untergräbt.

Ich habe frueher ueber ein zweites Gehirn mit Claude Code aufbauen geschrieben, und Auto Memory war ein echter Durchbruch fuer diesen Workflow. Anstatt CLAUDE.md nach jeder Sitzung manuell zu aktualisieren, begann Claude, eigene Notizen zu speichern: Build-Befehle, Debugging-Muster, Architekturentscheidungen, Framework-Praeferenzen. Sitzung fuer Sitzung wuchs die Wissensbasis.

Der Teil, den ich nicht vorhergesehen hatte? Wachstum ohne Pflege ist nur Horten.

Nach 20+ Sitzungen bei meinem Laravel-Projekt enthielten Claudes Speicherdateien 847 Zeilen ueber sechs Themendateien verteilt. Einige dieser Zeilen widersprachen sich direkt. Andere verwiesen auf Debugging-Workarounds fuer Bugs, die ich Wochen zuvor behoben hatte. Relative Zeitstempel wie "gestern haben wir beschlossen, die Caching-Schicht zu wechseln" waren bedeutungslos -- welches gestern? Das von Sitzung 12 oder Sitzung 27?

Die Symptome sind anfangs subtil. Claude zoegert mehr. Statt "verwende den Redis Cache-Adapter, den wir eingerichtet haben" sagt es "du moechtest vielleicht Redis oder Memcached verwenden, je nach deinem Setup." Dieses Zoegern ist ein Signal. Es bedeutet, dass Claude widersprüchliche Informationen in seinen eigenen Notizen gefunden hat und sich entschied, auf Nummer sicher zu gehen, anstatt sich auf eine Antwort festzulegen, die falsch sein koennte.

Dann werden die Symptome weniger subtil. Veraltete Code-Muster. Verweise auf Dependencies, die du entfernt hast. Vorschlaege, die aktiv deiner aktuellen Architektur widersprechen. An diesem Punkt verbringst du mehr Zeit damit, Claude zu korrigieren, als Claude dir einspart.

Dies ist das Problem, das Autodream loesen sollte. Und nach zwei Wochen Tests kann ich bestaetigen: Es funktioniert. Aber das Wie ist wichtiger als das Was.

Was tatsaechlich passiert, wenn du /dream tippst

Hier ist die Sache, die niemand gut ueber Autodream erklaert: Es gibt zwei verschiedene Wege, es auszuloesen, und sie produzieren leicht unterschiedliche Ergebnisse.

Der manuelle Weg: Oeffne eine Claude Code-Sitzung, tippe /memory und suche nach dem Autodream-Schalter. Wenn er da ist, kannst du ihn einschalten. Du kannst auch "consolidate my memory using dream" direkt in den Chat tippen, und Claude startet den Konsolidierungs-Subagenten sofort.

Der automatische Weg: Sobald Autodream aktiviert ist, loest es sich selbst aus, wenn zwei Bedingungen gleichzeitig erfuellt sind -- mehr als 24 Stunden seit dem letzten Konsolidierungslauf UND du hattest seitdem 5 oder mehr Sitzungen. Beide Tore muessen offen sein. Zehn schnelle Sitzungen in zwei Stunden loesen es nicht aus. Eine Marathon-Sitzung ueber zwei Tage auch nicht. Dieses Doppeltor-Design verhindert unnoetige Verarbeitung bei wenig genutzten Projekten, waehrend aktive Projekte regelmaessig bereinigt werden.

Als ich meinen ersten manuellen Dream beim Laravel-Projekt ausloeste, erschien ein Statusindikator: "dreaming." Claude sperrte die Speicherdateien, um Schreibkonflikte zu verhindern (du kannst weiter programmieren -- es sperrt nur den Speicher, nicht deine Projektdateien), und startete das, was Anthropic intern den Vierphasen-Konsolidierungszyklus nennt.

Ich habe die Zeit gestoppt. Acht Minuten und dreiundvierzig Sekunden fuer ein Projekt mit 34 Sitzungen an angesammeltem Speicher.

Hier ist, was waehrend dieser acht Minuten passierte, Phase fuer Phase.

Die vier Phasen: Was ich tatsaechlich beobachtet habe

Ich habe genug Artikel gesehen, die die vier Phasen abstrakt beschreiben. Ich werde dir erzaehlen, wie sie in der Praxis aussehen, denn die Abstraktionen uebersehen die wichtigen Details.

Phase 1: Orientierung

Claudes Dream-Subagent scannt jede Speicherdatei in deinem Projektverzeichnis und erstellt das, was ich eine Wissenskarte nennen wuerde -- ein strukturelles Verstaendnis davon, welche Informationen existieren und wo sie sich befinden. Bei meinem Laravel-Projekt bedeutete das das Lesen von MEMORY.md (dem Hauptindex), plus fuenf themenspezifische Dateien, die Auto Memory ueber 34 Sitzungen erstellt hatte: architecture.md, debugging.md, decisions.md, preferences.md und api-patterns.md.

Die Orientierungsphase dauerte etwa 90 Sekunden. Ich konnte sehen, wie der Subagent jede Datei auflistete und ihre Groesse und das letzte Aenderungsdatum notierte. Das ist reine Aufklaerung -- noch keine Aenderungen.

Was ich interessant fand: Der Subagent bemerkte auch, welche Dateien unverhältnismäßig gross waren. Meine debugging.md war auf 312 Zeilen angewachsen -- hauptsaechlich veraltete Workarounds fuer Probleme, die ich Wochen zuvor behoben hatte. Die Orientierung markierte dies als hochprioritaeres Ziel fuer die Bereinigung.

Phase 2: Signale sammeln

Hier wird der Dream-Subagent chirurgisch. Er durchsucht deine Sitzungstranskripte -- die JSONL-Dateien, die jede Claude Code-Interaktion aufzeichnen -- und sucht nach spezifischen wertvollen Signalen. Nicht alles lesen. Nach Mustern suchen.

Was zaehlt als wertvolles Signal? Ich habe vier Kategorien ueber meine fuenf Projekte verfolgt:

Benutzerkorrekturen. Jedes Mal, wenn ich sagte "nein, das ist falsch" oder "das verwenden wir nicht mehr" oder "der aktuelle Ansatz ist eigentlich X." Diese Korrekturen sind Gold wert. Sie repraesentieren explizite Momente, in denen Claudes vorhandenes Wissen falsch war und der Mensch die richtige Antwort gab.

Architekturentscheidungen. Momente, in denen ich mich auf eine bestimmte technische Richtung festlegte: "Wir gehen mit Fastify statt Express," "Verwende Redis Cluster, nicht Standalone," "Die Zahlungsabstraktion wird das Adapter-Pattern verwenden."

Wiederholte Muster. Wenn drei verschiedene Sitzungen auf die gleiche Build-Befehl-Eigenheit oder den gleichen Deployment-Schritt verwiesen, ist das ein Signal, das es wert ist, aufbewahrt und zu einem einzigen sauberen Eintrag konsolidiert zu werden.

Explizite Speicherungen. Jedes Mal, wenn ich sagte "merk dir das" oder "speicher das im Gedaechtnis" oder Claude proaktiv entschied, etwas Wichtiges zu speichern.

Bei meinem Next.js-Projekt fand die Sammelphase 23 Benutzerkorrekturen ueber 28 Sitzungen. Dreiundzwanzig Mal hatte ich Claude gesagt, dass etwas, das es glaubte, falsch war. Einige dieser Korrekturen widersprachen einander, weil sich mein eigenes Denken weiterentwickelt hatte -- ich hatte Claude in Sitzung 10 korrigiert und dann die Korrektur in Sitzung 19 korrigiert. Die Sammelphase erfasste die gesamte Kette, damit die Konsolidierungsphase sie zur aktuellsten Wahrheit aufloesen konnte.

Phase 3: Konsolidierung

Dies ist die Phase, die ihr Gewicht wert ist. Der Dream-Subagent nimmt alles aus Phase 1 und 2 und fuehrt vier spezifische Operationen durch:

Datumskonvertierung. Jeder relative Zeitstempel wird in ein absolutes Datum umgewandelt. "Gestern haben wir beschlossen, Redis zu verwenden" aus einer Sitzung am 12. Maerz wird "Am 2026-03-12 beschlossen, Redis Cluster fuer horizontale Skalierung zu verwenden." Diese einzelne Operation eliminiert die zeitliche Verwirrung, die die meisten speicherbezogenen Halluzinationen verursacht.

Widerspruchsloesung. Wenn zwei Eintraege in Konflikt stehen, verwendet der Subagent die Sitzungszeitstempel und alle zugehoerigen Korrekturen, um festzustellen, welcher aktuell ist. Bei meinem Laravel-Projekt identifizierte er korrekt, dass "Auth verwendet Sanctum" (Sitzung 8) durch "Auf Custom JWT migriert" (Sitzung 15) ersetzt wurde. Der Sanctum-Eintrag wurde geloescht. Nicht archiviert. Geloescht. Denn veraltete Architekturverweise in Speicherdateien sind aktiv schaedlich -- sie sind schlimmer als gar keinen Eintrag zu haben.

Duplikat-Zusammenfuehrung. Drei Sitzungen notierten, dass der Build-Befehl --legacy-peer-deps erfordert. Diese wurden zu einem einzigen sauberen Eintrag mit dem Datum der ersten Beobachtung zusammengefuehrt.

Entscheidungsketten-Verknuepfung. Das hat mich ueberrascht. Der Subagent verknuepfte zusammengehoerige Entscheidungen zu narrativen Ketten. Bei meinem Python CLI-Projekt verknuepfte er "Click statt argparse gewaehlt (5. Maerz)" mit "Click Group fuer Unterbefehle hinzugefuegt (9. Maerz)" mit "Click-Befehle auf Decorators umgestellt (14. Maerz)" zu einer einzigen architekturalen Erzaehlung. Diese Kette gibt zukuenftigen Claude-Sitzungen echten Kontext darueber, wie sich die CLI-Struktur entwickelt hat -- nicht nur, was sie jetzt ist, sondern warum sie so ist, wie sie ist.

Phase 4: Bereinigen und Indexieren

Die letzte Phase ist Aufraeumen. Der Subagent kuerzt den Haupt-MEMORY.md-Index auf unter 200 Zeilen -- das ist die Schwelle fuer das, was beim Start geladen wird, also ist alles ueber 200 Zeilen fuer neue Sitzungen effektiv unsichtbar. Veraltete Debugging-Notizen werden entfernt. Geloeste Probleme werden archiviert. Das Ergebnis ist ein Speichersystem, das schlank, aktuell und intern konsistent ist.

Der Speicher meines Laravel-Projekts ging von 847 Zeilen ueber sechs Dateien auf 193 Zeilen ueber vier Dateien. Die debugging.md-Datei, die auf 312 Zeilen angewachsen war, wurde auf 41 reduziert -- nur die aktiven, ungeloesten Debugging-Muster ueberlebten.

Das ist eine 77%ige Reduktion des Speichervolumens ohne Verlust aktueller, relevanter Informationen. Die Informationsqualitaet stieg sogar, denn das Entfernen von Rauschen verbesserte Claudes Faehigkeit, das Verbliebene zu finden und zu nutzen.

Fuenf Projekte, vierzehn Tage: Die echten Ergebnisse

Ueber Phasen zu reden ist eine Sache. Ergebnisse zu zeigen eine andere. Hier ist, was sich tatsaechlich bei jedem Projekt aenderte, nachdem ich Autodream zwei Wochen lang konsequent ausgefuehrt hatte.

Projekt 1: Laravel-Monolith (34 Sitzungen)

Dies war das Projekt, das mich dazu brachte, Autodream zu testen. Die Sanctum-vs-JWT-Verwirrung war nur das offensichtlichste Symptom.

Vor Dream: Claude zoegerte bei 6 von 10 Architekturfragen. Schlug regelmaessig veraltete Muster vor. Verwies auf Pakete, die wir entfernt hatten. Durchschnittlich nuetzlicher Output pro Prompt: vielleicht 70% -- der Rest brauchte manuelle Korrektur.

Nach erstem Dream: Sofortige Verbesserung. Claude hoerte auf, bei Auth zu zoegern. Hoerte auf, Sanctum zu referenzieren. Die Vorschlaege zur Zahlungsintegration stimmten mit unserem aktuellen Adapter-Pattern ueberein. Aber ich bemerkte, dass ein Eintrag entfernt wurde, den ich eigentlich behalten wollte -- eine Notiz ueber eine spezifische PostgreSQL-Indexoptimierung, die noch relevant war. Ich fuegte sie manuell wieder hinzu.

Nach zwei Wochen (3 Dream-Zyklen): Der Speicher fuehlte sich kuratiert an. Claudes Vorschlaege spiegelten konsistent die aktuelle Architektur wider. Keine Widersprueche mehr. Das Zoegern sank bei Themen im Speicher auf nahezu Null. Nuetzlicher Output pro Prompt stieg auf etwa 90%.

Projekt 2: Next.js SaaS-Dashboard (28 Sitzungen)

Das SaaS-Projekt hatte ein anderes Speicherproblem: keine Widersprueche, sondern schiere Menge. 28 Sitzungen Feature-Entwicklung hatten umfangreiche Notizen ueber Komponentenmuster, API-Integrationsdetails, State-Management-Entscheidungen und Styling-Konventionen produziert. Die Speicherdateien waren gruendlich, aber langsam zu parsen -- Claude verbrauchte Context-Window-Tokens fuer das Laden von Informationen, die es fuer die meisten Aufgaben nicht brauchte.

Vor Dream: Die Antwortzeit fuehlte sich bei diesem Projekt im Vergleich zu anderen traege an. Claude fuegte manchmal irrelevanten Kontext in seine Erklaerungen ein, wie den Verweis auf die Chart-Bibliothek-Entscheidung, wenn ich nach Formularvalidierung fragte.

Nach erstem Dream: Speicherdateigroesse sank um 63%. Der Dream-Subagent hatte festgestellt, dass 40% der angesammelten Notizen ueber abgeschlossene Feature-Entscheidungen waren, die keinen aktiven Abruf mehr benoetigten. Er archivierte die Entscheidungshistorie, behielt aber den aktuellen Stand.

Nach zwei Wochen: Antworten fuehlten sich merklich schneller an. Claude blieb auf den relevanten Kontext fuer jede Aufgabe fokussiert, anstatt alles zu laden. Die Verbesserung war nicht dramatisch in der Output-Qualitaet -- sie war dramatisch in der Output-Relevanz.

Projekt 3: Python CLI-Tool (19 Sitzungen)

Weniger Sitzungen bedeuteten weniger Verfall. Das CLI-Projekt war meine Kontrollgruppe -- ich wollte sehen, ob es sich lohnt, Autodream bei Projekten auszufuehren, die die Degradationsschwelle noch nicht erreicht hatten.

Vor Dream: Speicher war relativ sauber. Kleine Redundanzen, aber keine grossen Widersprueche.

Nach erstem Dream: Bescheidene Bereinigung. Entfernte 8 veraltete Debugging-Notizen und konsolidierte 3 doppelte Eintraege ueber die Click-Framework-Konfiguration. Gesamte Speicherreduktion: 31%.

Fazit: Bei Projekten mit weniger als 20 Sitzungen ist Autodream hilfreich, aber nicht transformativ. Die automatische Ausloeser-Schwelle (24 Stunden + 5 Sitzungen) ist gut kalibriert -- sie verschwendet keine Zyklen bei Projekten, die es noch nicht brauchen.

Projekt 4: Claude Code Agent Swarm (41 Sitzungen)

Das war der interessanteste Test. Mein Agent Swarm-Architektur-Projekt hatte den komplexesten Speicher, weil es Meta-Entscheidungen darueber enthielt, wie KI-Agenten koordinieren sollten. Die Speicherdateien enthielten verschachtelte Abstraktionen -- Notizen ueber Agentenverhalten, Notizen ueber Speicherverwaltung (ironisch, angesichts dessen, was ich testete), und Notizen ueber Inter-Agenten-Kommunikationsprotokolle.

Vor Dream: Der Speicher war ein Labyrinth. Claude verwechselte manchmal seinen eigenen operativen Kontext mit den Agenten-Designmustern des Projekts. Es verwies auf "das Speichersystem des Agenten" und ich konnte nicht feststellen, ob es sein eigenes Auto Memory meinte oder das Speichersystem, das ich fuer den Swarm baute.

Nach erstem Dream: Die Konsolidierungsphase handhabte das wunderbar. Sie trennte Notizen auf Projektebene (ueber den Swarm, den ich baute) von operativen Notizen (ueber Claudes eigenes Verhalten in diesem Projekt). Zwei separate Themendateien. Keine Ambiguitaet mehr.

Nach zwei Wochen: Hier hat Autodream mein volles Vertrauen verdient. Der Speicher des Agent-Swarm-Projekts wurde zum am besten organisierten aller Projekte, an denen ich gearbeitet habe. Entscheidungen verknuepft mit Daten verknuepft mit Begruendungen. Aktuelle Architektur sauber getrennt von historischen Alternativen. Claude ging von "verwirrt ueber seinen eigenen Kontext" zu "der sachkundigste Mitarbeiter, den ich bei diesem Projekt hatte."

Projekt 5: Dokumentationsseite (12 Sitzungen)

Die Dokumentationsseite war ein Leichtgewicht-Projekt -- hauptsaechlich Content-Generierung und Markdown-Formatierung. Ich nahm es mit, um zu testen, ob Autodream ein einfaches Projekt zu aggressiv bereinigen wuerde.

Vor Dream: Sauberer, minimaler Speicher. 87 Zeilen insgesamt.

Nach erstem Dream: Auf 64 Zeilen reduziert. Veraltete Inhaltskalender-Referenzen entfernt und Style-Guide-Eintraege konsolidiert.

Fazit: Autodream handhabte das einfache Projekt elegant. Kein Uebermaessiges Bereinigen. Keine Entfernung aktiver Informationen. Es erkannte korrekt, dass ein Dokumentationsprojekt weniger zeitliche Abhaengigkeiten hat als ein Code-Projekt, und passte sich entsprechend an.

Der Haken, der mich beinahe gekostet haette

Hier ist etwas, das jeder Early Adopter wissen sollte, denn ich haette es beinahe auf die harte Tour gelernt.

Autodream hat eine klare Meinung darueber, was "veraltet" ist. Seine Heuristik fuer Veralterung umfasst Eintraege, die in juengsten Sitzungen nicht referenziert oder verstaerkt wurden. Normalerweise ist das genau das, was man will -- wenn man eine Information in 15 Sitzungen nicht gebraucht hat, ist sie wahrscheinlich nicht kritisch.

Aber manchmal sind wichtige Informationen ruhend. Bei meinem Laravel-Projekt war die PostgreSQL-Indexoptimierungs-Notiz, die ich frueher erwaehnt habe, relevant, aber in letzter Zeit nicht aufgetaucht, weil ich die Query-Schicht wochenlang nicht angefasst hatte. Der Dream-Subagent bereinigte sie. Ich habe es bei meiner Post-Dream-Pruefung bemerkt und sie wieder hinzugefuegt.

Die Loesung ist einfach: Erstelle ein Backup deines Speicherverzeichnisses vor deinem ersten Dream-Zyklus.

cp -r ~/.claude/projects/$(pwd | sed 's|/|%2F|g')/memory ~/claude-memory-backup-$(date +%Y%m%d)

Pruefe dann den Unterschied nach Abschluss des Dreams. Schau, was entfernt wurde. Alles, was nicht haette bereinigt werden sollen, fuege es mit einer expliziten Markierung wieder hinzu: "KEEP: [Grund, warum dies noch relevant ist]." Ich habe nicht bestaetigt, ob der Dream-Subagent KEEP-Markierungen respektiert, aber in meinen Tests neigen Eintraege mit explizitem Kontext darueber, warum sie wichtig sind, dazu, Bereinigungszyklen zu ueberleben.

Der zweite Haken: Autodream verarbeitet nur Speicherdateien. Es beruehrt weder deinen Code, deine CLAUDE.md noch irgendwelche Projektdateien. Das klingt offensichtlich, aber ich habe Verwirrung in Entwickler-Communities gesehen, wo Leute befuerchteten, es koennte ihre Codebasis veraendern. Das tut es nicht. Die Sperre, die es waehrend des Dreamens setzt, gilt ausschliesslich fuer das Speicherverzeichnis.

Wann /dream manuell ausloesen vs. automatisch laufen lassen

Nach zwei Wochen Tests mit beiden Ansaetzen, hier ist meine Empfehlung.

Lass es automatisch laufen bei Projekten im stabilen Betrieb, in denen du regelmaessig Features entwickelst. Die 24-Stunden + 5-Sitzungen-Schwelle ist fuer diesen Workflow gut kalibriert. Du kommst am naechsten Tag zu leicht sauberem Speicher zurueck, ohne darueber nachzudenken.

Loese es manuell aus in drei spezifischen Situationen:

Nach einem grossen Refactoring. Wenn du gerade dein Authentifizierungssystem umstrukturiert, dein Datenbankschema neu aufgebaut oder Frameworks migriert hast, enthalten deine Speicherdateien garantiert veraltete Architekturverweise. Warte nicht 24 Stunden. Fuehre /dream sofort nach Ende der Refactoring-Sitzung aus.

Wenn Claude anfaengt zu zoegern. Wenn Claude beginnt, mit "je nach deinem Setup" oder "du koenntest in Betracht ziehen" bei Themen zu antworten, wo es definitives Wissen haben sollte, ist das das Speicherverwirrungssignal. Ein manueller Dream-Zyklus klaert das auf.

Vor einer kritischen Sitzung. Wenn du eine komplexe Funktion angehen willst, die davon abhaengt, dass Claude den aktuellen Zustand deines Projekts versteht -- eine Zahlungsintegration, ein Sicherheitsaudit, ein Performance-Optimierungssprint -- stellt ein Pre-Session-Dream sicher, dass Claude mit sauberen, aktuellen Informationen arbeitet.

Ich habe mich auf ein Muster eingependelt: automatisch laufen lassen fuer die taegliche Arbeit, manuell ausloesen nach jeder Sitzung, in der ich signifikante Architekturuenderungen vorgenommen habe. Das haelt den Speicher konsistent sauber, ohne dass ich die meisten Tage darueber nachdenken muss.

Wenn du lieber jemanden haettest, der diese Art optimierter KI-Workflows von Grund auf baut, uebernehme ich Claude Code-Automatisierung und KI-Agenten-Auftraege. Du kannst sehen, was ich gebaut habe auf fiverr.com/s/EgxYmWD.

Das groessere Bild: Claude Code wird ein zustandsbehafteter Assistent

Hier ist, was die meisten Leute ueber Autodream uebersehen, und es ist der Grund, warum ich zwei Wochen damit verbracht habe, es zu testen, anstatt nur die Dokumentation zu lesen.

Auto Memory gab Claude Code die Faehigkeit, Wissen anzusammeln. Das war ein enormer Sprung -- von einem zustandslosen Tool zu etwas, das sich an dein Projekt erinnert. Aber Ansammlung ohne Kuratierung ist nur Horten. Jedes Wissenssystem, das nur waechst, bricht irgendwann unter seinem eigenen Gewicht zusammen. Dein E-Mail-Postfach. Dein Notion-Workspace. Deine Browser-Lesezeichen. Ansammlung ist der einfache Teil. Pflege ist der schwere Teil.

Autodream ist die Pflegeschicht. Es ist der Unterschied zwischen Notizen machen und ein funktionierendes Wissensmanagement-System haben. Und wenn du beides kombinierst -- Auto Memory fuer die Erfassung, Autodream fuer die Kuratierung -- bekommst du etwas qualitativ anderes als jedes einzelne allein.

Claude Code hat jetzt vier verschiedene Speicherschichten, die zusammenarbeiten:

1. CLAUDE.md -- die Anweisungen, die du manuell schreibst. Die Verfassung deines Projekts.
2. Auto Memory -- Notizen, die Claude waehrend der Sitzungen fuer sich selbst schreibt. Das taegliche Tagebuch.
3. Session Memory -- Gespraechskontinuitaet innerhalb einer einzelnen Sitzung. Kurzzeitgedaechtnis.
4. Autodream -- periodische Konsolidierung von allem Angesammelten. Das naechtliche Aufraeum-Team.

Das ist kein Chat-Tool mit einem Context-Window-Hack. Das ist eine Speicherarchitektur. Bedienungsanleitung, Protokollfuehrer, Kurzzeitgedaechtnis und etwas, das bemerkenswert nach Schlaf aussieht -- still zusammengebaut in drei Monaten von Anthropics Claude Code-Team.

Das Paper von UC Berkeley und Letta vom April 2025 -- "Sleep-time Compute: Beyond Inference Scaling at Test-time" -- zeigte, dass KI-Modelle, die Berechnungen waehrend der Leerlaufzeit durchfuehren, die Test-Time-Compute bei gleicher Genauigkeit um das 2,5-fache reduzieren koennen. Autodream ist die produktisierte Version dieser Erkenntnis. Nutze die tote Zeit zwischen Sitzungen, um das Arbeitswissen des Modells zu verbessern, und die aktiven Sitzungen werden schaerfer.

Ich benutze Claude Code seit den fruehen Betas. Ich habe ueber Claude Code-Workflows meistern geschrieben, ueber Claude Skills, ueber den Bau von selbstverbessernden KI-Systemen. Autodream ist die bedeutendste Quality-of-Life-Verbesserung seit Auto Memory selbst. Nicht weil es eine auffaellige neue Faehigkeit hinzufuegt -- sondern weil es den schleichenden Verfall behebt, der jede andere Faehigkeit untergräbt.

Automemory vs. Autodream: Das vollstaendige Bild

Ich sehe immer wieder, dass Leute diese beiden Features verwechseln oder als austauschbar behandeln. Das sind sie nicht. Sie sind komplementaere Haelften eines einzigen Systems. Hier ist die klarste Aufschluesselung, die ich nach ausgiebiger Nutzung beider geben kann:

Das staerkste Setup verwendet beides. Automemory ohne Autodream ist ein Notizbuch, das nie durchgesehen wird. Autodream ohne Automemory hat nichts zu konsolidieren. Zusammen bilden sie einen Schreib-Pruef-Verstaerk-Zyklus, der mit der Zeit tatsaechlich besser wird statt schlechter.

Das praktische Setup: Das heute zum Laufen bringen

Wenn du jetzt sofort mit Autodream beginnen moechtest, hier ist der exakte Workflow, auf den ich nach zwei Wochen Iteration gekommen bin.

Schritt 1: Pruefe deine Version. Autodream erfordert Claude Code v2.1.59 oder spaeter. Fuehre claude --version in deinem Terminal aus. Wenn du hinterherhinkst, aktualisiere zuerst.

Schritt 2: Aktiviere es. Oeffne eine Claude Code-Sitzung bei einem Projekt mit mindestens 10+ Sitzungen an angesammeltem Speicher. Tippe /memory. Suche nach dem Autodream-Schalter. Wenn du ihn siehst, schalte ihn ein.

Wenn du den Schalter nicht siehst -- Anthropic rollt dies Stand Maerz 2026 noch schrittweise aus -- kannst du eine manuelle Konsolidierung ausloesen, indem du tippst: "Consolidate my memory files. Review all existing memories, remove contradictions, convert relative dates to absolute dates, merge duplicates, and prune stale entries."

Schritt 3: Erstelle zuerst ein Backup. Ernsthaft. Fuehre den Backup-Befehl aus, den ich frueher geteilt habe. Der erste Dream-Zyklus ist der aggressivste, weil er den meisten angesammelten Verfall bereinigen muss. Du willst ein Sicherheitsnetz.

Schritt 4: Ueberprüfe die Ergebnisse. Nachdem der Dream abgeschlossen ist (8-10 Minuten fuer die meisten Projekte), oeffne deine Speicherdateien und scanne sie durch. Achte auf:

• Eintraege, die entfernt wurden, aber nicht haetten entfernt werden sollen
• Widerspruchsloesungen, die den falschen Gewinner gewaehlt haben
• Datumskonvertierungen, die inkorrekt erscheinen

In meinen Tests ueber fuenf Projekte war die Fehlerquote niedrig -- ich habe eine falsche Bereinigung bei Hunderten von Operationen gefunden. Aber "niedrig" ist nicht "null," und die Kosten fuer das erneute Hinzufuegen eines bereinigten Eintrags sind viel niedriger als die Kosten fuer den Verlust wichtigen Projektkontexts.

Schritt 5: Vertraue dem Auto-Trigger fuer die taegliche Pflege. Sobald du verifiziert hast, dass der erste Dream-Zyklus gute Ergebnisse geliefert hat, lass den automatischen Trigger die laufende Konsolidierung uebernehmen. Die 24-Stunden + 5-Sitzungen-Schwelle haelt alles sauber ohne Ueberverarbeitung.

Schritt 6: Loese manuell nach grossen Aenderungen aus. Datenbank refactored? Framework gewechselt? Kernmodul neu gebaut? Fuehre /dream vor deiner naechsten Sitzung aus. Warte nicht auf den Auto-Trigger.

Was das fuer unsere Arbeit mit KI bedeutet

Vor einem Jahr haette die Idee, dass dein KI-Codierassistent zwischen Sitzungen "schlaeft" -- seine Erinnerungen durchgeht, Wichtiges verstaerkt, Veraltetes bereinigt -- wie anthropomorpher Unsinn geklungen. Heute ist es ein Schalter in deinem Terminal.

Die Benennung ist kein Zufall. Anthropic haette es "Speicherbereinigung" oder "automatische Konsolidierung" nennen koennen. Sie nannten es "dream." Die System-Prompt sagt woertlich: "You are performing a dream -- a reflective pass over your memory files." Diese Sprachwahl signalisiert Absicht. Sie bauen keine schlauere Autovervollstaendigung. Sie bauen etwas, das ein bestaendiges, sich entwickelndes Verstaendnis deines Projekts pflegt -- etwas, das besser darin wird, dir zu helfen, je laenger ihr zusammenarbeitet, anstatt langsam unter dem Gewicht seiner eigenen angesammelten Notizen zu degradieren.

Nach Sitzung 34 bei meinem Laravel-Projekt -- der, in der Claude selbstsicher Sanctum-Middleware vorschlug, die wir neunzehn Sitzungen zuvor entfernt hatten -- habe ich ernsthaft hinterfragt, ob langfristige Claude Code-Projekte nachhaltig sind. Der Speicherverfall fuehlte sich wie eine Unvermeidlichkeit an. Je mehr man es benutzte, desto rauschiger wurde der Speicher, und je rauschiger der Speicher wurde, desto unzuverlaessiger wurden die Vorschlaege.

Drei Dream-Zyklen spaeter fuehlte sich Sitzung 47 beim selben Projekt an wie die Zusammenarbeit mit einem Senior Engineer, der das Wochenende damit verbracht hatte, die Projektdokumentation zu ueberpruefen. Saubere Referenzen. Genaues Architekturwissen. Kein Zoegern bei Entscheidungen, die wir gemeinsam getroffen hatten.

Das ist keine kleine Verbesserung. Das ist der Unterschied zwischen einem KI-Tool, mit dem du kaempfst, und einem KI-Mitarbeiter, dem du vertraust.

Das Feature wird noch ausgerollt. Nicht jeder hat den Schalter schon. Aber wenn du Claude Code v2.1.59 oder spaeter ausfuehrst und Projekte mit 20+ Sitzungen angesammeltem Speicher hast, pruefe heute /memory. Wenn die Autodream-Option da ist, schalte sie ein.

Dein KI-Agent braucht Schlaf. Und ehrlich? Nachdem ich gesehen habe, was passiert, wenn er ihn bekommt, gilt das fuer jedes andere KI-Tool in deinem Stack auch.

Häufig gestellte Fragen

Wie loese ich Autodream in Claude Code manuell aus?

Tippe /memory in deiner Claude Code-Sitzung und suche nach dem Autodream-Schalter. Alternativ tippe "consolidate my memory using dream" direkt in den Chat. Die Konsolidierung dauert 8-10 Minuten und laeuft im Hintergrund, ohne deine aktive Sitzung zu blockieren. Erfordert Claude Code v2.1.59 oder spaeter.

Loescht Autodream wichtige Erinnerungen?

Autodream bereinigt Eintraege, die es als veraltet identifiziert -- Informationen, die in juengsten Sitzungen nicht referenziert oder verstaerkt wurden. In seltenen Faellen kann es ruhende-aber-relevante Eintraege entfernen. Erstelle ein Backup deines Speicherverzeichnisses vor deinem ersten Dream-Zyklus und ueberprüfe die Ergebnisse. Fuer eine detaillierte Beschreibung der Bereinigungslogik siehe den Abschnitt ueber die Vier Phasen oben.

Wie oft sollte ich /dream manuell ausfuehren?

Lass den Auto-Trigger die taegliche Pflege uebernehmen (er laeuft alle 24+ Stunden nach 5+ Sitzungen). Loese manuell nach grossen Refactorings, Framework-Migrationen oder wenn Claude bei Fragen zoegert, die es mit Sicherheit beantworten sollte, aus. Ich fuehre manuelle Dreams bei aktiven Projekten etwa zweimal pro Woche aus.

Was ist der Unterschied zwischen Auto Memory und Autodream?

Auto Memory erfasst Notizen waehrend aktiver Sitzungen -- es schreibt vorwaerts. Autodream konsolidiert diese Notizen zwischen Sitzungen -- es schaut zurueck, bereinigt Widersprueche, konvertiert relative Daten und entfernt veraltete Eintraege. Beides wird benoetigt: Auto Memory ohne Autodream akkumuliert Rauschen, Autodream ohne Auto Memory hat nichts zu konsolidieren. Siehe die Vergleichstabelle oben fuer die vollstaendige Aufschluesselung.

Veraendert Autodream meine Code-Dateien oder CLAUDE.md?

Nein. Autodream verarbeitet ausschliesslich Speicherdateien im Speicherverzeichnis deines Projekts. Es beruehrt keinen Quellcode, keine Konfigurationsdateien und nicht deine CLAUDE.md. Die Dateisperre, die es waehrend der Konsolidierung setzt, betrifft nur Speicherdateien, und du kannst normal weiter programmieren, waehrend ein Dream-Zyklus laeuft.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io