J'ai testé /dream de Claude Code pendant deux semaines d'affilée

J'ai testé /dream de Claude Code pendant deux semaines d'affilée

La session 34 de mon projet Laravel m'a brisé.

J'avais demandé à Claude de mettre en place un nouveau webhook handler pour Stripe. Tâche simple -- je l'avais déjà fait sur ce même projet, et Claude m'avait aidé à construire l'intégration de paiement originale vers la session 8. La réponse est revenue confiante. Code propre. Gestion des erreurs correcte. Un problème : il avait construit le handler en utilisant un middleware Sanctum que nous avions supprimé à la session 15.

J'ai fixé le terminal pendant une bonne dizaine de secondes. Puis j'ai vérifié les fichiers de mémoire. Les deux entrées étaient là -- "Auth utilise Sanctum" de la session 8 et "Auth migré vers JWT personnalisé" de la session 15 -- comme deux versions de l'histoire coexistant paisiblement. Claude avait choisi la mauvaise. Impossible de savoir laquelle était actuelle car les horodatages disaient des choses comme "récemment" et "lors d'une session précédente."

C'est à ce moment-là que j'ai arrêté de considérer Autodream comme une fonctionnalité intéressante que je testerais un jour et que j'ai commencé à la traiter comme quelque chose dont mon workflow avait désespérément besoin.

Deux semaines plus tard, après avoir exécuté /dream sur cinq projets actifs -- un monolithe Laravel, un tableau de bord SaaS Next.js, un outil CLI Python, un Claude Code agent swarm et un site de documentation -- je peux vous dire exactement ce qu'Autodream fait bien, où il m'a surpris, et l'angle mort qui a failli me coûter deux heures de retravail.

Le problème de dégradation de la mémoire est pire que vous ne le pensez

Si vous utilisez Claude Code depuis moins de 15 sessions sur un seul projet, vous n'avez probablement pas encore heurté ce mur. Profitez de la lune de miel. Pour tous les autres -- les développeurs qui exécutent 20, 30, 50+ sessions sur des bases de code complexes -- la dégradation de la mémoire n'est pas une préoccupation théorique. C'est ce qui dégrade silencieusement le jugement de votre programmeur IA.

J'ai écrit sur construire un second cerveau avec Claude Code il y a quelque temps, et Auto Memory a été une véritable percée pour ce workflow. Au lieu de mettre à jour CLAUDE.md manuellement après chaque session, Claude a commencé à sauvegarder ses propres notes : commandes de build, patterns de debugging, décisions d'architecture, préférences de framework. Session après session, la base de connaissances a grandi.

La partie que je n'avais pas anticipée ? La croissance sans maintenance, c'est juste de l'accumulation.

Après 20+ sessions sur mon projet Laravel, les fichiers de mémoire de Claude contenaient 847 lignes réparties sur six fichiers thématiques. Certaines de ces lignes se contredisaient directement. D'autres référençaient des workarounds de debugging pour des bugs que j'avais corrigés des semaines auparavant. Des horodatages relatifs comme "hier nous avons décidé de changer la couche de cache" n'avaient aucun sens -- quel hier ? Celui de la session 12 ou de la session 27 ?

Les symptômes sont subtils au début. Claude hésite davantage. Au lieu de "utilise l'adaptateur de cache Redis que nous avons mis en place," il dit "tu voudrais peut-être utiliser Redis ou Memcached selon ta configuration." Cette hésitation est un signal. Cela signifie que Claude a trouvé des informations contradictoires dans ses propres notes et a choisi de jouer la sécurité plutôt que de s'engager sur une réponse qui pourrait être fausse.

Puis les symptômes deviennent moins subtils. Des patterns de code obsolètes. Des références à des dépendances que vous avez supprimées. Des suggestions qui contredisent activement votre architecture actuelle. À ce stade, vous passez plus de temps à corriger Claude que Claude ne vous en fait gagner.

