La compaction inactive de Claude Code préserve le cache, mais reprend à partir d’un résumé

La compaction inactive de Claude Code peut désormais résumer une longue session avant l’expiration de son cache de prompts, même lorsque la fenêtre de contexte n’est pas pleine. La fonctionnalité cible par défaut les sessions contenant au moins 200 000 tokens. Son compromis central est marqué : Claude revient à un contexte plus court et moins coûteux, mais poursuit à partir d’un résumé généré plutôt que de chaque échange d’origine.

L’ingénieure d’Anthropic Lydia Hallie a décrit ce comportement dans une publication d’octobre 2026 sur la compaction inactive. Les utilisateurs peuvent désactiver la fonctionnalité en ajoutant "idleCompaction": false à un fichier de paramètres Claude Code. Ils peuvent également modifier le seuil minimal de contexte avec CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.

Ce contrôle est arrivé après que des développeurs ont signalé des compactages inattendus dans des sessions de longue durée. Leur préoccupation ne portait pas sur l’existence de la compaction. Claude Code résumait déjà les conversations approchant leurs limites de contexte. Le désaccord concernait la question de savoir si un minuteur d’inactivité devait remplacer une transcription encore exploitable afin de réduire le coût d’un retour après l’expiration du cache.

La compaction inactive de Claude Code change ce que signifie reprendre une session

Une session reprise peut conserver son identité tout en perdant l’historique mot à mot qui l’avait initialement établie.

Claude Code stocke localement les messages de session et permet de les rouvrir avec --continue ou --resume. Cette persistance peut donner à une session l’apparence d’un espace de travail durable. Toutefois, le modèle ne raisonne qu’à partir du contexte envoyé dans sa requête actuelle, et non de chaque élément stocké sur le disque.

Le guide de la fenêtre de contexte d’Anthropic explique que le contexte actif contient l’historique des conversations, le contenu des fichiers, la sortie des commandes, les instructions du projet, les mémoires, les compétences et les instructions système. À mesure que ces éléments s’accumulent, Claude Code efface les anciennes sorties d’outils puis finit par résumer la conversation.

La compaction consiste à remplacer les anciens éléments conversationnels par un résumé plus court. La session reste disponible et Claude peut continuer à travailler. Cependant, le modèle ne reçoit plus chaque échange remplacé mot pour mot.

Le nouveau mécanisme d’inactivité change le moment où ce remplacement peut intervenir. La compaction automatique traditionnelle répond à une diminution du budget de contexte. La compaction inactive répond plutôt à l’inactivité et au calendrier du cache de prompts, à condition que la session soit suffisamment volumineuse.

Des utilisateurs ont commencé à signaler le message « Compacted while idle, before the prompt cache expired » après avoir laissé des sessions sans surveillance. Des signalements ont associé le déploiement à Claude Code 2.1.286, bien que le comportement ait été contrôlé en partie par une activation côté serveur. Installer une version client donnée ne révélait donc pas nécessairement l’état complet du déploiement.

Le minimum par défaut rapporté par Hallie et évoqué dans le dépôt public d’Anthropic est de 200 000 tokens. Ce nombre constitue un seuil d’éligibilité, et non une promesse que la compaction se produira précisément lorsque la conversation atteint 200 000 tokens.

Une session éligible doit également réunir les conditions de cache pertinentes et rester inactive suffisamment longtemps. Une enquête communautaire dans le ticket sur la compaction inactive a constaté que le minuteur approchait la fin d’une période de cache de prompts d’une heure. Des utilisateurs ont observé l’événement visible environ 54 à 56 minutes après la dernière activité.

Ces détails temporels proviennent de participants au ticket ayant examiné le comportement du client et exécuté des tests locaux. La documentation publique d’Anthropic sur Claude Code ne fournissait pas initialement de spécification complète de la compaction inactive. Les lecteurs devraient donc distinguer trois niveaux de preuve : la description de la compaction par Anthropic, l’annonce de l’ingénieure et l’analyse communautaire des détails d’implémentation.

La conséquence vérifiée pour le produit reste claire dans l’ensemble de ces sources. Après une compaction inactive, Claude reprend à partir d’un état conversationnel compressé. La transcription d’origine peut toujours exister localement, mais son contenu complet n’est plus automatiquement présent dans le contexte de travail du modèle.

Cette distinction importe, car la persistance locale et l’attention du modèle résolvent des problèmes différents. Une transcription stockée facilite l’audit et la récupération. Le contexte actif détermine ce que Claude peut prendre en compte lors de sa prochaine réponse.

