Auto Dream

Anthropic a intégré une fonctionnalité dans Claude Code sans aucune annonce publique. Elle s'appelle Auto Dream, et elle s'attaque à la faiblesse fondamentale de l'auto memory : les notes pourrissent quand elles s'accumulent.

Problème : L'auto memory était une vraie avancée. Claude a commencé à tenir ses propres notes de projet. Après 20 sessions ou plus, le carnet devient moche. Les entrées commencent à se contredire. Les dates relatives comme "hier" ne veulent plus rien dire. Les anciens conseils de débogage pointent encore vers des fichiers supprimés lors d'un refactor. Ce qui devrait être une mémoire utile se transforme en bruit de fond qui perturbe Claude.

Victoire rapide : Vérifie si Auto Dream est actif sur ton installation. Ouvre n'importe quelle session Claude Code et lance /memory. Cherche "Auto-dream: on" dans le sélecteur. Si le flag est là, Claude nettoie déjà tes fichiers mémoire entre les sessions en arrière-plan.

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

Tu vois le toggle et il est activé ? Parfait. De temps en temps, Claude parcourt les fichiers mémoire du projet, jette ce qui est périmé, corrige les contradictions, et réorganise le reste. Pas encore de toggle ? Lis la suite. Un déclencheur manuel fonctionne quand même.

Pourquoi appeler ça "dreaming" ? L'analogie du sommeil REM

Le nom n'a pas été choisi par hasard. L'analogie tient vraiment.

Ton cerveau absorbe des inputs toute la journée et les stocke en mémoire à court terme. Le sommeil REM passe ensuite en revue les événements de la journée, conserve les connexions importantes, abandonne ce qui ne l'est pas, et range le reste dans la mémoire à long terme. Prive-toi de REM et tu auras du mal à former des souvenirs durables. Les informations arrivent mais ne sont jamais consolidées.

L'auto memory joue le rôle du cerveau éveillé de Claude. Il prend des notes pendant son travail : patterns de débogage, commandes de build, décisions d'architecture, tes habitudes. Chaque session empile de nouvelles entrées. Sans passe de nettoyage, ces notes deviennent aussi désordonnées qu'une mémoire à court terme non consolidée. Les vieilles contradictions traînent. Les entrées obsolètes ne partent jamais. Le signal se noie dans le bruit à chaque session.

Auto Dream joue le rôle du REM. Il examine ce que l'auto memory a collecté, garde les parties qui valent encore la peine, efface tout ce qui a dépassé sa date d'expiration, et réorganise le reste en fichiers thématiques propres avec un index clair. Sans lui, Claude Code tournait essentiellement sans sommeil. Les notes continuaient de s'empiler. Le nettoyage n'arrivait jamais.

Les quatre phases d'un cycle de rêve

Auto Dream suit une routine en quatre phases à chaque exécution. Chaque phase a son propre rôle, et ensemble elles transforment un tas épars de notes de session en connaissance de projet organisée.

Phase 1 : Orientation