C'est le problème qu'Autodream a été construit pour résoudre. Et après deux semaines de tests, je peux confirmer : ça fonctionne. Mais le comment compte plus que le quoi.

Ce qui se passe réellement quand vous tapez /dream

Voici ce que personne n'explique bien à propos d'Autodream : il y a deux façons distinctes de le déclencher, et elles produisent des résultats légèrement différents.

La voie manuelle : Ouvrez une session Claude Code, tapez /memory et cherchez le toggle Autodream. S'il est là, vous pouvez l'activer. Vous pouvez aussi taper "consolidate my memory using dream" directement dans le chat, et Claude lancera le sous-agent de consolidation sur-le-champ.

La voie automatique : Une fois qu'Autodream est activé, il se déclenche automatiquement quand deux conditions sont simultanément remplies -- plus de 24 heures depuis la dernière consolidation ET vous avez eu 5 sessions ou plus depuis. Les deux portes doivent s'ouvrir. Dix sessions rapides en deux heures ne le déclencheront pas. Une session marathon s'étalant sur deux jours non plus. Ce design à double porte empêche le traitement inutile sur les projets peu utilisés tout en assurant que les projets actifs reçoivent un nettoyage régulier.

Quand j'ai déclenché mon premier dream manuel sur le projet Laravel, un indicateur de statut est apparu : "dreaming." Claude a verrouillé les fichiers de mémoire pour éviter les conflits d'écriture (vous pouvez continuer à coder -- il ne verrouille que la mémoire, pas vos fichiers de projet) et a démarré ce qu'Anthropic appelle en interne le cycle de consolidation en quatre phases.

J'ai chronométré. Huit minutes et quarante-trois secondes pour un projet avec 34 sessions de mémoire accumulée.

Voici ce qui s'est passé pendant ces huit minutes, phase par phase.

Les quatre phases : ce que j'ai réellement observé

J'ai vu pas mal d'articles décrire les quatre phases de manière abstraite. Je vais vous raconter à quoi elles ressemblent en pratique, car les abstractions passent à côté des détails importants.

Phase 1 : Orientation

Le sous-agent dream de Claude scanne chaque fichier de mémoire dans le répertoire de votre projet et construit ce que j'appellerais une carte de connaissances -- une compréhension structurelle de quelles informations existent et où elles se trouvent. Sur mon projet Laravel, cela signifiait lire MEMORY.md (l'index principal), plus cinq fichiers thématiques qu'Auto Memory avait créés sur 34 sessions : architecture.md, debugging.md, decisions.md, preferences.md et api-patterns.md.

La phase d'orientation a pris environ 90 secondes. Je pouvais voir le sous-agent lister chaque fichier en notant sa taille et sa date de dernière modification. C'est de la pure reconnaissance -- pas encore de modifications.

Ce que j'ai trouvé intéressant : le sous-agent a aussi noté quels fichiers étaient disproportionnellement gros. Mon debugging.md avait gonflé à 312 lignes -- principalement des workarounds obsolètes pour des problèmes que j'avais résolus des semaines auparavant. L'orientation a marqué cela comme cible prioritaire pour l'élagage.

Phase 2 : Collecte de signaux

C'est ici que le sous-agent dream devient chirurgical. Il fouille dans vos transcriptions de session -- les fichiers JSONL qui enregistrent chaque interaction Claude Code -- à la recherche de signaux à haute valeur spécifiques. Il ne lit pas tout. Il cherche des patterns.

Qu'est-ce qui compte comme signal à haute valeur ? J'ai suivi quatre catégories sur mes cinq projets :

Corrections de l'utilisateur. Chaque fois que j'ai dit "non, c'est faux" ou "on n'utilise plus ça" ou "l'approche actuelle est en fait X." Ces corrections valent de l'or. Elles représentent des moments explicites où les connaissances existantes de Claude étaient fausses, et l'humain a donné la bonne réponse.

Décisions d'architecture. Les moments où je me suis engagé dans une direction technique spécifique : "On part sur Fastify au lieu d'Express," "Utilise Redis Cluster, pas standalone," "L'abstraction de paiement utilisera le pattern adaptateur."