La fonctionnalité échange fidélité du contexte contre efficacité du cache

La compaction inactive déplace le travail d’un retour potentiellement à froid vers une dernière fenêtre de cache active, en acceptant la perte liée au résumé pour réduire le traitement répété du contexte.

Le cache de prompts permet aux requêtes répétées de réutiliser des préfixes d’entrée identiques. Un accès au cache exige généralement moins de traitement d’entrée que la reconstruction du même grand préfixe après l’expiration de son entrée de cache. Les longues sessions Claude Code créent des préfixes réutilisables particulièrement volumineux, car chaque échange peut inclure les messages précédents, l’activité des outils et les éléments du projet.

La documentation d’Anthropic sur le cache de prompts décrit la durée de vie du cache et le traitement différent des écritures et lectures de cache. Une longue session qui refroidit peut obliger Claude Code à traiter de nouveau un préfixe substantiel lorsque l’utilisateur revient.

La compaction inactive tente d’intervenir avant ce moment. Tant que le grand préfixe reste en cache, Claude Code peut demander au modèle de le résumer. Une requête ultérieure commence avec le résumé plus court et les instructions ou éléments de projet que Claude Code restaure.

Ce mécanisme favorise l’efficacité lorsqu’un utilisateur prévoit de reprendre une grande session après une pause. Au lieu de revenir avec l’intégralité de l’ancien contexte, l’utilisateur revient avec une représentation compressée qui exige moins de tokens à traiter.

Le coût est une perte de fidélité informationnelle. Les résumés préservent des faits et décisions sélectionnés, mais ne garantissent pas la conservation exacte de chaque contrainte, option écartée, observation de test ou correction conversationnelle.

Anthropic reconnaît cette limite générale dans sa documentation sur le contexte. L’entreprise indique que les requêtes et les principaux extraits de code sont préservés lors de la compaction, tandis que des instructions détaillées issues d’échanges antérieurs peuvent être perdues.

Cet avertissement devient plus important dans une session de programmation agentique. Une instruction subtile peut déterminer quel chemin de migration est autorisé. Une hypothèse rejetée peut empêcher Claude de répéter une investigation coûteuse. Une petite anomalie de test peut expliquer pourquoi une correction apparemment évidente n’est pas sûre.

Ces détails peuvent sembler secondaires pour un système de résumé tout en restant déterminants pour l’étape de programmation suivante. Un résumé peut décrire avec précision l’objectif général du projet tout en omettant les éléments qui ont limité son implémentation.

Le risque augmente avec les longues sessions exploratoires. Un développeur peut demander à Claude d’inspecter plusieurs modules, de comparer des conceptions concurrentes, d’exécuter des tests et d’abandonner deux approches. L’orientation finale peut dépendre de résultats négatifs dispersés dans les sorties de commandes et de brèves corrections.

Après la compaction, Claude peut se souvenir qu’une approche a été choisie sans conserver toutes les raisons pour lesquelles les alternatives ont échoué. Il peut alors reconstruire une explication plausible qui diffère de l’investigation réelle.

Cela ne rend pas la compaction intrinsèquement défectueuse. Aucun système fini de gestion du contexte ne peut conserver indéfiniment l’historique mot à mot. Le différend porte sur le moment choisi et l’intention de l’utilisateur.

Près d’une limite stricte de contexte, le résumé empêche la session de s’arrêter. Avant l’expiration du cache, le produit privilégie l’efficacité alors que la session pourrait encore disposer d’une capacité de contexte substantielle.

C’est l’opposition principale de cette histoire : l’efficacité du cache contre la fidélité du contexte. Il ne s’agit pas de Claude Code face à un autre assistant de programmation. Tout agent fonctionnant sur une longue durée doit à terme gérer un contexte fini, mais le déclencheur d’inactivité rend l’équilibre choisi par Anthropic particulièrement visible.

Pourquoi les développeurs se sont opposés à un résumé automatique

La réaction négative portait sur un changement d’état non annoncé, et non sur l’existence même de la compression du contexte.

Un développeur qui saisit manuellement /compact sait que Claude résumera la conversation précédente. La commande peut inclure un axe prioritaire, comme la préservation des décisions d’API ou des échecs de test non résolus. Ce moment crée une limite naturelle pour la révision.

La compaction inactive retire ce choix immédiat. Un utilisateur peut partir déjeuner, assister à une réunion ou attendre un retour externe, puis revenir dans une session dont l’historique actif a changé.

