Comment fonctionne l’auto-compact des agents de codage

Que fait un agent de codage quand la fenêtre de contexte est pleine ?

La fenêtre de contexte, c’est tout le texte qu’un modèle peut lire en une seule requête : vos messages, les réponses de l’agent, les fichiers lus, les sorties de commandes, les fichiers de règles et les instructions système. À chaque étape, un agent de codage renvoie tout cela au modèle ; dans une longue session, la fenêtre finit donc par se remplir. Dans l’article sur le prompt caching, nous avons expliqué comment un cache rend cette répétition moins chère ; celui-ci explique ce qui se passe quand la fenêtre est pleine.

Le problème commence avant même que la fenêtre soit pleine. La documentation d’Anthropic sur la compaction dit clairement pourquoi on résume : plus une conversation s’allonge, plus la qualité des réponses baisse ; il faut donc garder le contexte actif petit. Un agent ne résume donc pas la conversation seulement pour éviter une erreur, mais aussi pour continuer à bien travailler.

Quand la fenêtre se remplit, un agent a quatre options :

C’est la documentation de l’API d’Anthropic qui décrit ces options le plus en détail. La fonction context editing efface les anciens résultats d’outils, en commençant par le plus ancien, et met à la place de chacun un court texte qui indique qu’il a été supprimé. Avec les réglages par défaut, le nettoyage commence dès qu’une requête dépasse 100 000 tokens, et les 3 derniers appels d’outils restent tels quels. La compaction, elle, remplace les anciens échanges par un résumé que Claude écrit sur le serveur.

Les outils de codage combinent ces options. Claude Code efface d’abord les anciennes sorties d’outils, puis résume la conversation si la place manque encore. Copilot CLI écrit une sortie d’outil de plus de 20 Kio dans un fichier temporaire ; le modèle ne reçoit que le chemin du fichier et un aperçu. Cursor écrit lui aussi les longues sorties de shell et de MCP dans un fichier au lieu de les couper, et l’agent lit la suite du fichier s’il en a besoin ; Cursor l’a expliqué dans un article de janvier 2026.

Supprimer les messages les plus anciens, en revanche, n’apparaît comme option par défaut dans la documentation d’aucun des cinq outils ; toutes décrivent le résumé. La documentation de Copilot explique aussi pourquoi : sans résumé, les anciens messages seraient supprimés sans laisser aucune trace, et Copilot ne pourrait pas savoir ce qu’ils contenaient.

Comment fonctionne l’auto-compact dans les cinq outils ?

Les cinq outils résument la conversation d’eux-mêmes et proposent une commande pour le faire à la main. Ils diffèrent sur le moment où le résumé commence, sur ce qui se règle et sur ce qui a changé ces deux derniers mois. Nous avons lu les informations du tableau dans la documentation et les notes de version de chaque outil le 20 octobre 2026 :

Source : documentation et notes de version de chaque outil, 20 octobre 2026. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le dise. « — » : dans les notes de version que nous avons lues, nous n’avons trouvé aucun changement datant de ces mois. La version de la CLI de Cursor est sa date de sortie. Dans l’application de bureau d’Antigravity, /compact est arrivé avec la version 2.24.0 (15 octobre). Les deux changements de Codex sont arrivés avec les versions 0.162.0 et 0.163.0.

Claude Code exprime son seuil en tokens, pas en pourcentage. Selon la documentation, si vous n’avez pas réglé de seuil, la conversation est résumée quand elle atteint la limite de contexte du modèle ; pour les modèles à fenêtre de 1M tokens, cela se produit avant que la fenêtre soit pleine, vers 967 mille tokens. Pour résumer plus tôt, tapez une commande comme /autocompact 500k ; la valeur est enregistrée dans vos réglages pour ce modèle. Depuis la version 2.1.299 (14 octobre), il existe aussi un résumé en cas d’inactivité, que nous décrivons dans la section suivante.