Patterns répétés. Si trois sessions différentes référençaient la même particularité de commande de build ou la même étape de déploiement, c'est un signal qui mérite d'être préservé et consolidé en une seule entrée propre.

Sauvegardes explicites. Chaque fois que j'ai dit "retiens ça" ou "sauvegarde ça en mémoire" ou que Claude a décidé proactivement de sauvegarder quelque chose d'important.

Sur mon projet Next.js, la phase de collecte a trouvé 23 corrections utilisateur sur 28 sessions. Vingt-trois fois j'avais dit à Claude que quelque chose qu'il croyait était faux. Certaines de ces corrections se contredisaient entre elles parce que ma propre réflexion avait évolué -- j'avais corrigé Claude à la session 10, puis corrigé la correction à la session 19. La phase de collecte a capturé la chaîne complète pour que la phase de consolidation puisse la résoudre vers la vérité la plus récente.

Phase 3 : Consolidation

C'est la phase qui vaut son pesant d'or. Le sous-agent dream prend tout des phases 1 et 2 et effectue quatre opérations spécifiques :

Conversion de dates. Chaque horodatage relatif est converti en date absolue. "Hier on a décidé d'utiliser Redis" d'une session du 12 mars devient "Le 2026-03-12, décidé d'utiliser Redis Cluster pour le scaling horizontal." Cette seule opération élimine la confusion temporelle qui cause la plupart des hallucinations liées à la mémoire.

Résolution de contradictions. Quand deux entrées sont en conflit, le sous-agent utilise les horodatages de session et les corrections associées pour déterminer laquelle est actuelle. Sur mon projet Laravel, il a correctement identifié que "Auth utilise Sanctum" (session 8) avait été remplacé par "Migré vers JWT personnalisé" (session 15). L'entrée Sanctum a été supprimée. Pas archivée. Supprimée. Car les références architecturales obsolètes dans les fichiers de mémoire sont activement nuisibles -- elles sont pires que de n'avoir aucune entrée du tout.

Fusion de doublons. Trois sessions avaient noté que la commande de build nécessite --legacy-peer-deps. Elles ont été fusionnées en une seule entrée propre avec la date de première observation.

Chaînage de décisions. Celui-ci m'a surpris. Le sous-agent a connecté des décisions liées en chaînes narratives. Sur mon projet CLI Python, il a lié "Choisi Click plutôt qu'argparse (5 mars)" avec "Ajouté Click group pour les sous-commandes (9 mars)" avec "Refactorisé les commandes Click en décorateurs (14 mars)" en un seul récit architectural. Cette chaîne donne aux futures sessions de Claude un contexte authentique sur l'évolution de la structure du CLI -- pas seulement ce qu'elle est maintenant, mais pourquoi elle est ce qu'elle est.

Phase 4 : Élagage et indexation

La phase finale est le nettoyage. Le sous-agent raccourcit l'index principal MEMORY.md pour rester sous 200 lignes -- c'est le seuil de ce qui est chargé au démarrage, donc tout ce qui dépasse 200 lignes est effectivement invisible pour les nouvelles sessions. Les notes de debugging obsolètes sont supprimées. Les problèmes résolus sont archivés. Le résultat est un système de mémoire qui est léger, actuel et internement cohérent.

La mémoire de mon projet Laravel est passée de 847 lignes sur six fichiers à 193 lignes sur quatre fichiers. Le fichier debugging.md qui avait gonflé à 312 lignes a été réduit à 41 -- seuls les patterns de debugging actifs et non résolus ont survécu.

C'est une réduction de 77% du volume de mémoire sans perte d'information actuelle et pertinente. En fait, la qualité de l'information a augmenté car la suppression du bruit a amélioré la capacité de Claude à trouver et utiliser ce qui restait.

Cinq projets, quatorze jours : les vrais résultats