Le signalement GitHub d’origine décrivait plusieurs sessions de travail compactées pendant leur inactivité. Son auteur indiquait que les résumés omettaient des instructions précises, le raisonnement derrière les décisions et des méthodes précédemment convenues. D’autres utilisateurs ont déclaré voir la même notification sans être proches de leur seuil de contexte configuré.

Il s’agit de témoignages d’utilisateurs, et non de mesures contrôlées de l’exactitude des résumés. Ils identifient néanmoins un risque produit crédible, car la documentation d’Anthropic indique déjà que des détails initiaux peuvent être perdus lors de la compaction.

L’implémentation initiale compliquait également la surveillance. Selon des tests documentés dans le ticket, les premières compactations inactives apparaissaient dans les métadonnées des hooks comme manual, alors qu’aucun utilisateur n’avait saisi /compact.

Les hooks de Claude Code permettent aux équipes d’exécuter des automatisations avant ou après des événements définis. Une étiquette de déclenchement trompeuse rend plus difficile la distinction entre une action volontaire de l’utilisateur et une transition pilotée par un minuteur.

Claude Code 2.1.290 a remplacé ce déclencheur par auto, selon un collaborateur d’Anthropic dans le dépôt. Cela distingue la compaction inactive de /compact explicitement invoqué, mais ne différencie pas totalement la compaction inactive de la compaction automatique ordinaire fondée sur un seuil.

Cette ambiguïté importe aux équipes qui utilisent des hooks pour préserver leur état de travail. Un hook pourrait appliquer une politique avant une compaction d’urgence liée à une limite de contexte et une autre avant une compaction inactive déclenchée par le cache.

La discussion du ticket a demandé un déclencheur idle distinct. Selon le comportement rapporté pour la version 2.1.290, les événements d’inactivité comme ceux de seuil de contexte pouvaient apparaître sous auto. La notification du terminal identifiait l’événement d’inactivité pour l’humain, mais cet avis n’était pas nécessairement inclus dans l’entrée des hooks.

La leçon produit plus large concerne l’optimisation invisible. Les développeurs acceptent généralement une optimisation lorsqu’elle modifie la latence ou l’utilisation des ressources sans changer la sémantique. Le résumé peut modifier la sémantique, car la requête suivante du modèle reçoit des éléments de preuve différents.

La compaction inactive s’apparente donc davantage à une migration automatique d’état qu’à une tâche de nettoyage en arrière-plan. L’identifiant de session reste stable, tandis que le substrat de raisonnement change.

Les équipes menant des migrations à haut risque, répondant à des incidents ou réalisant des revues de code prolongées ont des raisons de traiter cette transition avec prudence. Leurs sessions accumulent souvent des contraintes individuellement mineures, mais collectivement importantes.

Les sessions plus courtes sont moins exposées car elles restent sous le seuil minimal. Les flux de travail déjà construits autour de transmissions explicites réduisent aussi le coût, car l’état critique existe en dehors de la transcription de discussion.

La pression s’exerce donc surtout sur les développeurs qui considèrent une longue session Claude Code comme un partenaire de projet persistant. Ils tirent le plus grand bénéfice de la continuité, mais perdent également le plus lorsque cette continuité dépend d’un résumé sans limite intentionnelle.

Le paramètre idleCompaction sépare deux protections différentes

Les utilisateurs peuvent désactiver la compaction inactive sans désactiver la compaction automatique qui protège les sessions proches de leur limite de contexte.

Claude Code 2.1.290 a introduit un paramètre dédié, selon un collaborateur d’Anthropic répondant dans le ticket public. Un utilisateur a ensuite confirmé que l’option fonctionnait dans la version 2.1.291.

La configuration de base est la suivante :

Claude Code prend en charge des paramètres à plusieurs niveaux, notamment utilisateur, projet, projet local et politique gérée. La référence des paramètres d’Anthropic explique leur emplacement et leur ordre de priorité.

Une préférence applicable à l’ensemble des utilisateurs peut être placée dans le fichier de paramètres personnels. Une équipe travaillant sur un dépôt peut placer les paramètres du projet sous contrôle de version lorsque tout le monde doit partager le même comportement. Un paramètre de projet local peut remplacer ce comportement sans modifier la configuration partagée du dépôt.

La distinction importante se situe entre idleCompaction et autoCompactEnabled. Le premier cible le nouveau mécanisme basé sur un minuteur. Le second régit le comportement plus large de compactage automatique.