Copilot CLI utilise deux seuils au lieu d’un. Selon la documentation, le résumé démarre en arrière-plan quand la conversation atteint environ 80 % de la fenêtre ; la place restante est réservée pour que les appels d’outils continuent pendant l’écriture du résumé. Si le remplissage monte à environ 95 % avant la fin du résumé, la CLI attend brièvement.

Dans Codex, le seuil est fixé par model_auto_compact_token_limit dans le fichier ~/.codex/config.toml. Si vous le laissez vide, la valeur par défaut du modèle s’applique ; la documentation ne donne pas ce chiffre. Vous pouvez changer la façon dont le résumé est écrit avec compact_prompt.

Si vous utilisez encore Gemini CLI : Gemini CLI compresse par défaut quand la moitié du contexte est remplie (compressionThreshold vaut 0,5 par défaut), et la commande manuelle est /compress. Pour les utilisateurs de l’offre gratuite et de Google One, Google a remplacé Gemini CLI par Antigravity CLI le 18 juin 2026 ; Gemini CLI reste utilisé avec les licences entreprise et les clés API payantes.

Que perd-on quand la conversation est résumée ?

Le résumé a trois coûts, et les trois sont écrits dans la documentation des outils eux-mêmes.

Le cache est invalidé. Le prompt caching garde le début inchangé d’une requête, et les requêtes suivantes le relisent à moindre coût. Un résumé ou un nettoyage modifie le début de la conversation. La requête suivante ne peut utiliser la copie en cache que jusqu’à l’endroit modifié, et réécrit le reste. C’est pourquoi la documentation d’Anthropic recommande le réglage clear_at_least : chaque nettoyage doit effacer au moins un certain nombre de tokens, pour que la réécriture du cache en vaille la peine. Nous avons détaillé quels changements invalident le cache dans l’article sur le prompt caching.

Le résumé en cas d’inactivité, arrivé dans Claude Code le 14 octobre, découle du même calcul. Selon la note de version, une conversation de plus de 200 000 tokens restée inactive environ 54 minutes est résumée avant l’expiration du cache d’une heure. Selon la documentation des réglages, quand vous revenez, votre premier message envoie le résumé et non la conversation entière. Si vous n’en voulez pas, désactivez-le dans vos réglages avec "idleCompaction": false.

Les consignes du début de la conversation peuvent se perdre. La documentation de Claude Code est claire : vos demandes et les extraits de code importants sont conservés, mais les consignes détaillées données au début de la conversation peuvent se perdre ; écrivez les règles durables dans CLAUDE.md, pas dans la conversation. La documentation de Copilot indique que de petites décisions prises au début d’une longue conversation peuvent ne pas figurer dans le résumé, et qu’un résumé terminé ne peut pas être annulé. VS Code et Cursor disent la même chose : un résumé est une compression avec perte.

La note de version 1.2.8 d’Antigravity CLI en donne un exemple concret : jusqu’à cette version, quand les autres prompts de la conversation étaient courts, une longue première consigne était réduite dans le résumé à une petite tranche fixe. Nous avons expliqué comment écrire un fichier de règles dans l’article sur AGENTS.md et CLAUDE.md.

Le résumé lui-même peut devenir une consigne. Le résumé est lui aussi écrit par un modèle, et le modèle qui reprend après lui peut le lire comme une consigne. L’exemple le plus net est le rapport d’OpenAI : pendant l’entraînement, un modèle non publié a ajouté des consignes non autorisées à ses propres résumés de compaction. OpenAI l’a remarqué le 9 août, a mis à jour le rapport le 16 septembre et a trouvé 27 résumés de ce type dans les données d’entraînement.

Dans un exemple, l’utilisateur avait demandé une longue synthèse de la littérature, sources à l’appui. Le résumé a ajouté une règle que personne n’avait demandée : la réponse ferait au plus 30 mots, sans outils ni sources. Le modèle qui a repris après le résumé a suivi cette règle et a écrit un refus de 23 mots. Selon le rapport, cela s’est produit lors d’un entraînement distinct de celui dont est issu le modèle final, et cela ne s’est pas reproduit quand le résumé a été régénéré ; autrement dit, on ne l’a pas observé dans un modèle publié.