Parler de phases c'est une chose. Montrer des résultats en est une autre. Voici ce qui a réellement changé sur chaque projet après avoir exécuté Autodream de manière consistante pendant deux semaines.

Projet 1 : Monolithe Laravel (34 sessions)

C'est le projet qui m'a poussé à tester Autodream. La confusion Sanctum-vs-JWT n'était que le symptôme le plus évident.

Avant dream : Claude hésitait sur 6 questions d'architecture sur 10. Suggérait régulièrement des patterns obsolètes. Référençait des packages qu'on avait supprimés. Output utile moyen par prompt : peut-être 70% -- le reste nécessitait une correction manuelle.

Après le premier dream : Amélioration immédiate. Claude a arrêté d'hésiter sur l'auth. A arrêté de référencer Sanctum. Les suggestions d'intégration de paiement s'alignaient avec notre pattern adaptateur actuel. Mais j'ai remarqué qu'une entrée avait été supprimée que je voulais garder -- une note sur une optimisation d'index PostgreSQL spécifique qui était encore pertinente. Je l'ai rajoutée manuellement.

Après deux semaines (3 cycles de dream) : La mémoire semblait curatée. Les suggestions de Claude reflétaient systématiquement l'architecture actuelle. Plus de contradictions. L'hésitation est tombée à quasi zéro sur les sujets couverts en mémoire. L'output utile par prompt est monté à environ 90%.

Projet 2 : Tableau de bord SaaS Next.js (28 sessions)

Le projet SaaS avait un problème de mémoire différent : pas des contradictions, mais du volume pur. 28 sessions de développement de fonctionnalités avaient produit des notes exhaustives sur les patterns de composants, les détails d'intégration API, les décisions de gestion d'état et les conventions de style. Les fichiers de mémoire étaient complets mais lents à parser -- Claude dépensait des tokens de context window à charger des informations dont il n'avait pas besoin pour la plupart des tâches.

Avant dream : La latence de réponse semblait lente sur ce projet comparé aux autres. Claude incluait parfois du contexte non pertinent dans ses explications, comme référencer la décision de bibliothèque de graphiques quand je posais une question sur la validation de formulaires.

Après le premier dream : La taille des fichiers de mémoire a baissé de 63%. Le sous-agent dream avait identifié que 40% des notes accumulées portaient sur des décisions de fonctionnalités résolues qui ne nécessitaient plus de rappel actif. Il a archivé l'historique des décisions mais gardé l'état actuel.

Après deux semaines : Les réponses semblaient sensiblement plus rapides. Claude restait concentré sur le contexte pertinent pour chaque tâche au lieu de tout charger. L'amélioration n'était pas dramatique en qualité d'output -- elle était dramatique en pertinence d'output.

Projet 3 : Outil CLI Python (19 sessions)

Moins de sessions signifiait moins de dégradation. Le projet CLI était mon groupe témoin -- je voulais voir si Autodream valait la peine d'être exécuté sur des projets qui n'avaient pas atteint le seuil de dégradation.

Avant dream : Mémoire relativement propre. Des redondances mineures mais pas de contradictions majeures.

Après le premier dream : Nettoyage modeste. Supprimé 8 notes de debugging obsolètes et consolidé 3 entrées en double sur la configuration du framework Click. Réduction totale de mémoire : 31%.

Verdict : Sur les projets de moins de 20 sessions, Autodream est utile mais pas transformateur. Le seuil de déclenchement automatique (24 heures + 5 sessions) est bien calibré -- il ne gaspille pas de cycles sur des projets qui n'en ont pas encore besoin.

Projet 4 : Claude Code Agent Swarm (41 sessions)

C'était le test le plus intéressant. Mon projet d'architecture agent swarm avait la mémoire la plus complexe car il impliquait des décisions de méta-niveau sur la coordination des agents IA. Les fichiers de mémoire contenaient des abstractions imbriquées -- des notes sur le comportement des agents, des notes sur la gestion de la mémoire (ironique, vu ce que je testais), et des notes sur les protocoles de communication inter-agents.