Désactiver "idleCompaction": false préserve le compactage normal au seuil, conformément au comportement décrit pour la version 2.1.290. C’est utile aux développeurs qui souhaitent une protection à l’approche d’une fenêtre de contexte pleine, mais refusent la synthèse pilotée par le cache pendant les pauses.

Cette séparation a directement répondu à la demande la plus forte des utilisateurs. Avant l’apparition du commutateur dédié, désactiver plus largement le compactage automatique pouvait également supprimer la protection empêchant une session d’atteindre son plafond de contexte.

Les utilisateurs doivent vérifier la version installée avant de supposer que cette clé fonctionne. Exécutez :

Le problème public situe ce paramètre dans la version 2.1.290, tandis qu’un utilisateur a explicitement confirmé son fonctionnement dans la version 2.1.291. Les organisations disposant d’installations gérées peuvent également recevoir les mises à jour selon un calendrier contrôlé.

Le mécanisme d’activation côté serveur de cette fonctionnalité ajoute une autre raison à la prudence. Définir idleCompaction sur true ne force pas nécessairement Anthropic à activer la fonctionnalité pour chaque compte ou environnement. Cela autorise le comportement côté client lorsque les autres conditions d’éligibilité sont remplies.

Le réglage sur false constitue le contrôle pertinent pour les utilisateurs qui ont besoin de se désinscrire. Les équipes doivent néanmoins tester le comportement dans leur propre installation, selon leur type de compte et leur hiérarchie de politiques.

Un paramètre géré peut primer sur le choix d’un utilisateur. C’est approprié pour les organisations ayant une configuration centralisée, mais cela signifie que modifier un seul fichier local peut ne pas produire le résultat attendu.

La méthode de vérification la plus sûre est comportementale. Confirmez la version du client, inspectez les paramètres effectifs et effectuez un test dans une session non critique avant de vous appuyer sur l’option pour un travail important.

Les utilisateurs devraient également conserver les instructions durables en dehors de l’historique conversationnel. Anthropic recommande de placer les règles persistantes dans CLAUDE.md, que Claude Code charge comme contexte de projet. Ce conseil s’applique que le compactage à l’inactivité soit activé ou désactivé, car le compactage ordinaire à l’approche de la limite peut toujours se produire.

Une base de connaissances d’ingénierie consultable peut servir un objectif connexe pour les équipes humaines. Les décisions, contraintes et résultats d’investigation deviennent des artefacts récupérables au lieu de dépendre entièrement d’une seule session d’agent.

Le seuil de 200K est ajustable, mais ce n’est pas une limite de contexte

`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` modifie le moment où une session devient éligible au compactage à l’inactivité, et non la taille de la fenêtre de contexte du modèle.

Hallie a indiqué que le minimum est fixé par défaut à 200 000 tokens. Les utilisateurs peuvent fournir une autre valeur entière via la configuration d’environnement dans les paramètres de Claude Code.

Par exemple :

Cet exemple relève le seuil d’éligibilité à 400 000 tokens. Il n’accorde pas une fenêtre de contexte plus grande, ne réserve pas 400 000 tokens à l’historique de conversation et ne garantit pas que le compactage se déclenche immédiatement à ce stade.

L’analyse du problème public a signalé une limite inférieure de 100 000 tokens. Les valeurs sous ce plancher étaient décrites comme étant relevées à 100 000. Anthropic n’avait pas entièrement documenté la variable d’environnement dans la référence publique des paramètres au moment de la discussion ; les utilisateurs devraient donc considérer les détails d’implémentation comme sensibles à la version.

Relever le seuil favorise la fidélité. Davantage de longues sessions peuvent rester inactives sans être résumées, bien que la reprise après l’expiration du cache puisse nécessiter davantage de traitement des entrées.

Abaisser le seuil favorise l’efficacité du cache. Davantage de sessions deviennent éligibles au compactage avant expiration, ce qui accroît la probabilité que les utilisateurs reviennent à des résumés plutôt qu’à l’historique conversationnel complet.

La bonne valeur dépend de la forme du flux de travail, et pas seulement de la capacité du modèle. Une longue session avec des sorties d’outils répétitives peut se résumer proprement. Une discussion d’architecture plus courte peut contenir des décisions denses et interdépendantes qui résistent à la compression.

Le nombre de tokens mesure la taille, non l’importance sémantique. Une session de débogage de 300 000 tokens peut inclure des milliers de lignes de journaux jetables. Une revue de sécurité de 120 000 tokens peut contenir de nombreuses hypothèses précises sur les menaces qui devraient rester textuellement intactes.