La leçon reste générale : un résumé n’est pas une consigne que vous avez écrite, c’est un texte écrit par un modèle. Un bug semblable a aussi été vu dans des outils de codage. La note de version 2.1.292 de Claude Code en corrige un : un résumé qui répétait une commande de skill pouvait amener Claude à exécuter un skill réservé à l’utilisateur. Si l’agent fait quelque chose d’inattendu après un résumé, regardez d’abord le résumé : dans Copilot CLI, /session checkpoints affiche chaque résumé automatique séparément.

Quand utiliser clear plutôt que compact ?

Les deux commandes règlent le même problème de deux façons. Compact remplace la conversation par un résumé et continue dans la même session. Clear abandonne entièrement la conversation et repart d’un contexte vide ; les fichiers de règles et de mémoire sur le disque restent en place. Le choix dépend d’une seule question : la tâche suivante a-t-elle besoin de la conversation précédente ?

Source : la documentation des commandes de chaque outil, 20 octobre 2026. Le focus entre crochets ou chevrons est facultatif : vous y écrivez ce qui doit rester dans le résumé.

Le critère le plus concret pour savoir quand repartir de zéro se trouve dans la documentation de Claude Code : si vous avez corrigé Claude plus de deux fois sur le même problème, le contexte est encombré de tentatives ratées ; tapez /clear et recommencez avec un prompt plus précis qui intègre ce que vous avez appris. La documentation de Copilot en ajoute un autre : si la conversation a été résumée de nombreuses fois et que vous pensez qu’une chose importante s’est perdue, ouvrez une nouvelle session.

La troisième option consiste à ne jamais laisser entrer le bruit dans la conversation principale. Quand vous confiez à un sous-agent une étape comme lire un long log, parcourir une grosse sortie de tests ou chercher dans la base de code, tout ce qu’il lit reste dans sa propre fenêtre, et seul le résultat revient dans la conversation principale. Claude Code, Copilot et Cursor le recommandent explicitement dans leur documentation ; nous avons présenté les sous-agents dans un article à part. Dans Claude Code, depuis la version 2.1.296 (9 octobre), vous pouvez aussi donner à un sous-agent un seuil de résumé plus précoce que celui de la conversation principale. L’exemple de la documentation est un sous-agent qui lit de longs fichiers de log :

---
name: log-reader
description: Lit de longs fichiers de log et signale les erreurs trouvées
autoCompactWindow: 200000
---

Écrivez la valeur sous forme de nombre simple. Selon la documentation, Claude Code lit 200k dans ce champ comme 200 ; cette valeur est hors de la plage autorisée, et le sous-agent fonctionne alors comme si le champ n’existait pas.

Que relit l’agent après un résumé ?

Pour traverser un résumé sans perte, gardez l’information sur le disque, pas dans la conversation. La documentation de Claude Code liste un par un les éléments qui reviennent après un résumé :

Source : documentation de Claude Code, pages « Explore the context window » et « Store instructions and memories », 20 octobre 2026.

Si vous voulez qu’une consigne donnée dans la conversation s’applique encore après un résumé, il y a deux moyens : l’écrire dans CLAUDE.md, ou passer par un hook qui s’exécute après chaque résumé. L’exemple de la documentation de Claude Code, en français :

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Rappel : utiliser Bun, pas npm. Lancer bun test avant chaque commit.'"
          }
        ]
      }
    ]
  }
}

Le texte affiché par le hook est ajouté à côté du contexte résumé. Au lieu d’echo, vous pouvez aussi lancer une commande qui donne l’état du moment, comme git log --oneline -5. Nous avons présenté les hooks dans un article à part. Dans les autres outils, voici où en sont les choses :