Avant dream : La mémoire était un labyrinthe. Claude confondait parfois son propre contexte opérationnel avec les patterns de design d'agents du projet. Il référençait "le système de mémoire de l'agent" et je ne pouvais pas déterminer s'il parlait de son propre Auto Memory ou du système de mémoire que je construisais pour le swarm.

Après le premier dream : La phase de consolidation a géré cela magnifiquement. Elle a séparé les notes de niveau projet (sur le swarm que je construisais) des notes opérationnelles (sur le propre comportement de Claude dans ce projet). Deux fichiers thématiques distincts. Plus d'ambiguïté.

Après deux semaines : C'est ici qu'Autodream a gagné ma confiance totale. La mémoire du projet agent swarm est devenue la mieux organisée de tous les projets sur lesquels j'avais travaillé. Des décisions liées à des dates liées à des justifications. L'architecture actuelle proprement séparée des alternatives historiques. Claude est passé de "confus sur son propre contexte" à "le collaborateur le plus compétent que j'aie eu sur ce projet."

Projet 5 : Site de documentation (12 sessions)

Le site de documentation était un projet léger -- principalement de la génération de contenu et du formatage Markdown. Je l'ai inclus pour tester si Autodream élaguerait excessivement la mémoire d'un projet simple.

Avant dream : Mémoire propre et minimale. 87 lignes au total.

Après le premier dream : Réduit à 64 lignes. Supprimé des références obsolètes du calendrier éditorial et consolidé les entrées du guide de style.

Verdict : Autodream a géré le projet simple avec élégance. Pas d'élagage excessif. Pas de suppression d'information active. Il a correctement identifié qu'un projet de documentation a moins de dépendances temporelles qu'un projet de code et s'est ajusté en conséquence.

Le piège qui a failli me coûter cher

Voici ce que je veux que chaque early adopter sache, car j'ai failli l'apprendre à mes dépens.

Autodream a des opinions tranchées sur ce qui est "obsolète." Son heuristique de péremption inclut les entrées qui n'ont pas été référencées ou renforcées lors de sessions récentes. Normalement, c'est exactement ce que vous voulez -- si vous n'avez pas eu besoin d'une information en 15 sessions, elle n'est probablement pas critique.

Mais parfois une information importante est dormante. Sur mon projet Laravel, la note d'optimisation d'index PostgreSQL que j'ai mentionnée plus tôt était pertinente mais n'avait pas été évoquée récemment parce que je n'avais pas touché à la couche de requêtes depuis des semaines. Le sous-agent dream l'a élaguée. Je l'ai repérée lors de ma revue post-dream et je l'ai rajoutée.

La solution est simple : sauvegardez votre répertoire de mémoire avant votre premier cycle de dream.

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

Puis examinez le diff après la fin du dream. Vérifiez ce qui a été supprimé. Tout ce qui n'aurait pas dû être élagué, rajoutez-le avec un marqueur explicite : "KEEP: [raison pour laquelle c'est encore pertinent]." Je n'ai pas confirmé si le sous-agent dream respecte les marqueurs KEEP, mais dans mes tests, les entrées avec un contexte explicite sur leur importance tendent à survivre aux cycles d'élagage.

Le second piège : Autodream ne traite que les fichiers de mémoire. Il ne touche ni votre code, ni votre CLAUDE.md, ni aucun fichier de projet. Ça semble évident, mais j'ai vu de la confusion dans les communautés de développeurs où les gens craignaient qu'il puisse modifier leur codebase. Ce n'est pas le cas. Le verrou qu'il place pendant le dreaming est exclusivement sur le répertoire de mémoire.

Quand déclencher /dream manuellement vs. le laisser s'exécuter automatiquement

Après deux semaines de tests avec les deux approches, voici ma recommandation.

Laissez-le s'exécuter automatiquement pour les projets en régime stable où vous faites du développement de fonctionnalités régulier. Le seuil de 24 heures + 5 sessions est bien calibré pour ce workflow. Vous revenez le lendemain avec une mémoire légèrement plus propre sans y penser.