C’est pourquoi un minimum configurable aide sans résoudre la tension fondamentale. Il permet aux équipes de choisir où commence le compromis, mais un seuil numérique ne peut pas reconnaître si la conversation en cours peut être résumée sans risque.

Les développeurs peuvent réduire le risque en créant des points de contrôle explicites avant de quitter une session. Demandez à Claude de consigner l’objectif actif, les constats confirmés, les approches rejetées, les fichiers modifiés, l’état des tests et la prochaine commande dans une note du dépôt.

Cette note ne devrait pas simplement reformuler la tâche. Elle devrait capturer les éléments de preuve nécessaires pour reprendre sans reconstruire l’intégralité de la conversation.

Les contraintes persistantes ont leur place dans CLAUDE.md ou dans un autre fichier de projet faisant autorité. Les découvertes temporaires ont leur place dans un problème, un journal de travail ou un document de transmission. Les résumés générés peuvent alors soutenir la continuité sans devenir l’unique enregistrement.

Les équipes peuvent également utiliser /context pour examiner ce qui consomme la fenêtre active. Si des sorties de commande volumineuses dominent, effacer ou restructurer ce contenu peut être plus sûr que de laisser un résumé général décider de ce qui compte.

Le /compact manuel reste utile aux frontières naturelles. Anthropic indique que les utilisateurs peuvent ajouter des instructions de cadrage, ce qui donne au synthétiseur une meilleure cible de préservation qu’un événement d’inactivité sans supervision.

Le principe général est simple : choisissez le compactage autour des frontières de tâche lorsque c’est possible. Les seuils de tokens préviennent les échecs, mais les frontières définies par les humains reflètent mieux la structure du travail d’ingénierie.

Ce que le compactage de Claude Code préserve, et ce qu’il ne peut pas garantir

Le compactage préserve une représentation de travail de la session, et non une copie sans perte de son historique de raisonnement.

La documentation Claude Platform d’Anthropic définit le compactage comme le remplacement des anciens tours de conversation par un résumé rédigé par le modèle. Sa présentation du compactage explique que les applications continuent en plaçant le bloc compacté renvoyé à l’endroit où apparaissaient auparavant les messages résumés.

Claude Code gère ce flux de travail au sein du produit. L’implémentation précise diffère de celle d’une application utilisant directement l’API Claude, mais le résultat conceptuel est similaire : les entrées plus anciennes sont représentées par du texte généré.

Un bon résumé peut conserver la demande de l’utilisateur, l’état actuel de l’implémentation, les chemins de fichiers importants, les résultats des tests et les tâches restantes. Il peut réduire drastiquement la quantité de contenu antérieur envoyée lors des tours suivants.

Il ne peut pas garantir la conservation mot à mot de chaque échange. Le synthétiseur doit sélectionner les informations, les organiser et les exprimer dans un budget de tokens plus réduit.

L’historique du raisonnement pose un défi particulier. Une session de programmation contient souvent une chaîne d’éliminations. Claude examine un fichier, formule une hypothèse, constate une sortie contradictoire et change de direction.

Le résumé final peut consigner l’explication retenue tout en compressant le chemin qui l’a validée. C’est souvent suffisant, mais cela réduit la capacité du modèle suivant à auditer la conclusion.

Les sorties d’outils créent un autre problème. Les journaux, erreurs de compilateur, plans de base de données et traces de tests peuvent contenir de petits détails dont l’importance ne devient évidente que plus tard. Un résumé produit avant cette découverte ultérieure ne peut pas savoir quelle ligne importera.

Les corrections de l’utilisateur peuvent également perdre de leur force. « Ne modifiez pas le schéma » peut n’apparaître qu’une fois, suivi de centaines de tours. Si elle n’est pas élevée au rang d’instruction persistante, le compactage peut réduire ou omettre son importance.

La documentation de Claude Code recommande explicitement CLAUDE.md pour les règles qui doivent perdurer. Elle prend également en charge une section « Compact Instructions », qui indique au synthétiseur quoi conserver pendant le compactage.

Ces mécanismes réduisent le risque, mais ne rendent pas les résumés sans perte. Une instruction de compactage reste une indication adressée à un modèle effectuant une sélection. Un fichier d’instructions de projet est plus solide, car Claude Code peut le charger à nouveau comme contexte faisant autorité.

Les développeurs devraient donc répartir les connaissances de session en trois catégories. Les règles de fonctionnement permanentes ont leur place dans les instructions du projet. L’état d’ingénierie vérifié a sa place dans des fichiers ou des enregistrements de travail suivis. L’exploration conversationnelle peut rester dans la transcription et accepter une compression ultérieure.

