Ik heb Claude Code's /dream twee weken lang getest

Ik heb Claude Code's /dream twee weken lang getest

Sessie 34 van mijn Laravel-project brak me.

Ik had Claude gevraagd om een nieuwe webhook-handler voor Stripe op te zetten. Simpele taak -- ik had het eerder gedaan op exact dit project, en Claude had me geholpen bij het bouwen van de oorspronkelijke betalingsintegratie rond sessie 8. Het antwoord kwam zelfverzekerd terug. Schone code. Correcte foutafhandeling. Eén probleem: het had de handler gebouwd met Sanctum-middleware die we in sessie 15 hadden verwijderd.

Ik staarde een goede tien seconden naar de terminal. Toen controleerde ik de geheugenbestanden. Beide vermeldingen stonden erin -- "Auth gebruikt Sanctum" uit sessie 8 en "Auth gemigreerd naar custom JWT" uit sessie 15 -- als twee versies van de geschiedenis die vreedzaam naast elkaar bestonden. Claude had de verkeerde gekozen. Er was geen manier om te weten welke actueel was, want de tijdstempels zeiden dingen als "recent" en "in een vorige sessie."

Dat was het moment waarop ik stopte Autodream te behandelen als een interessante functie die ik nog wel eens zou testen, en het ging behandelen als iets dat mijn workflow dringend nodig had.

Twee weken later, na het draaien van /dream op vijf actieve projecten -- een Laravel-monoliet, een Next.js SaaS-dashboard, een Python CLI-tool, een Claude Code agent swarm, en een documentatiesite -- kan ik je precies vertellen wat Autodream goed doet, waar het me verraste, en het ene blinde vlekje dat me bijna twee uur herwerk kostte.

Het geheugenverlies-probleem is erger dan je denkt

Als je Claude Code minder dan 15 sessies op een enkel project hebt gebruikt, heb je deze muur waarschijnlijk nog niet geraakt. Geniet van de wittebroodsweken. Voor alle anderen -- de ontwikkelaars die 20, 30, 50+ sessies draaien op complexe codebases -- geheugenverlies is geen theoretisch probleem. Het is datgene wat stilletjes het oordeel van je AI-programmeerpartner ondermijnt.

Ik schreef eerder over een tweede brein bouwen met Claude Code, en Auto Memory was een echte doorbraak voor die workflow. In plaats van CLAUDE.md handmatig bij te werken na elke sessie, begon Claude zijn eigen notities op te slaan: build-commando's, debugging-patronen, architectuurbeslissingen, framework-voorkeuren. Sessie na sessie groeide de kennisbank.

Het deel dat ik niet had voorzien? Groei zonder onderhoud is gewoon hamsteren.

Na 20+ sessies op mijn Laravel-project bevatten Claude's geheugenbestanden 847 regels verspreid over zes onderwerpbestanden. Sommige van die regels spraken elkaar direct tegen. Andere verwezen naar debugging-workarounds voor bugs die ik weken geleden had opgelost. Relatieve tijdstempels zoals "gisteren besloten we om de caching-laag te wisselen" waren betekenisloos -- welke gisteren? Die van sessie 12 of sessie 27?

De symptomen zijn in het begin subtiel. Claude gaat meer twijfelen. In plaats van "gebruik de Redis cache-adapter die we hebben opgezet," zegt het "je wilt misschien Redis of Memcached gebruiken, afhankelijk van je setup." Die aarzeling is een signaal. Het betekent dat Claude tegenstrijdige informatie in zijn eigen notities heeft gevonden en ervoor koos om voorzichtig te zijn in plaats van zich te committeren aan een antwoord dat misschien fout is.

Daarna worden de symptomen minder subtiel. Verouderde codepatronen. Verwijzingen naar dependencies die je hebt verwijderd. Suggesties die actief in strijd zijn met je huidige architectuur. Op dat punt besteed je meer tijd aan het corrigeren van Claude dan Claude jou bespaart.

Dit is het probleem dat Autodream is gebouwd om op te lossen. En na twee weken testen kan ik bevestigen: het werkt. Maar het hoe is belangrijker dan het wat.