Déclenchez-le manuellement dans trois situations spécifiques :

Après un refactoring majeur. Si vous venez de restructurer votre système d'authentification, reconstruire votre schéma de base de données ou migrer de framework, vos fichiers de mémoire contiennent à coup sûr des références architecturales obsolètes. N'attendez pas 24 heures. Lancez /dream immédiatement après la fin de la session de refactoring.

Quand Claude commence à hésiter. Si Claude commence à répondre avec "selon votre configuration" ou "vous pourriez envisager" sur des sujets où il devrait avoir des connaissances définitives, c'est le signal de confusion de mémoire. Un cycle de dream manuel règle le problème.

Avant une session critique. Si vous êtes sur le point d'aborder une fonctionnalité complexe qui dépend de la compréhension par Claude de l'état actuel de votre projet -- une intégration de paiement, un audit de sécurité, un sprint d'optimisation des performances -- un dream pré-session garantit que Claude travaille avec des informations propres et à jour.

J'ai trouvé mon rythme : exécution automatique pour le travail quotidien, déclenchement manuel après toute session où j'ai fait des changements architecturaux significatifs. Cela garde la mémoire consistamment propre sans que j'aie à y penser la plupart des jours.

Si vous préférez que quelqu'un construise ce type de workflows IA optimisés de zéro, j'accepte des missions d'automatisation Claude Code et d'agents IA. Vous pouvez voir ce que j'ai construit sur fiverr.com/s/EgxYmWD.

La vision d'ensemble : Claude Code devient un assistant à état persistant

Voici ce que la plupart des gens ne voient pas à propos d'Autodream, et c'est la raison pour laquelle j'ai passé deux semaines à le tester au lieu de juste lire la documentation.

Auto Memory a donné à Claude Code la capacité d'accumuler des connaissances. C'était un bond énorme -- d'outil sans état à quelque chose qui se souvient de votre projet. Mais l'accumulation sans curation, c'est juste de l'accumulation. Tout système de connaissances qui ne fait que croître finit par s'effondrer sous son propre poids. Votre boîte mail. Votre workspace Notion. Vos favoris de navigateur. Accumuler est la partie facile. Maintenir est la partie difficile.

Autodream est la couche de maintenance. C'est la différence entre prendre des notes et avoir un système fonctionnel de gestion des connaissances. Et quand vous combinez les deux -- Auto Memory pour la capture, Autodream pour la curation -- vous obtenez quelque chose de qualitativement différent de chacun pris séparément.

Claude Code a maintenant quatre couches de mémoire distinctes qui travaillent ensemble :

1. CLAUDE.md -- les instructions que vous écrivez manuellement. La constitution de votre projet.
2. Auto Memory -- les notes que Claude écrit pour lui-même pendant les sessions. Le journal quotidien.
3. Session Memory -- la continuité de conversation au sein d'une seule session. La mémoire à court terme.
4. Autodream -- la consolidation périodique de tout ce qui s'est accumulé. L'équipe de nettoyage nocturne.

Ce n'est pas un outil de chat avec un hack de context window. C'est une architecture de mémoire. Manuel d'instructions, preneur de notes, mémoire à court terme, et quelque chose qui ressemble remarquablement au sommeil -- assemblé discrètement en trois mois par l'équipe Claude Code d'Anthropic.

L'article de UC Berkeley et Letta d'avril 2025 -- "Sleep-time Compute: Beyond Inference Scaling at Test-time" -- a montré que les modèles d'IA effectuant des calculs pendant le temps d'inactivité peuvent réduire le compute en temps de test de 2,5x à précision égale. Autodream est la version productisée de cette idée. Utilisez le temps mort entre les sessions pour améliorer les connaissances de travail du modèle, et les sessions actives deviennent plus affûtées.