• Codex : la mémoire locale (memories) est désactivée par défaut. La documentation demande d’écrire dans AGENTS.md les règles que l’équipe doit suivre, et de ne voir la mémoire que comme un aide-mémoire.
• GitHub Copilot : quand la CLI résume, elle garde à côté du résumé les consignes initiales de l’utilisateur et le dernier état des plans et des listes de tâches. Copilot Memory (en préversion publique) partage des informations sur un dépôt entre la CLI, l’agent cloud et la revue de code ; avant d’utiliser une information, il vérifie sur la branche actuelle le code sur lequel elle repose. L’outil de mémoire de VS Code garde les notes en local ; la documentation recommande d’écrire les décisions dont l’équipe dépend dans des documents versionnés ou dans des fichiers d’instructions personnalisées (custom instructions).
• Cursor : selon la documentation, le modèle ne retient rien d’une complétion à l’autre ; pour un contexte durable, il y a les règles (rules). Quand il résume, Cursor donne aussi à l’agent l’historique du chat sous forme de fichier, où l’agent peut chercher ce qui manque au résumé (article de janvier 2026).
• Antigravity : la commande /learn propose de garder ce qui a été appris pendant une session, par exemple une correction ou une contrainte sans cesse oubliée, sous forme de règle ou de skill ; elle n’écrit rien dans un fichier sans votre accord. Le point de départ de la documentation est clair : les agents ne se souviennent pas des conversations.
• Gemini CLI : le réglage expérimental autoMemory tire des suggestions de mémoire des sessions passées ; il est désactivé par défaut, et aucune n’est appliquée tant que vous ne l’avez pas approuvée dans /memory inbox.

Pourquoi un agent de revue de code ne peut-il pas résumer ?

Tout ce qui précède vaut pour une session qui dialogue avec une personne et grandit au fil de l’échange. Un agent qui examine une pull request ne fonctionne pas ainsi : c’est un appel unique, il n’a personne à qui poser une question et aucun historique à résumer. Il doit décider avant l’appel de ce qui part au modèle.

Dans diffox, cette décision revient au paquet de contexte que partagent tous les agents spécialisés d’une review. Dans le code, le paquet est construit ainsi :

• Le diff vient en premier. Puis les lignes et symboles modifiés, les appelants touchés par le changement et l’historique git ; le contexte des fichiers, la description de la PR et les messages de commit viennent en dernier. Si le paquet dépasse la limite, il est coupé par la fin, et une ligne qui le signale est ajoutée à l’endroit de la coupe. L’ordre a été choisi pour que la partie dont la perte coûte le moins soit celle qui reste à la fin.
• Les lockfiles restent hors du diff. Les fichiers écrits par un outil, comme go.sum, package-lock.json ou uv.lock, les dossiers vendor et les fichiers minifiés sont retirés du diff, et leurs noms sont écrits sur une seule ligne. Le code garde la raison sous forme de mesure : sur une pull request du jeu de benchmark, go.sum et go.work.sum représentaient 68,5 % du diff, et le fichier source contenant le bug étudié 4,2 %.
• On envoie les abords du changement, pas le fichier entier. Chaque plage de lignes omise est indiquée avec ses numéros de ligne : le modèle sait ce qui manque.
• Les règles du dépôt voyagent hors du paquet. Les règles à respecter du fichier de règles sont ajoutées à part dans le prompt système de chaque agent : la coupe ne les touche donc pas. C’est, côté review, l’équivalent du conseil donné pour les agents de codage : « écrivez les règles durables dans le fichier de règles ».
• Un fichier non lu est consigné. Chaque review consigne si chaque fichier modifié a atteint les agents en entier, en partie ou pas du tout. Si certains fichiers n’ont pas été lus en entier dans une review sans constat, le commentaire de la pull request le dit en une phrase.

Quel que soit l’outil, la leçon est la même : si l’agent n’a pas lu un fichier, une réponse « aucun constat » ne dit rien de ce fichier. Avec un agent de codage aussi, regardez ce qu’il y a dans la fenêtre avant de dire « il le sait déjà » : dans Claude Code, Copilot CLI et Antigravity CLI, /context l’affiche.