Wat er daadwerkelijk gebeurt als je /dream typt

Hier is het ding dat niemand goed uitlegt over Autodream: er zijn twee verschillende manieren om het te activeren, en ze produceren iets verschillende resultaten.

De handmatige route: Open een Claude Code-sessie, typ /memory, en zoek naar de Autodream-schakelaar. Als die er is, kun je hem aanzetten. Je kunt ook "consolidate my memory using dream" direct in de chat typen, en Claude start de consolidatie-subagent ter plekke.

De automatische route: Zodra Autodream is ingeschakeld, activeert het zichzelf wanneer aan twee voorwaarden tegelijk is voldaan -- meer dan 24 uur sinds de laatste consolidatierun EN je hebt 5 of meer sessies gehad sindsdien. Beide poorten moeten opengaan. Tien snelle sessies in twee uur activeren het niet. Eén marathonsessie die twee dagen bestrijkt evenmin. Dit dubbele-poort-ontwerp voorkomt onnodige verwerking op licht gebruikte projecten terwijl actieve projecten regelmatig worden opgeschoond.

Toen ik mijn eerste handmatige dream op het Laravel-project activeerde, verscheen er een statusindicator: "dreaming." Claude vergrendelde de geheugenbestanden om schrijfconflicten te voorkomen (je kunt doorcoderen -- het vergrendelt alleen geheugen, niet je projectbestanden) en startte wat Anthropic intern de vierfase-consolidatiecyclus noemt.

Ik heb het getimed. Acht minuten en drieënveertig seconden voor een project met 34 sessies aan opgebouwd geheugen.

Dit is wat er tijdens die acht minuten gebeurde, fase voor fase.

De vier fasen: wat ik daadwerkelijk waarnam

Ik heb genoeg artikelen gezien die de vier fasen abstract beschrijven. Ik ga je vertellen hoe ze er in de praktijk uitzien, want de abstracties missen de belangrijke details.

Fase 1: Oriëntatie

Claude's dream-subagent scant elk geheugenbestand in je projectdirectory en bouwt wat ik een kenniskaart zou noemen -- een structureel begrip van welke informatie bestaat en waar die zich bevindt. Op mijn Laravel-project betekende dit het lezen van MEMORY.md (de hoofdindex), plus vijf onderwerpspecifieke bestanden die Auto Memory over 34 sessies had aangemaakt: architecture.md, debugging.md, decisions.md, preferences.md en api-patterns.md.

De oriëntatiefase duurde ongeveer 90 seconden. Ik kon zien dat de subagent elk bestand opsomde en de grootte en laatste wijzigingsdatum noteerde. Dit is pure verkenning -- nog geen wijzigingen.

Wat ik interessant vond: de subagent merkte ook op welke bestanden onevenredig groot waren. Mijn debugging.md was opgeblazen tot 312 regels -- voornamelijk verouderde workarounds voor problemen die ik weken geleden had opgelost. Oriëntatie markeerde dit als een hoge-prioriteit doelwit voor opschoning.

Fase 2: Signalen verzamelen

Dit is waar de dream-subagent chirurgisch wordt. Het doorzoekt je sessietranscripties -- de JSONL-bestanden die elke Claude Code-interactie vastleggen -- op zoek naar specifieke waardevolle signalen. Niet alles lezen. Zoeken naar patronen.

Wat telt als een waardevol signaal? Ik heb vier categorieën bijgehouden over mijn vijf projecten:

Gebruikerscorrecties. Elke keer dat ik zei "nee, dat klopt niet" of "dat gebruiken we niet meer" of "de huidige aanpak is eigenlijk X." Deze correcties zijn goud waard. Ze vertegenwoordigen expliciete momenten waarop Claude's bestaande kennis fout was, en de mens het juiste antwoord gaf.

Architectuurbeslissingen. Momenten waarop ik me vastlegde op een specifieke technische richting: "We gaan met Fastify in plaats van Express," "Gebruik Redis Cluster, niet standalone," "De betalingsabstractie zal het adapter-patroon gebruiken."