Cette approche améliore également la collaboration. Un autre ingénieur ne peut pas hériter de manière fiable des nuances non documentées d’une conversation privée avec un agent. Un fichier de transmission concis offre aux humains comme aux agents un point de reprise commun.

La question pratique n’est pas de savoir si les résumés sont bons ou mauvais. Il s’agit de déterminer si un fait particulier peut exister sans risque uniquement à l’intérieur d’un résumé.

Si la perte d’un détail provoquerait une migration dangereuse, un incident répété ou un résultat invalide, consignez-le hors de la conversation avant de quitter la session.

Trois signaux montreront si le compactage à l’inactivité gagne la confiance

Le prochain test consiste à déterminer si Anthropic peut rendre le bénéfice d’efficacité observable sans rendre la continuité des sessions imprévisible.

Le premier signal est la documentation officielle. Les utilisateurs ont besoin d’une description stable de l’éligibilité, du calendrier, des versions prises en charge, des limites de seuil, de la priorité des paramètres et des interactions avec les politiques de cache de prompts.

La documentation clarifierait également si le réglage par défaut de 200 000 tokens s’applique de manière cohérente à tous les modèles et comptes. Si Anthropic documente la variable d’environnement et sa limite inférieure, les équipes pourront la configurer sans dépendre de l’archéologie des problèmes.

Ce résultat renforcerait la confiance dans la fonctionnalité. Une dépendance continue aux publications sociales et à l’inspection binaire l’affaiblirait, car les contrôles non documentés peuvent évoluer sans parcours de migration évident.

Le deuxième signal est la présence de métadonnées de hook distinctes. Un déclencheur idle dédié permettrait aux équipes de traiter le compactage piloté par minuteur différemment des commandes /compact manuelles comme du compactage automatique à l’approche de la limite.

Les organisations pourraient capturer un instantané de l’état avant un événement d’inactivité, joindre des instructions de compactage adaptées ou enregistrer des données de télémétrie sur la fréquence d’activation de la fonctionnalité. Une identité d’événement claire faciliterait également l’investigation des incidents.

Si Anthropic conserve les deux mécanismes automatiques sous la même étiquette auto, les administrateurs disposeront d’une visibilité limitée sur les raisons pour lesquelles une session a changé. Cela maintiendrait un écart entre l’expérience dans le terminal et les interfaces d’automatisation.

Le troisième signal est l’existence de preuves sur la qualité des résumés dans de longues sessions de programmation. Les rapports d’utilisateurs identifient des nuances manquantes, mais la discussion publique n’établit pas de taux d’échec général.

Une évaluation utile mesurerait si les résumés conservent les contraintes explicites, les hypothèses rejetées, les tâches en attente, les échecs de tests, les références de fichiers et les règles de sécurité. Elle devrait également tester le compactage répété, car les erreurs peuvent s’accumuler lorsqu’un état compressé devient l’entrée d’un autre.

Un résultat positif étayerait l’argument d’efficacité d’Anthropic. Il montrerait que la plupart des sessions éligibles reprennent avec une précision suffisante pour justifier la compression automatique avant l’expiration du cache.

Un résultat négatif renforcerait les arguments en faveur d’un comportement sur opt-in ou de seuils par défaut plus élevés. Il pourrait également pousser Claude Code vers un compactage partiel qui conserve les tours récents textuellement tout en résumant le contenu plus ancien.

Pour l’instant, les développeurs disposent d’un choix praticable. Laissez la compaction d’inactivité de Claude Code activée lorsque la réduction de la surcharge de reprise importe davantage que la continuité à l’identique. Augmentez le seuil de tokens lorsque seules les très longues sessions justifient ce compromis.

Désactivez-la avec "idleCompaction": false lorsqu’une session mise en pause doit reprendre en conservant intact son historique actif existant. La compaction normale liée à la limite de contexte peut rester activée comme protection distincte.

Quelle que soit la politique choisie, ne faites pas d’un long échange l’unique registre de l’état critique d’ingénierie. Inscrivez les contraintes durables dans les instructions du projet, conservez les constatations vérifiées dans des fichiers et préparez une transmission avant de vous absenter.

La compaction d’inactivité de Claude Code révèle une vérité fondamentale sur les agents de programmation : la continuité de session n’est pas synonyme de mémoire parfaite. Avant votre prochaine longue pause, déterminez laquelle de ces deux exigences votre flux de travail requiert réellement.