Claude ouvre le répertoire mémoire et inventorie ce qui est déjà là. Il lit MEMORY.md (l'index), regarde la liste des fichiers thématiques, et esquisse l'état actuel des choses.

La question à laquelle cette phase répond : "Qu'est-ce que je sais déjà, et comment c'est classé ?"

Phase 2 : Collecter le signal

Ensuite, Auto Dream fouille dans tes transcripts de session (ces fichiers JSONL que Claude garde localement pour chaque session). Les lire en entier de bout en bout est hors de question. Sur un projet avec des centaines de sessions, ce serait absurde en termes de tokens et de temps. La passe est ciblée. Elle cherche uniquement des patterns spécifiques :

• Corrections de l'utilisateur : Les moments où tu as dit à Claude qu'il avait tort ou l'as orienté dans une nouvelle direction
• Sauvegardes explicites : Quand tu as dit "souviens-toi de ça" ou "sauvegarde en mémoire"
• Thèmes récurrents : Des patterns qui sont apparus dans beaucoup de sessions
• Décisions importantes : Choix d'architecture, d'outils, changements de workflow

Cette passe étroite est délibérée. Lire 500 transcripts en entier brûlerait des tokens pour presque rien de nouveau. Des requêtes de type grep ciblées extraient les bits à fort signal sans le gaspillage.

Phase 3 : Consolidation

C'est l'événement principal. Claude intègre les nouvelles informations dans les fichiers thématiques existants et gère la maintenance critique :

• Les dates relatives sont réécrites en dates absolues. "Hier on a décidé d'utiliser Redis" devient "Le 2026-03-15 on a décidé d'utiliser Redis." Ça évite que le timing se brouille avec l'âge des souvenirs.
• Les faits contredits sont supprimés. Tu as changé d'Express pour Fastify il y a trois semaines ? L'ancienne entrée "L'API utilise Express" disparaît.
• Les souvenirs obsolètes sont supprimés. Des notes de débogage pointant vers un fichier effacé lors d'un refactor ne servent à rien. Dehors.
• Les entrées qui se chevauchent sont fusionnées. Trois sessions qui signalent toutes la même bizarrerie de commande de build se condensent en une seule note propre.

Phase 4 : Élagage et indexation

La dernière phase se concentre sur MEMORY.md. Ce fichier est maintenu sous 200 lignes car 200 est le seuil de ce qui se charge au démarrage. La phase 4 met à jour MEMORY.md pour qu'il reflète l'état actuel des fichiers thématiques :

• Supprime les liens vers les fichiers thématiques qui n'existent plus
• Ajoute des pointeurs vers les nouveaux fichiers thématiques créés pendant la consolidation
• Corrige tout écart entre l'index et ce que les fichiers disent vraiment
• Réordonne les entrées par pertinence et fraîcheur

Les fichiers thématiques qui n'ont pas eu besoin de modifications lors de la consolidation sont laissés tranquilles. Auto Dream ne réécrit pas tout à chaque exécution. Les changements sont chirurgicaux.

Le prompt système complet

Voici le prompt système réel qui propulse Auto Dream. C'est ce que Claude reçoit quand un cycle de rêve démarre :

# 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.

Quelques détails de ce prompt méritent d'être soulignés. Il dit à Claude clairement de faire des grep ciblés et d'éviter les lectures complètes de transcript. Il maintient MEMORY.md sous la limite des 200 lignes. Et il dit à Claude de corriger les contradictions dans le fichier source plutôt que de simplement les signaler. Le prompt a des opinions fortes sur l'apparence que doit avoir la mémoire, ce qui explique pourquoi le résultat est toujours propre.

Quand un cycle de rêve se déclenche

Deux conditions doivent être vraies simultanément pour que la consolidation se lance :

1. Au moins 24 heures se sont écoulées depuis la consolidation précédente
2. Plus de 5 sessions ont eu lieu depuis la consolidation précédente

Les deux conditions sont requises. Une session marathon sur deux jours ne déclenchera pas Auto Dream (le nombre de sessions est trop bas). Dix sessions rapides en deux heures ne le déclencheront pas non plus (pas assez de temps écoulé). Ce double verrou empêche les projets tranquilles de déclencher des nettoyages inutiles et s'assure que les actifs restent bien rangés.

Pour donner une idée de l'échelle : lors d'une exécution observée, Auto Dream a traité 913 sessions de mémoire en environ 8 à 9 minutes. Pas gratuit, mais le travail se fait en arrière-plan donc tu ne ressens jamais le coût.

Les garanties de sécurité

Auto Dream tourne avec de vraies protections. Les accidents sont difficiles à provoquer.

Le code du projet reste en lecture seule. Pendant un cycle de rêve, Claude ne peut écrire que dans les fichiers mémoire. Le code source, la configuration, les tests, et le reste de tes fichiers de projet sont hors limites. Le processus de rêve est confiné dans le répertoire mémoire.

Un fichier verrou bloque les chevauchements. Tu as deux instances de Claude Code ouvertes sur le même projet ? Une seule peut exécuter Auto Dream à la fois. Un fichier verrou empêche deux exécutions de consolidation de se battre l'une contre l'autre, ce qui causerait des conflits de fusion dans les fichiers mémoire.

Tourne en arrière-plan. Auto Dream ne bloque pas ta session et ne te fait pas attendre. Tu continues à travailler dans Claude Code pendant qu'il tourne. La consolidation se passe dans son propre processus.

Déclencher un rêve manuellement

Attendre le déclencheur automatique est facultatif. Si tu sais que la mémoire a besoin d'un nettoyage (disons, juste après un grand refactor), tu peux forcer une consolidation toi-même.

La commande /dream existe mais n'a pas encore atteint tous les comptes. En attendant, dis simplement à Claude ce que tu veux :

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

Claude comprend l'intention et suit le même flux en quatre phases. Utile après de grands changements dans le projet, quand une mémoire fraîche compte et qu'attendre le prochain cycle automatique est trop lent.

Avant et après : une vraie consolidation

Voici à quoi peut ressembler un répertoire mémoire de part et d'autre d'un cycle de rêve.

Avant (désordonné, 30+ sessions accumulées)

~/.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

Après (consolidé)

~/.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

Le fichier random-notes.md a disparu. Son contenu a été soit intégré dans des fichiers thématiques pertinents, soit supprimé pour obsolescence. MEMORY.md est passé de 280 lignes à 142, sous le seuil de démarrage des 200 lignes. Les contradictions sont résolues. Les dates sont absolues.

Auto Memory vs Auto Dream : deux couches d'un même système

Ces deux fonctionnalités travaillent ensemble, pas l'une contre l'autre. Pense-y comme la couche de collecte et la couche de maintenance d'un seul système mémoire.

L'auto memory sans rien pour nettoyer après, c'est comme un preneur de notes qui ne feuillette jamais son carnet. L'inverse est vrai aussi : sans rien qui écrit de nouvelles notes, un cycle de rêve n'a rien sur quoi travailler. Tu veux les deux en même temps.

Quatre systèmes mémoire : le tableau complet

Avec cette nouvelle couche, Claude Code a quatre mécanismes mémoire distincts. Voici comment l'ensemble s'assemble, en développant le tableau du deep-dive sur l'auto memory :

La configuration la plus solide utilise les quatre. CLAUDE.md porte les règles que tu possèdes et contrôles. L'auto memory capture ce que Claude apprend sur le tas. La session memory porte les fils de conversation entre les redémarrages. Et le cycle de rêve maintient cette connaissance accumulée à jour, précise et organisée.

Conseils pratiques

Laisse l'automatisation gérer la plupart des projets. Les gates par défaut (24h plus 5 sessions) conviennent bien au développement actif. Pas besoin de surveillance.

Force un rêve juste après un grand refactor. Tu as renommé la moitié de ta codebase ? Changé de framework ? Remanié ton API ? Déclenche un cycle manuel. Les vieilles entrées seront plus sources de confusion qu'utiles jusqu'à ce qu'elles soient réconciliées.

Jette un coup d'œil aux résultats de temps en temps. Après un cycle de rêve, parcours MEMORY.md. Auto Dream est bien, mais pas infaillible. Un choix de consolidation pourrait te déranger. Les fichiers sont en markdown brut. Édite-les comme tu veux.

Combine-le avec une bonne hygiène du contexte. Un cycle de rêve garde tes fichiers mémoire propres, mais le contexte de session actif reste à toi à gérer. Des fichiers plus propres signifient que Claude charge moins de déchets au démarrage, ce qui te laisse plus de place pour le vrai travail dans la fenêtre de contexte.

Prochaines étapes

• Mets CLAUDE.md en place d'abord si ce n'est pas déjà fait. Un cycle de rêve consolide l'auto memory, mais CLAUDE.md reste la source de vérité la plus prioritaire.
• Renseigne-toi sur l'auto memory pour voir exactement ce que Claude capture pendant les sessions, qui est la matière première sur laquelle Auto Dream travaille.
• Regarde la session memory pour la continuité au niveau de la conversation entre les sessions de travail.
• Consulte le guide sur le context engineering pour voir comment tous ces systèmes mémoire s'additionnent en une stratégie de contexte délibérée.
• Surveille le changelog de Claude Code pour les mises à jour du système mémoire, notamment quand Auto Dream sera disponible sur ton niveau d'abonnement.
• Nouveau sur Claude Code ? Suis le guide d'installation pour te configurer sur macOS, Windows, ou Linux avant de toucher à la configuration mémoire.

Auto Dream est la pièce qui transforme la mémoire de Claude d'une pile croissante de notes en une base de connaissances vivante et maintenue. L'auto memory rassemble la matière première. Auto Dream la façonne en quelque chose que Claude peut vraiment utiliser. L'effet net est un Claude qui non seulement se souvient de plus avec le temps, mais qui se souvient mieux.