Herhaalde patronen. Als drie verschillende sessies verwezen naar dezelfde build-commando-eigenaardigheid of dezelfde deployment-stap, is dat een signaal dat het waard is om te bewaren en te consolideren tot één schone vermelding.

Expliciete opslagen. Elk moment dat ik zei "onthoud dit" of "sla dit op in geheugen" of Claude proactief besloot om iets belangrijks op te slaan.

Op mijn Next.js-project vond de verzamelfase 23 gebruikerscorrecties over 28 sessies. Drieëntwintig keer had ik Claude verteld dat iets dat het geloofde fout was. Sommige van die correcties spraken elkaar tegen omdat mijn eigen denken was geëvolueerd -- ik had Claude gecorrigeerd in sessie 10 en vervolgens de correctie gecorrigeerd in sessie 19. De verzamelfase legde de volledige keten vast zodat de consolidatiefase deze kon oplossen naar de meest recente waarheid.

Fase 3: Consolidatie

Dit is de fase die zijn gewicht waard is. De dream-subagent neemt alles uit fase 1 en 2 en voert vier specifieke operaties uit:

Datumconversie. Elk relatief tijdstempel wordt omgezet naar een absoluut datum. "Gisteren besloten om Redis te gebruiken" uit een sessie op 12 maart wordt "Op 2026-03-12, besloten om Redis Cluster te gebruiken voor horizontale schaalbaarheid." Deze enkele operatie elimineert de temporele verwarring die de meeste geheugen-gerelateerde hallucinaties veroorzaakt.

Tegenspraak-oplossing. Wanneer twee vermeldingen conflicteren, gebruikt de subagent de sessietijdstempels en eventuele bijbehorende correcties om te bepalen welke actueel is. Op mijn Laravel-project identificeerde het correct dat "Auth gebruikt Sanctum" (sessie 8) was vervangen door "Gemigreerd naar custom JWT" (sessie 15). De Sanctum-vermelding werd verwijderd. Niet gearchiveerd. Verwijderd. Want verouderde architectuurverwijzingen in geheugenbestanden zijn actief schadelijk -- ze zijn erger dan helemaal geen vermelding hebben.

Duplicaat-samenvoeging. Drie sessies noteerden dat het build-commando --legacy-peer-deps vereist. Die werden samengevoegd tot één schone vermelding met de datum waarop het voor het eerst was waargenomen.

Beslissingsketen-koppeling. Deze verraste me. De subagent verbond gerelateerde beslissingen tot narratieve ketens. Op mijn Python CLI-project koppelde het "Gekozen voor Click boven argparse (5 maart)" met "Click group voor subcommando's toegevoegd (9 maart)" met "Click-commando's gerefactord naar decorators (14 maart)" tot één architecturaal verhaal. Die keten geeft toekomstige Claude-sessies echte context over hoe de CLI-structuur is geëvolueerd -- niet alleen wat het nu is, maar waarom het is wat het is.

Fase 4: Opschonen en indexeren

De laatste fase is opruimen. De subagent verkort de hoofd-MEMORY.md-index tot onder de 200 regels -- dat is de drempel voor wat bij het opstarten wordt geladen, dus alles boven 200 regels is effectief onzichtbaar voor nieuwe sessies. Verouderde debugging-notities worden verwijderd. Opgeloste problemen worden gearchiveerd. Het resultaat is een geheugensysteem dat lean, actueel en intern consistent is.

Het geheugen van mijn Laravel-project ging van 847 regels over zes bestanden naar 193 regels over vier bestanden. Het debugging.md-bestand dat was opgeblazen tot 312 regels werd teruggebracht tot 41 -- alleen de actieve, onopgeloste debugging-patronen overleefden.

Dat is een reductie van 77% in geheugenvolume zonder verlies van actuele, relevante informatie. De informatiekwaliteit steeg zelfs, want het verwijderen van ruis verbeterde Claude's vermogen om te vinden en te gebruiken wat er overbleef.

Vijf projecten, veertien dagen: de echte resultaten