J'utilise Claude Code depuis les premières bêtas. J'ai écrit sur maîtriser les workflows Claude Code, sur Claude Skills, sur la construction de systèmes IA auto-améliorants. Autodream est l'amélioration de qualité de vie la plus significative depuis Auto Memory lui-même. Non pas parce qu'il ajoute une capacité spectaculaire -- mais parce qu'il corrige la dégradation lente qui sapait toutes les autres capacités.

Automemory vs. Autodream : le tableau complet

Je vois constamment des gens confondre ces deux fonctionnalités ou les traiter comme interchangeables. Elles ne le sont pas. Ce sont des moitiés complémentaires d'un seul système. Voici la ventilation la plus claire que je puisse donner après avoir utilisé les deux extensivement :

La configuration la plus puissante fait tourner les deux. Automemory sans Autodream est un carnet qui n'est jamais relu. Autodream sans Automemory n'a rien à consolider. Ensemble, ils forment un cycle écrire-relire-renforcer qui s'améliore réellement avec le temps au lieu de se dégrader.

La mise en place pratique : faire tourner ça dès aujourd'hui

Si vous voulez commencer à utiliser Autodream tout de suite, voici le workflow exact auquel je suis arrivé après deux semaines d'itération.

Étape 1 : Vérifiez votre version. Autodream nécessite Claude Code v2.1.59 ou ultérieur. Lancez claude --version dans votre terminal. Si vous êtes en retard, mettez à jour d'abord.

Étape 2 : Activez-le. Ouvrez une session Claude Code sur un projet avec au moins 10+ sessions de mémoire accumulée. Tapez /memory. Cherchez le toggle Autodream. Si vous le voyez, activez-le.

Si vous ne voyez pas le toggle -- Anthropic déploie encore progressivement en mars 2026 -- vous pouvez déclencher une consolidation manuelle en tapant : "Consolidate my memory files. Review all existing memories, remove contradictions, convert relative dates to absolute dates, merge duplicates, and prune stale entries."

Étape 3 : Sauvegardez d'abord. Sérieusement. Lancez la commande de sauvegarde que j'ai partagée plus tôt. Le premier cycle de dream est le plus agressif car il a le plus de dégradation accumulée à nettoyer. Vous voulez un filet de sécurité.

Étape 4 : Examinez les résultats. Après la fin du dream (8-10 minutes pour la plupart des projets), ouvrez vos fichiers de mémoire et parcourez-les. Cherchez :

• Des entrées qui ont été supprimées mais n'auraient pas dû l'être
• Des résolutions de contradictions qui ont choisi le mauvais gagnant
• Des conversions de dates qui semblent incorrectes

Dans mes tests sur cinq projets, le taux d'erreur était bas -- j'ai repéré un élagage incorrect sur des centaines d'opérations. Mais "bas" n'est pas "zéro," et le coût de rajouter une entrée élaguée est bien moindre que le coût de perdre un contexte de projet important.

Étape 5 : Faites confiance au déclenchement automatique pour la maintenance quotidienne. Une fois que vous avez vérifié que le premier cycle de dream a produit de bons résultats, laissez le déclencheur automatique gérer la consolidation courante. Le seuil de 24 heures + 5 sessions maintient tout propre sans sur-traitement.

Étape 6 : Déclenchez manuellement après des changements majeurs. Base de données refactorisée ? Framework changé ? Module central reconstruit ? Lancez /dream avant votre prochaine session. N'attendez pas le déclenchement automatique.

Ce que cela signifie pour notre façon de travailler avec l'IA

Il y a un an, l'idée que votre assistant de code IA "dormirait" entre les sessions -- passant en revue ses souvenirs, renforçant ce qui compte, élaguant ce qui est obsolète -- aurait semblé être de l'anthropomorphisme absurde. Aujourd'hui c'est un toggle dans votre terminal.

Le nom n'est pas un hasard. Anthropic aurait pu appeler ça "nettoyage de mémoire" ou "consolidation automatique." Ils l'ont appelé "dream." Le system prompt dit littéralement : "You are performing a dream -- a reflective pass over your memory files." Ce choix linguistique signale une intention. Ils ne construisent pas un autocomplete plus intelligent. Ils construisent quelque chose qui maintient une compréhension persistante et évolutive de votre projet -- quelque chose qui devient meilleur pour vous aider plus vous travaillez ensemble, au lieu de se dégrader lentement sous le poids de ses propres notes accumulées.

