Le context rot, c'est la dégradation progressive de la qualité de sortie d'un LLM à mesure que sa context window se remplit de tokens périmés, redondants ou à faible signal au cours d'une longue session. Le modèle ne plante pas ; il devient juste discrètement moins bon — il oublie les instructions que vous lui avez données vingt tours plus tôt, relit des fichiers qu'il a déjà vus, contredit ses propres décisions antérieures et se met à halluciner avec assurance parce que le signal réel est désormais enseveli sous un tas de bruit.Le mécanisme est simple dès qu'on arrête de penser la context window comme une « mémoire » pour la voir comme un seul prompt à plat renvoyé à chaque tour. Un agent de code n'a pas une jolie mémoire de travail bien rangée — à chaque tour, il réexpédie au modèle l'intégralité de la transcription accumulée : chaque fichier lu, chaque résultat d'outil, chaque impasse. L'attention est finie et grosso modo en compétition sur tous ces tokens ; alors quand 80 % de la fenêtre est un corps de fonction que le modèle a survolé une fois et un log de npm install de 4 000 lignes, les 20 % qui comptent vraiment doivent se battre pour capter l'attention du modèle. C'est ça, le rot : pas une limite dure que vous heurtez, mais un effondrement lent du rapport signal/bruit dans lequel vous glissez.Et vous le payez deux fois. La qualité chute et la facture grimpe, parce que chaque token pourri est refacturé en input à chaque tour suivant. J'ai vu une seule session d'agent gonfler jusqu'à une transcription de plusieurs centaines de milliers de tokens où peut-être un dixième était porteur — le reste, c'était du rot que le modèle traînait pendant toute la conversation, au plein tarif input à chaque tour.
Pourquoi le context rot compte en 2026
Ça compte parce que les agents sont désormais autonomes et de longue durée. Un tour de chatbot en 2024, c'était vous, une question, une réponse. Un agent de code en 2026 tourne pendant cinquante tours sans surveillance, lit des dizaines de fichiers et lance des commandes dont il déverse la sortie directement dans le contexte. Le rot s'accumule de façon linéaire avec la longueur de la session ; donc plus l'agent devrait être long et utile, plus il devient mauvais — exactement l'inverse de ce que vous voulez.Il existe des preuves mesurables que la décrue est réelle, et pas juste une impression. Le rapport Context Rot de Chroma a constaté que la performance des LLM se dégrade de façon non uniforme à mesure que la longueur de l'input augmente, même sur des tâches bien en deçà de la fenêtre annoncée — des modèles avec une « context window de 1M tokens » ne tournent pas à 1M tokens comme ils le font à 8K. La taille de fenêtre sur la fiche technique est un plafond, pas la promesse d'une qualité constante jusqu'à ce plafond.La solution, ce n'est pas « acheter une fenêtre plus grande ». Une fenêtre plus grande est un plus grand seau à remplir de rot ; elle relève le plafond sans relever le plancher. La solution, c'est de contrôler ce qui entre dans le contexte en premier lieu — ce dont parle le context engineering, et là où un outil prouve sa valeur. Tokenade attaque le rot à la source : la semantic code search pour que l'agent ne récupère que le code pertinent au lieu de lire des répertoires entiers, la skeleton compression pour qu'un fichier entre dans la fenêtre sous forme de signatures plutôt que de corps complets, et l'output filtering pour que ce log d'install de 4 000 lignes atterrisse comme les trois lignes qui comptaient. Moins de déchets en entrée, c'est moins de rot à traîner — et un dashboard d'économies pour réellement voir la différence. Si vous partez d'une configuration Claude Code, le guide de réduction des tokens couvre les manœuvres concrètes.
Quand NE PAS s'en soucier
Les tâches courtes, en un coup. Si votre agent lit deux fichiers, fait une modification et sort, il n'y a aucune session assez longue pour rotir. Le surcoût de compression vous coûterait plus de taxe d'attention qu'il n'en économise.
Quand le « rot » est en fait un problème de rappel. Si le modèle a besoin de chaque ligne d'un fichier de 200 lignes pour répondre correctement, le résumer agressivement ne combat pas le rot — ça ampute du signal. La compression consiste à jeter ce que le modèle n'utilisera pas, pas à l'affamer de ce qu'il utilisera. Sachez lequel des deux vous avez avant de saisir le couteau.
Quand le prompt caching couvre déjà votre souci de coût mais pas celui de qualité. Le caching rend les tokens réexpédiés bon marché (les cache reads tournent à ≈10 % du prix input normal), donc un préfixe stable et rarement modifié est quasi gratuit à garder. Mais le caching rend le rot moins cher, pas moins nuisible — un tas de bruit en cache reste du bruit en compétition pour l'attention. Ne laissez pas un bon taux de cache-hit vous bercer au point de ne jamais élaguer.