Over fasen praten is één ding. Resultaten tonen is iets anders. Hier is wat er daadwerkelijk veranderde per project na het consistent draaien van Autodream gedurende twee weken.

Project 1: Laravel-monoliet (34 sessies)

Dit was het project dat me ertoe dreef om Autodream te testen. De Sanctum-vs-JWT-verwarring was slechts het meest zichtbare symptoom.

Voor dream: Claude twijfelde bij 6 van de 10 architectuurvragen. Suggereerde regelmatig verouderde patronen. Verwees naar packages die we hadden verwijderd. Gemiddelde bruikbare output per prompt: misschien 70% -- de rest had handmatige correctie nodig.

Na eerste dream: Directe verbetering. Claude stopte met twijfelen over auth. Stopte met verwijzen naar Sanctum. De suggesties voor betalingsintegratie waren in lijn met ons huidige adapter-patroon. Maar ik merkte dat het één vermelding had verwijderd die ik eigenlijk wilde behouden -- een notitie over een specifieke PostgreSQL-indexoptimalisatie die nog steeds relevant was. Ik heb die handmatig opnieuw toegevoegd.

Na twee weken (3 dream-cycli): Het geheugen voelde gecureerd aan. Claude's suggesties weerspiegelden consistent de huidige architectuur. Geen tegenspraken meer. De aarzeling daalde naar bijna nul bij onderwerpen die in het geheugen stonden. Bruikbare output per prompt steeg naar ongeveer 90%.

Project 2: Next.js SaaS-dashboard (28 sessies)

Het SaaS-project had een ander geheugenprobleem: geen tegenspraken, maar puur volume. 28 sessies aan feature-ontwikkeling hadden uitgebreide notities opgeleverd over componentpatronen, API-integratiedetails, state management-beslissingen en styling-conventies. De geheugenbestanden waren grondig maar traag te verwerken -- Claude besteedde context window-tokens aan het laden van informatie die het voor de meeste taken niet nodig had.

Voor dream: De responstijd voelde traag aan op dit project vergeleken met anderen. Claude voegde soms irrelevante context toe aan zijn uitleg, zoals verwijzen naar de beslissing over de grafiekbibliotheek wanneer ik vroeg naar formuliervalidatie.

Na eerste dream: Geheugenbestandsgrootte daalde 63%. De dream-subagent had vastgesteld dat 40% van de verzamelde notities ging over opgeloste feature-beslissingen die geen actieve herinnering meer nodig hadden. Het archiveerde de beslissingsgeschiedenis maar behield de huidige staat.

Na twee weken: Antwoorden voelden merkbaar sneller aan. Claude bleef gefocust op de relevante context voor elke taak in plaats van alles te laden. De verbetering was niet dramatisch in outputkwaliteit -- het was dramatisch in output-relevantie.

Project 3: Python CLI-tool (19 sessies)

Minder sessies betekende minder verval. Het CLI-project was mijn controlegroep -- ik wilde zien of Autodream de moeite waard was om te draaien op projecten die de degradatiedrempel nog niet hadden bereikt.

Voor dream: Geheugen was relatief schoon. Kleine redundanties maar geen grote tegenspraken.

Na eerste dream: Bescheiden opschoning. Verwijderde 8 verouderde debugging-notities en consolideerde 3 dubbele vermeldingen over de Click-frameworkconfiguratie. Totale geheugenreductie: 31%.

Conclusie: Op projecten met minder dan 20 sessies is Autodream nuttig maar niet transformatief. De automatische activatiedrempel (24 uur + 5 sessies) is goed gekalibreerd -- het verspilt geen cycli aan projecten die het nog niet nodig hebben.

Project 4: Claude Code Agent Swarm (41 sessies)

Dit was de meest interessante test. Mijn agent swarm-architectuur-project had het meest complexe geheugen omdat het meta-beslissingen bevatte over hoe AI-agents moeten coördineren. De geheugenbestanden bevatten geneste abstracties -- notities over agentgedrag, notities over geheugenbeheer (ironisch, gezien wat ik testte), en notities over inter-agent communicatieprotocollen.