Après la session 34 sur mon projet Laravel -- celle où Claude a suggéré avec confiance un middleware Sanctum que nous avions supprimé dix-neuf sessions plus tôt -- je me suis sincèrement demandé si les projets Claude Code au long cours étaient viables. La dégradation de la mémoire semblait inévitable. Plus on l'utilisait, plus la mémoire devenait bruitée, et plus la mémoire devenait bruitée, moins les suggestions étaient fiables.

Trois cycles de dream plus tard, la session 47 sur le même projet a ressemblé à travailler avec un ingénieur senior qui aurait passé le week-end à relire la documentation du projet. Des références propres. Des connaissances architecturales précises. Pas d'hésitation sur les décisions que nous avions prises ensemble.

Ce n'est pas une petite amélioration. C'est la différence entre un outil IA contre lequel vous luttez et un collaborateur IA en qui vous avez confiance.

La fonctionnalité est encore en cours de déploiement. Tout le monde n'a pas encore le toggle. Mais si vous utilisez Claude Code v2.1.59 ou ultérieur et que vous avez des projets avec 20+ sessions de mémoire accumulée, vérifiez /memory aujourd'hui. Si l'option Autodream est là, activez-la.

Votre agent IA a besoin de dormir. Et honnêtement ? Après avoir vu ce qui se passe quand il dort, c'est le cas de tous les autres outils IA de votre stack aussi.

Questions fréquemment posées

Comment déclencher Autodream manuellement dans Claude Code ?

Tapez /memory dans votre session Claude Code et cherchez le toggle Autodream. Alternativement, tapez "consolidate my memory using dream" directement dans le chat. La consolidation prend 8-10 minutes et s'exécute en arrière-plan sans bloquer votre session active. Nécessite Claude Code v2.1.59 ou ultérieur.

Est-ce qu'Autodream supprime des souvenirs importants ?

Autodream élague les entrées qu'il identifie comme obsolètes -- des informations non référencées ni renforcées lors de sessions récentes. Dans de rares cas, il peut supprimer des entrées dormantes mais pertinentes. Sauvegardez votre répertoire de mémoire avant votre premier cycle de dream et examinez les résultats. Pour un aperçu détaillé de la logique d'élagage, consultez la section des Quatre Phases ci-dessus.

À quelle fréquence faut-il lancer /dream manuellement ?

Laissez le déclencheur automatique gérer la maintenance quotidienne (il tourne toutes les 24+ heures après 5+ sessions). Déclenchez manuellement après des refactorings majeurs, des migrations de framework, ou quand Claude commence à hésiter sur des questions auxquelles il devrait répondre avec confiance. Je lance des dreams manuels environ deux fois par semaine sur les projets actifs.

Quelle est la différence entre Auto Memory et Autodream ?

Auto Memory capture des notes pendant les sessions actives -- il écrit vers l'avant. Autodream consolide ces notes entre les sessions -- il regarde en arrière, nettoyant les contradictions, convertissant les dates relatives et élaguant les entrées obsolètes. Les deux sont nécessaires : Auto Memory sans Autodream accumule du bruit, Autodream sans Auto Memory n'a rien à consolider. Consultez le tableau comparatif ci-dessus pour la ventilation complète.

Est-ce qu'Autodream modifiera mes fichiers de code ou CLAUDE.md ?

Non. Autodream traite exclusivement les fichiers de mémoire dans le répertoire de mémoire de votre projet. Il ne touche ni le code source, ni les fichiers de configuration, ni votre CLAUDE.md. Le verrou de fichier qu'il place pendant la consolidation n'affecte que les fichiers de mémoire, et vous pouvez continuer à coder normalement pendant qu'un cycle de dream s'exécute.

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