Voor dream: Geheugen was een doolhof. Claude verwarde soms zijn eigen operationele context met de agentontwerp-patronen van het project. Het verwees naar "het geheugensysteem van de agent" en ik kon niet bepalen of het zijn eigen Auto Memory bedoelde of het geheugensysteem dat ik aan het bouwen was voor de swarm.

Na eerste dream: De consolidatiefase handelde dit prachtig af. Het scheidde notities op projectniveau (over de swarm die ik aan het bouwen was) van operationele notities (over Claude's eigen gedrag in dit project). Twee aparte onderwerpbestanden. Geen ambiguïteit meer.

Na twee weken: Dit was waar Autodream mijn volledige vertrouwen verdiende. Het geheugen van het agent swarm-project werd het meest georganiseerd van elk project waar ik aan had gewerkt. Beslissingen gekoppeld aan datums gekoppeld aan onderbouwingen. Huidige architectuur netjes gescheiden van historische alternatieven. Claude ging van "verward over zijn eigen context" naar "de meest deskundige medewerker die ik op dit project heb gehad."

Project 5: Documentatiesite (12 sessies)

De documentatiesite was een lichtgewicht project -- voornamelijk contentgeneratie en Markdown-opmaak. Ik nam het mee om te testen of Autodream een simpel project te agressief zou opschonen.

Voor dream: Schoon, minimaal geheugen. 87 regels totaal.

Na eerste dream: Teruggebracht tot 64 regels. Verouderde contentkalender-verwijzingen verwijderd en stijlgidsonderdelen geconsolideerd.

Conclusie: Autodream handelde het simpele project elegant af. Geen overmatige opschoning. Geen verwijdering van actieve informatie. Het identificeerde correct dat een documentatieproject minder temporele afhankelijkheden heeft dan een codeproject en paste zich dienovereenkomstig aan.

De valkuil die me bijna heeft gekost

Hier is iets dat elke early adopter moet weten, want ik heb het bijna op de harde manier geleerd.

Autodream heeft een uitgesproken mening over wat "verouderd" is. Zijn heuristiek voor veroudering omvat vermeldingen die niet zijn gerefereerd of versterkt in recente sessies. Normaal gesproken is dit precies wat je wilt -- als je een stuk informatie niet nodig hebt gehad in 15 sessies, is het waarschijnlijk niet kritiek.

Maar soms is belangrijke informatie slapend. Op mijn Laravel-project was de notitie over PostgreSQL-indexoptimalisatie die ik eerder noemde relevant, maar was niet recentelijk aan bod gekomen omdat ik de querylaag weken niet had aangeraakt. De dream-subagent schonde het op. Ik ving het tijdens mijn post-dream review en voegde het opnieuw toe.

De oplossing is simpel: maak een back-up van je geheugendirectory voor je eerste dream-cyclus.

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

Controleer daarna het verschil na afloop van de dream. Bekijk wat er is verwijderd. Alles wat niet had mogen worden opgeschoond, voeg je opnieuw toe met een expliciete markering: "KEEP: [reden waarom dit nog steeds relevant is]." Ik heb niet bevestigd of de dream-subagent KEEP-markeringen respecteert, maar in mijn tests hebben vermeldingen met expliciete context over waarom ze belangrijk zijn de neiging om opschoningscycli te overleven.

De tweede valkuil: Autodream verwerkt alleen geheugenbestanden. Het raakt je code, je CLAUDE.md of welke projectbestanden dan ook niet aan. Dit klinkt vanzelfsprekend, maar ik heb verwarring gezien in ontwikkelaarscommunity's waar mensen bang waren dat het hun codebase zou wijzigen. Dat doet het niet. De vergrendeling die het plaatst tijdens het dreamen is uitsluitend op de geheugendirectory.

Wanneer /dream handmatig activeren vs. automatisch laten draaien

Na twee weken testen met beide benaderingen, hier is mijn aanbeveling.

Laat het automatisch draaien voor projecten in een stabiele fase waar je reguliere feature-ontwikkeling doet. De drempel van 24 uur + 5 sessies is goed gekalibreerd voor deze workflow. Je komt de volgende dag terug met iets schoner geheugen zonder erover na te denken.

Activeer het handmatig in drie specifieke situaties:

Na een grote refactor. Als je net je authenticatiesysteem hebt herstructureerd, je databaseschema hebt herbouwd of frameworks hebt gemigreerd, bevatten je geheugenbestanden gegarandeerd verouderde architectuurverwijzingen. Wacht niet 24 uur. Draai /dream onmiddellijk nadat de refactor-sessie is beëindigd.

Wanneer Claude begint te twijfelen. Als Claude begint te antwoorden met "afhankelijk van je setup" of "je zou kunnen overwegen" bij onderwerpen waar het definitieve kennis zou moeten hebben, is dat het geheugenverwarringssignaal. Een handmatige dream-cyclus lost het op.

Voor een kritieke sessie. Als je op het punt staat om een complexe feature aan te pakken die afhankelijk is van Claude's begrip van de huidige staat van je project -- een betalingsintegratie, een beveiligingsaudit, een performance-optimalisatiesprint -- zorgt een pre-sessie dream ervoor dat Claude met schone, actuele informatie werkt.

Ik ben op een patroon uitgekomen: automatisch draaien voor dagelijks werk, handmatig activeren na elke sessie waarin ik significante architectuurwijzigingen heb gemaakt. Dit houdt het geheugen consistent schoon zonder dat ik er de meeste dagen over hoef na te denken.

Als je liever wilt dat iemand dit soort geoptimaliseerde AI-workflows helemaal vanaf nul opbouwt, neem ik Claude Code-automatisering en AI-agent-opdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Het grotere plaatje: Claude Code wordt een stateful assistent

Hier is wat de meeste mensen missen over Autodream, en het is de reden waarom ik twee weken heb besteed aan het testen ervan in plaats van alleen de documentatie te lezen.

Auto Memory gaf Claude Code het vermogen om kennis op te bouwen. Dat was een enorme sprong -- van een stateless tool naar iets dat je project onthoudt. Maar ophoping zonder curatie is gewoon hamsteren. Elk kennissysteem dat alleen maar groeit, stort uiteindelijk in onder zijn eigen gewicht. Je e-mailinbox. Je Notion-workspace. Je browserbladwijzers. Ophoping is het makkelijke deel. Onderhoud is het moeilijke deel.

Autodream is de onderhoudslaag. Het is het verschil tussen notities maken en een functioneel kennisbeheersysteem hebben. En wanneer je beide combineert -- Auto Memory voor vastlegging, Autodream voor curatie -- krijg je iets dat kwalitatief verschilt van elk afzonderlijk.

Claude Code heeft nu vier verschillende geheugenlagen die samenwerken:

1. CLAUDE.md -- de instructies die je handmatig schrijft. De grondwet van je project.
2. Auto Memory -- notities die Claude voor zichzelf schrijft tijdens sessies. Het dagelijkse dagboek.
3. Session Memory -- gespreksvoortgang binnen een enkele sessie. Kortetermijngeheugen.
4. Autodream -- periodieke consolidatie van alles dat is opgebouwd. De nachtelijke schoonmaakploeg.

Dat is geen chattool met een context window-hack. Dat is een geheugenarchitectuur. Handleiding, notulist, kortetermijngeheugen en iets dat opmerkelijk veel op slaap lijkt -- stilletjes samengesteld in drie maanden door Anthropic's Claude Code-team.

Het paper van UC Berkeley en Letta uit april 2025 -- "Sleep-time Compute: Beyond Inference Scaling at Test-time" -- toonde aan dat AI-modellen die berekeningen uitvoeren tijdens inactieve tijd de test-time compute met 2,5x kunnen verminderen bij gelijke nauwkeurigheid. Autodream is de geproductiseerde versie van dat inzicht. Gebruik de dode tijd tussen sessies om de werkkennis van het model te verbeteren, en de actieve sessies worden scherper.

Ik gebruik Claude Code sinds de vroege bèta's. Ik heb geschreven over Claude Code-workflows beheersen, over Claude Skills, over het bouwen van zelfverbeterende AI-systemen. Autodream is de meest significante kwaliteit-van-leven verbetering sinds Auto Memory zelf. Niet omdat het een flitsende nieuwe mogelijkheid toevoegt -- maar omdat het het langzame verval repareert dat elke andere mogelijkheid ondermijnde.

Automemory vs. Autodream: het complete plaatje

Ik zie steeds weer dat mensen deze twee functies door elkaar halen of ze als uitwisselbaar beschouwen. Dat zijn ze niet. Ze zijn complementaire helften van één systeem. Hier is de duidelijkste uiteenzetting die ik kan geven na uitgebreid gebruik van beide:

De sterkste setup draait beide. Automemory zonder Autodream is een notitieboek dat nooit wordt doorgenomen. Autodream zonder Automemory heeft niets om te consolideren. Samen vormen ze een schrijf-beoordeel-versterk cyclus die daadwerkelijk beter wordt in de loop van de tijd in plaats van slechter.

De praktische setup: dit vandaag nog draaiend krijgen

Als je nu meteen met Autodream wilt beginnen, hier is de exacte workflow waar ik na twee weken iteratie op ben uitgekomen.

Stap 1: Controleer je versie. Autodream vereist Claude Code v2.1.59 of later. Draai claude --version in je terminal. Als je achterloopt, update eerst.

Stap 2: Schakel het in. Open een Claude Code-sessie op een project met minstens 10+ sessies aan opgebouwd geheugen. Typ /memory. Zoek naar de Autodream-schakelaar. Als je die ziet, zet hem aan.

Als je de schakelaar niet ziet -- Anthropic rolt dit nog steeds geleidelijk uit per maart 2026 -- kun je een handmatige consolidatie activeren door te typen: "Consolidate my memory files. Review all existing memories, remove contradictions, convert relative dates to absolute dates, merge duplicates, and prune stale entries."

Stap 3: Maak eerst een back-up. Serieus. Draai dat back-upcommando dat ik eerder deelde. De eerste dream-cyclus is de meest agressieve omdat het de meeste opgebouwde veroudering moet opschonen. Je wilt een vangnet.

Stap 4: Beoordeel de resultaten. Nadat de dream is voltooid (8-10 minuten voor de meeste projecten), open je geheugenbestanden en scan ze door. Zoek naar:

• Vermeldingen die zijn verwijderd maar dat niet hadden moeten worden
• Tegenspraak-oplossingen die de verkeerde winnaar kozen
• Datumconversies die incorrect lijken

In mijn tests over vijf projecten was het foutenpercentage laag -- ik ving één incorrecte opschoning op honderden operaties. Maar "laag" is niet "nul," en de kosten van het opnieuw toevoegen van een opgeschoonde vermelding zijn veel lager dan de kosten van het verliezen van belangrijke projectcontext.

Stap 5: Vertrouw de automatische activatie voor dagelijks onderhoud. Zodra je hebt geverifieerd dat de eerste dream-cyclus goede resultaten opleverde, laat de automatische trigger het lopende onderhoud afhandelen. De drempel van 24 uur + 5 sessies houdt alles schoon zonder overmatige verwerking.

Stap 6: Activeer handmatig na grote wijzigingen. Database gerefactord? Van framework gewisseld? Een kernmodule herbouwd? Draai /dream voor je volgende sessie. Wacht niet op de automatische activatie.

Wat dit betekent voor hoe we met AI werken

Een jaar geleden zou het idee dat je AI-codeerassistent zou "slapen" tussen sessies -- zijn herinneringen doornemen, versterken wat belangrijk is, verouderd materiaal opschonen -- als antropomorfische onzin hebben geklonken. Vandaag is het een schakelaar in je terminal.

De naamgeving is geen toeval. Anthropic had dit "geheugenopschoning" of "automatische consolidatie" kunnen noemen. Ze noemden het "dream." De systeemprompt zegt letterlijk: "You are performing a dream -- a reflective pass over your memory files." Die taalkundige keuze signaleert intentie. Ze bouwen niet aan een slimmere autocomplete. Ze bouwen aan iets dat een persistent, evoluerend begrip van je project bijhoudt -- iets dat beter wordt in het helpen hoe langer je samenwerkt, in plaats van langzaam te degraderen onder het gewicht van zijn eigen opgebouwde notities.

Na sessie 34 op mijn Laravel-project -- die waar Claude vol vertrouwen Sanctum-middleware suggereerde die we negentien sessies eerder hadden verwijderd -- twijfelde ik oprecht of langlopende Claude Code-projecten houdbaar waren. Het geheugenverlies voelde als een onvermijdelijkheid. Hoe meer je het gebruikte, hoe ruiziger het geheugen werd, en hoe ruiziger het geheugen werd, hoe minder betrouwbaar de suggesties werden.

Drie dream-cycli later voelde sessie 47 op hetzelfde project als werken met een senior engineer die het weekend had besteed aan het doornemen van de projectdocumentatie. Schone verwijzingen. Nauwkeurige architectuurkennis. Geen geaarzel over beslissingen die we samen hadden genomen.

Dat is geen kleine verbetering. Dat is het verschil tussen een AI-tool waar je tegen vecht en een AI-medewerker die je vertrouwt.

De functie wordt nog steeds uitgerold. Niet iedereen heeft de schakelaar al. Maar als je Claude Code v2.1.59 of later draait en projecten hebt met 20+ sessies aan opgebouwd geheugen, controleer vandaag nog /memory. Als de Autodream-optie er is, schakel het in.

Je AI-agent heeft slaap nodig. En eerlijk? Na te hebben gezien wat er gebeurt als het die krijgt, geldt dat voor elke andere AI-tool in je stack ook.

Veelgestelde vragen

Hoe activeer ik Autodream handmatig in Claude Code?

Typ /memory in je Claude Code-sessie en zoek naar de Autodream-schakelaar. Als alternatief typ je "consolidate my memory using dream" direct in de chat. De consolidatie duurt 8-10 minuten en draait op de achtergrond zonder je actieve sessie te blokkeren. Vereist Claude Code v2.1.59 of later.

Verwijdert Autodream belangrijke herinneringen?

Autodream schoont vermeldingen op die het als verouderd identificeert -- informatie die niet is gerefereerd of versterkt in recente sessies. In zeldzame gevallen kan het slapende-maar-relevante vermeldingen verwijderen. Maak een back-up van je geheugendirectory voor je eerste dream-cyclus en beoordeel de resultaten. Voor een gedetailleerder overzicht van de opschoningslogica, zie het gedeelte over de Vier Fasen hierboven.

Hoe vaak moet ik /dream handmatig draaien?

Laat de automatische activatie het dagelijkse onderhoud afhandelen (het draait elke 24+ uur na 5+ sessies). Activeer handmatig na grote refactors, framework-migraties of wanneer Claude begint te twijfelen bij vragen die het met vertrouwen zou moeten beantwoorden. Ik draai handmatige dreams ongeveer twee keer per week op actieve projecten.

Wat is het verschil tussen Auto Memory en Autodream?

Auto Memory legt notities vast tijdens actieve sessies -- het schrijft vooruit. Autodream consolideert die notities tussen sessies -- het kijkt achteruit, schoont tegenspraken op, converteert relatieve datums en verwijdert verouderde vermeldingen. Beide zijn nodig: Auto Memory zonder Autodream accumuleert ruis, Autodream zonder Auto Memory heeft niets om te consolideren. Zie de vergelijkingstabel hierboven voor het volledige overzicht.

Wijzigt Autodream mijn codebestanden of CLAUDE.md?

Nee. Autodream verwerkt uitsluitend geheugenbestanden in de geheugendirectory van je project. Het raakt broncode, configuratiebestanden of je CLAUDE.md niet aan. De bestandsvergrendeling die het plaatst tijdens consolidatie betreft alleen geheugenbestanden, en je kunt normaal doorcoderen terwijl een dream-cyclus draait.

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