Réduction du quota Claude Code : les agents créent-ils de nouvelles « montagnes de code hérité » ?

La prolongation du quota hebdomadaire de Claude Code attire l'attention, un article analyse le mécanisme de consommation de tokens des agents. L'exécution prolongée des agents entraîne un élargissement constant de l'ensemble de travail, chaque étape accumulant l'état historique, et en raison de la caractéristique selon laquelle les hits de cache occupent toujours le contexte, le coût de calcul augmente de manière cumulative. Un nettoyage excessif provoque des « défauts sémantiques », obligeant l'agent à récupérer à nouveau les informations. L'article souligne que cette incohérence entre l'état du code et la précision de la sauvegarde de l'état de conception peut conduire à la génération par l'IA de « code hérité » : les agents ultérieurs ne comprennent pas les causes et effets de la conception du code antérieur, aboutissant finalement à un code complexe où files d'attente, contournements et nouvelles tentatives se compensent mutuellement.

Auteur et source de l'article : Leifengwang

Le code a bien été écrit par un Agent, mais les Agents ultérieurs ne savent plus pourquoi l'Agent précédent l'a écrit ainsi.

L'incitation de +50 % sur le quota hebdomadaire de Claude Code, initialement prévue pour se terminer le 19 août, a été prolongée par Anthropic jusqu'au 31 août. Juste avant ou autour de la date de fin prévue, un débat a émergé sur Hacker News concernant le coût d'utilisation de Claude Code : plusieurs utilisateurs ont constaté qu'une tâche peu complexe, une fois exécutée par l'Agent sur plusieurs cycles, épuise rapidement le quota.

Le problème est que Claude Code ne consomme pas seulement les quelques lignes de code générées en fin de processus. La lecture des fichiers, la recherche des chaînes d'appel, l'exécution des tests et le traitement des journaux chaque étape continue d'alimenter le contexte suivant. Plus la tâche est longue, plus l'historique porté par l'agent est lourd, et plus le système dépend du nettoyage et de la compression.

Le code peut rester entièrement dans le dépôt, mais les raisons initiales de sa conception peuvent s’effilocher progressivement au fil des compressions. Ainsi, la consommation de jetons et la montagne de code commencent à se croiser au même endroit.

Les limites de calcul du Chat coding standard sont claires. Vous entrez un morceau de code, le modèle le lit et fournit une explication ou une proposition de modification ; ce tour est généralement terminé.

L'unité de base de Claude Code a été remplacée par une boucle d'agent. Le modèle observe d'abord l'état actuel, décide quel fichier lire ou quelle commande exécuter ensuite ; après que l'outil ait retourné le résultat, le modèle effectue un nouveau cycle de décision.

Lire le code source, rechercher les références, exécuter les tests, consulter les différences Git, modifier les fichiers : cela semble être un processus continu, mais en réalité, du côté du modèle, il s'agit d'une série de demandes d'inférence indépendantes. La documentation officielle de Claude Code présente ce cycle « le modèle évalue — appelle un outil — évalue le résultat et continue » comme le cœur de son fonctionnement en tant qu'agent.

Par exemple, un problème de connexion occasionnellement perdue. L'agent trouve d'abord le point d'entrée, découvre que l'état provient du service, puis lit le service ; en voyant le cache, il recherche qui l'écrit ; lance ensuite des tests, où un autre anomalie apparaît, donc il examine le fixture ; après correction, il vérifie à nouveau, mais les anciens tests révèlent un problème de compatibilité.

Il se peut qu'il n'ait réellement commencé à écrire ces quelques lignes de code qu'à ce moment-là. Ainsi,diff il n'existe presque aucune relation stable entre la taille du diff et la quantité de calcul. Derrière une patch de 5 lignes, il peut y avoir seulement 3 inférences, ou bien 30 interactions avec des outils.

Si l'on décompose une tâche Agent, on peut d'abord obtenir deux variables : une est le nombre d'étapes, c'est-à-dire le nombre d'étapes que l'Agent a effectuées pour accomplir la tâche ; l'autre est l'ensemble de travail, qui indique combien d'éléments d'état le modèle doit encore maîtriser à l'étape actuelle.

Augmenter simplement le nombre d'étapes augmente déjà la consommation. Si le working set continue de croître en cours de synchronisation, la situation devient totalement différente. L'étape 3 peut ne nécessiter que le traitement de quelques milliers de tokens, tandis que l'étape 30 pourrait déjà porter les règles du projet, le code source associé, les résultats des tests, l'historique des modifications et les outils pour continuer l'inférence.

C'est aussi le point de départ de la modification de la structure des coûts de Coding Agent : la quantité de calcul dépend désormais de « combien d'étapes × combien de poids à chaque étape », et non plus du nombre de lignes de code écrites.

Décomposer une requête de modèle d'Agent peut être grossièrement divisé en trois parties. Les éléments relativement stables incluent le prompt système, CLAUDE.md, les définitions d'outils et les règles du projet ; les éléments en constante évolution comprennent les fichiers de code, les résultats de recherche, les journaux de test, le Git diff et les traces des tâches précédentes ; enfin, il y a le raisonnement, le texte et le code générés lors de cette itération.

On peut facilement commettre une erreur : puisque le contenu précédent a déjà été lu, il ne devrait pas générer de coûts répétés. Le problème est que les LLM n’ont pas de mémoire interne accessible à tout moment, comme dans un programme traditionnel. Les informations connues lors du cycle précédent doivent continuer à apparaître dans le contexte disponible si le cycle suivant en dépend encore.

Le cache de prompt peut atténuer ce problème. La documentation officielle de Claude Code indique clairement que, sans mise en cache de prompt, chaque requête doit traiter à nouveau l'ensemble de l'historique ; une fois que le cache est atteint, les préfixes stables déjà traités peuvent être réutilisés, réduisant ainsi les calculs répétés et les coûts.

Mais le cache résout la question « peut-on réutiliser le même historique à moindre coût », sans résoudre celle-ci « cet historique doit-il encore exister ». Après qu’un état ancien de 100K Token ait été trouvé dans le cache et qu’il ait réduit les coûts, il occupe toujours le contexte et reste l’état sur lequel repose l’inférence actuelle.

On peut donc écrire grossièrement une tâche longue comme suit : la taille d'entrée à l'étape t est environ égale au préfixe stable S, plus l'ensemble de travail actif W_t, plus les nouvelles informations générées lors de cette itération Δ_t.

Le véritable problème est W_t. Si, à chaque étape, l'Agent lit un peu plus de code source, obtient un peu plus de journaux et laisse une décision de plus, tandis que les anciennes informations ne sont pas supprimées à temps, alors W_t augmentera continuellement au fur et à mesure de l'avancement de la tâche.

Dans un modèle extrêmement simplifié, sans aucun cache ni nettoyage, si chaque cycle ajoute à peu près le même nombre d'états valides, le volume total traité présente une structure cumulative proche de 1 + 2 + 3 + … + n. Autrement dit, si le nombre d'étapes double, l'ensemble des états historiques traités peut augmenter plus rapidement.

Le système réel dispose de cache, d'édition de contexte et de compaction, et ne suit pas mécaniquement cette courbe de croissance, mais la forme du problème reste inchangée : plus l'Agent fonctionne longtemps, plus chaque nouvelle action risque de s'appuyer sur un historique plus lourd.

Ainsi, le court prompt utilisateur dans les tâches longues perd rapidement sa pertinence. Ce qui commence véritablement à dominer les coûts, c’est l’ensemble de travail que le modèle doit constamment maintenir pour assurer la continuité de la tâche.

Pourquoi le jeu de travail grossit-il si rapidement ? Les sorties d'outils en sont une source majeure. Le code source a au moins une structure, tandis que les journaux n'en ont souvent aucune.

Une grep peut retourner des centaines de références, une construction peut produire de nombreux avertissements, un échec de test peut inclure une trace complète, et Docker, les compilateurs, les gestionnaires de paquets génèrent également une quantité importante de texte sans valeur durable pour la tâche.

Supposons que le test à l'étape 10 ait généré un journal de 8K tokens. Lorsqu'il entre pour la première fois dans le contexte, il ne s'agit que de 8K tokens. Toutefois, l'agent doit continuer à vérifier le code source, à le modifier et à retester ; tant que ce journal reste dans l'historique valide, il augmentera le poids de base de nombreuses demandes ultérieures.

C'est similaire à l'amplification d'écriture dans les systèmes de stockage : une écriture logique entraîne des traitements supplémentaires en couche inférieure. Dans le cas de l'agent, une sortie d'outil est écrite dans l'historique d'exécution, puis déplacée avec les étapes ultérieures de raisonnement.

Ainsi, le même jeton 8K, placé une ronde avant la fin de la tâche ou au début de la tâche, a un impact global totalement différent. Claude Code réduit désormais activement cette pollution. L'officiel recommande d'isoler les tâches à haute sortie à l'aide de sous-agents et mentionne explicitement que les résultats de recherche, les journaux et le contenu de nombreux fichiers consomment le contexte de la session principale ; la définition des outils occupe également de l'espace, ce qui signifie qu'un ensemble d'outils trop vaste augmente également la charge d'état.

Mais voici un problème inverse : on ne peut pas supprimer tous les journaux simplement parce qu’ils sont coûteux. Dans un journal de 3000 lignes, seules 20 lignes peuvent être liées à la cause racine. Le système ne sait pas à l’avance quelles sont ces 20 lignes. Si le nettoyage est effectué trop tôt, l’agent pourrait plus tard avoir besoin d’un de ces détails, et devrait alors relancer le test ou rouvrir le fichier.

Cela peut être appelé une défaut de page sémantique. Dans la mémoire virtuelle traditionnelle, lorsqu'un programme accède à une page qui n'est plus en mémoire, le système la recharge depuis le disque ; de même, lorsque l'agent de codage jette une preuve antérieure, un phénomène similaire se produit, se manifestant par une nouvelle recherche dans le dépôt, une lecture répétée des fichiers, la réexécution de commandes, voire la redérivation d'un problème déjà analysé.

Ainsi, la tâche longue se retrouve dans une impasse : conserver trop d’historique rend chaque étape suivante de plus en plus lourde ; nettoyer trop agressivement fait que l’agent récupère constamment des informations déjà vues précédemment.

Cela explique également pourquoi la gestion du contexte ne peut pas être simplifiée en « insérer moins de tokens ». Ce qu'il faut véritablement résoudre, c'est la sélection de l'ensemble de travail : quelles informations doivent rester dans l'ensemble de travail à ce moment précis, et lesquelles ne sont que des produits intermédiaires ayant déjà accompli leur mission.

À ce stade, compaction, memory et sub-agent prennent véritablement leur raison d'être.

Claude Code compresse automatiquement la session lorsqu'il approche la limite de contexte et nettoie également certains résultats d'outils plus anciens. L'officiel rappelle que les conversations inutiles, le contenu des fichiers et les résultats des commandes dans une session longue peuvent remplir la fenêtre et perturber les performances du modèle.

Du point de vue du système, la compaction ressemble à un ramassage des ordures sémantiques. Le problème réside dans le fait que le ramassage des ordures classique détermine si un objet a encore des références, tandis que l'Agent doit déterminer si cette information aura encore un sens à l'avenir.

Le dernier est beaucoup plus difficile. Par exemple, une conclusion de conception précoce était la suivante : un module ne peut pas mettre en cache l'état utilisateur lui-même, car le système exige qu'un seul propriétaire détienne l'état et que toutes les modifications passent par le service.

Après plusieurs étapes, si cette information est résumée à : « Le problème d'état a été résolu précédemment via le service. » Les faits ne sont pas erronés, mais l'information a changé. Le contenu original contenait une contrainte, tandis que le résumé suivant ne conserve que l'événement.

Lorsque le prochain Agent rencontrera un problème de performance et constatera que les appels de service sont lents, il ajoutera probablement à nouveau un cache dans le module. Il ne viole pas les informations qu'il possède actuellement ; la relation causale interdisant le cache n'est plus valide.

Le document contextuel de Claude Code indique explicitement que certaines règles limitées à un chemin et les fichiers CLAUDE.md imbriqués sont compressés et résumés au cours de la session, et doivent être rechargés en lisant à nouveau les fichiers correspondants.

Memory tente de résoudre le problème de la conservation à long terme des connaissances. Les fichiers CLAUDE.md et auto memory à la racine du projet permettent d'extraire les commandes de construction, les spécifications du projet, les expériences de débogage, etc., des conversations à court terme, et de les recharger au début de chaque session. Toutefois, Anthropic précise clairement que ces mémoires restent des contextes et ne constituent pas une configuration obligatoire.

Cette distinction est cruciale. Si « l'accès direct à la base de données n'est pas autorisé ici » est uniquement écrit en mémoire, il reste une phrase en langage naturel que le modèle doit comprendre et respecter. Si la même règle est exprimée sous forme de lint de dépendance, de contrainte de type ou de vérification CI, elle devient alors un invariant logiciel impossible à contourner facilement.

Le sous-agent traite un autre aspect : l'isolation de l'ensemble de travail. Faire qu'un agent indépendant scanne un dépôt ou analyse un long journal, puis renvoie un résultat compressé à l'agent principal, permet d'éviter que le bruit original n'entre dans le fil principal. L'une des utilisations officielles du sous-agent par Claude Code est l'isolation du contexte.

Son coût est également intéressant : l'agent principal obtient un état plus propre, mais perd une partie des preuves originales ; l'exécution simultanée de plusieurs agents établit également leurs propres contextes. Ainsi, en considérant ensemble la compaction, la mémoire et les sous-agents, ils ressemblent déjà à une hiérarchie de mémoire à l'ère des agents :

Le contexte actuel est une mémoire de travail coûteuse, la compaction est chargée de la compression, la mémoire conserve l'état inter-sessions, et les sous-agents utilisent un espace d'adressage indépendant pour isoler le bruit. La question est passée d'un niveau « le contexte est-il suffisamment grand » à un autre niveau :

Quels états nécessitent une sauvegarde à haute fidélité, et quels états n'exigent qu'un résumé ? Cette question aura un impact direct sur la qualité du code ultérieur.

Après avoir compris la structure d'exécution précédente, en examinant le quota hebdomadaire de Claude Code, on constate qu'il est difficile pour la plateforme de continuer à mesurer les agents selon le « nombre de messages », car un message a perdu sa signification stable.

Changer le nom d'une variable est un message,重构整个认证模块 est aussi un message. Le premier peut être terminé en quelques étapes, tandis que le second peut nécessiter des dizaines d'itérations, lire des dizaines de fichiers et démarrer plusieurs agents. Une même demande peut cacher des besoins en ressources complètement différents.

Claude Code intègre des limites de défilement et des quotas hebdomadaires ; Codex calcule désormais les crédits en fonction des jetons d'entrée, des jetons d'entrée mis en cache et des jetons de sortie ; les forfaits Cursor offrent différents pools d'utilisation pour les agents, et la consommation des modèles tiers est influencée par les prix des API des modèles.

Les interfaces de trois produits sont en langues différentes, mais les problèmes sous-jacents à résoudre sont très similaires : comment attribuer des ressources d'inférence à un programme intelligent dont le chemin d'exécution ne peut être déterminé à l'avance. Il est difficile de prévoir combien de temps un Coding Agent mettra à s'exécuter au démarrage de la tâche.

Le modèle peut rapidement identifier la cause racine, ou bien émettre plusieurs hypothèses erronées consécutives ; il peut réussir un test du premier coup, ou entrer dans une boucle de débogage prolongée ; il peut nécessiter un seul agent, ou bien être décomposé en plusieurs sous-agents.

Les API traditionnelles aiment facturer selon les requêtes, car les fluctuations de ressources d'une seule requête peuvent encore être contrôlées dans une certaine limite. Les agents dispersent cette stabilité. Ainsi, les jetons commencent à avoir un peu l'aspect du temps CPU.

Cette analogie ne peut pas être équivalente. Les différents modèles ont des coûts de calcul différents pour traiter le même nombre de tokens, et les coûts varient entre l'entrée, l'entrée mise en cache et la sortie. Mais du point de vue des développeurs, leurs fonctions deviennent de plus en plus similaires : elles décrivent toutes la quantité de ressources de calcul consommées pour qu'une tâche puisse continuer à s'exécuter.

Lorsqu'Anthropic a augmenté la limite d'utilisation de Claude Code cette année, il a directement lié l'augmentation du quota à l'ajout de capacité de calcul. Cela entraînera un changement d'indicateur intéressant. Auparavant, lors de l'évaluation des agents de codage, il était courant de comparer « qui résout le même problème du premier coup ». À l'avenir, il sera peut-être plus pertinent de mesurer : pour accomplir le même changement d'état de projet, qui consomme le moins de calcul efficace ?

Si un Agent dépense un grand nombre de Token uniquement pour ouvrir à plusieurs reprises des fichiers, relancer des tests et restaurer des contextes déjà perdus, ces Token n'ont pas été échangés contre une avancée technique équivalente.

Et ce type de restauration inefficace d'état se heurte précisément à la dette technique au niveau inférieur.

On peut abstraire un logiciel maintenu par un Coding Agent comme deux états évoluant simultanément. L’un est l’état du code R_t. Les fichiers, les types, les interfaces, les tests, les commits Git appartiennent tous à ce niveau. La ligne ajoutée à l’étape 20 par l’agent, retry reste intacte à l’étape 100 lorsqu’on ouvre le fichier, tant qu’elle n’a pas été supprimée. La précision de conservation des modifications passées dans le code est très élevée.

Un autre ensemble concerne l'état de conception M_t. Pourquoi faut-il ici un retry, pourquoi ce cache ne peut-il être placé que dans le service, pourquoi cet état ne peut-il pas avoir deux propriétaires, pourquoi ce jugement apparemment superflu ne peut-il pas être supprimé temporairement — ces informations relèvent de la causalité de la conception.

M_tIl n'existe pas de stockage naturellement sans perte comme Git. Il est réparti dans les conversations, le raisonnement, les retours des outils, la mémoire, les fichiers de règles et les résumés de compaction. À mesure que les tâches avancent, certaines parties sont supprimées, d'autres sont résumées, et certaines doivent être récupérées à nouveau.

Il en résulte donc un déséquilibre crucial : les résultats obtenus peuvent s'accumuler avec une haute fidélité, tandis que les relations causales ayant généré ces résultats sont continuellement sous-échantillonnées. Cela est bien plus grave que de simplement dire que « l'agent oublie des choses ».

Lors d’un problème de concurrence, après analyse, l’Agent a ajouté une file d’attente. À ce moment-là, sa conclusion complète était : seule la voie d’écriture A présentait une compétition, donc la file d’attente ne pouvait couvrir que A ; la voie d’écriture B nécessite une faible latence et ne peut pas entrer dans cette file d’attente.

Le code a sauvegardé l'ensemble de la file d'attente. Après une longue exécution, l'état de conception pourrait ne plus contenir que « ici, la file d'attente résout les conditions de course ».

Par la suite, une erreur ponctuelle s'est également produite sur B. Lorsque l'agent a de nouveau lu le code, il a naturellement intégré B à la file d'attente existante.

Ensuite, la latence a augmenté, alors un bypass a été ajouté. Le bypass a provoqué des incohérences d'état ponctuelles, donc un retry a été ajouté en périphérie. À ce stade, aucune modification n'était nécessairement absurde ; chaque correctif pouvait même sembler très raisonnable dans l'état local observé à ce moment-là. Le code était devenu, à partir d'un modèle de concurrence clair, un système où queue, bypass et retry se compensent mutuellement.

La montagne de code AI est probablement née ainsi. Elle ne se manifeste pas nécessairement par le modèle écrivant soudainement un tas de déchets, mais plus probablement par l'accumulation progressive de correctifs locaux, jusqu'à ce que le modèle global disparaisse.

Dans les logiciels traditionnels, ce type de problème se forme généralement progressivement lors du transfert de responsabilités. L'auteur original part, et les nouveaux développeurs voient le code ancien sans comprendre pourquoi il existe, ce qui les pousse à ajouter une couche supplémentaire de logique de compatibilité.

L'agent de codage a transformé « transfert de personnel » en « transfert de contexte ». Les étapes 20 et 100 semblent toujours faire partie de la même session Claude Code, mais les états de conception qu'elles ont reçus ne sont plus entièrement identiques. Du point de vue de l'information, cela ressemble davantage à deux ingénieurs qui maintiennent le même dépôt à travers un document de transfert de plus en plus réduit.

Les tests ne peuvent résoudre qu'une partie de ces problèmes. Les tests sont excellents pour protéger le comportement : l'interface doit retourner quoi, une entrée spécifique ne doit pas provoquer de plantage, les bogues passés ne doivent pas réapparaître. Beaucoup de contraintes d'architecture ne s'expriment pas naturellement sous forme d'entrées et de sorties.

L'état ne peut avoir qu'un seul propriétaire, la couche domaine ne doit pas dépendre à l'envers de l'UI, un certain package n'est pas autorisé à se connecter directement à la base de données, les opérations d'écriture doivent passer par une limite de transaction unifiée ; ces contraintes, si elles ne sont présentes que dans la documentation ou la mémoire de l'agent, sont facilement contournées lors de corrections locales.

Un état de projet très problématique se produit : les tests sont encore verts, mais le code devient de plus en plus difficile à expliquer. Encore plus dangereux, il existe des boucles de rétroaction.

L'architecture devient de plus en plus désordonnée ; pour la prochaine compréhension de la fonction, l'agent devra lire davantage de fichiers ; plus les dépendances sont complexes, plus l'ensemble de travail s'agrandit ; plus l'ensemble de travail est lourd, plus le système a besoin d'être nettoyé et compressé ; plus la causalité de la conception est superficielle, plus les modifications ultérieures risquent de dépendre du code actuel et des tests locaux.

Ainsi, la complexité du code augmente le coût des tokens, et la pression sur les tokens encourage à son tour des durées de conservation plus courtes de l'état et des correctifs plus locaux. Il s'agit là du mécanisme plus préoccupant derrière le phénomène « plus on itère, plus il y a de problèmes » dans le codage par agent.

Ce n'est pas un problème de capacité d'un modèle unique, mais un problème système lié à une incohérence de précision entre l'état du code et l'état de conception.

L'agent de codage devient de plus en plus capable d'agir sur de longues périodes, mais « pouvoir fonctionner pendant plusieurs heures » n'est pas nécessairement un bon indicateur de performance.

Si un Agent doit, après avoir travaillé pendant 3 heures, relire un fichier qu'il a modifié il y a 2 heures, réexaminer pourquoi un certain concept abstrait existe, puis réexécuter un test déjà effectué précédemment, une grande partie du calcul pendant ces 3 heures est consacrée à la restauration d'état.

La question suivante deviendra : après 50 étapes, 100 étapes, combien d'informations causales utiles pour les décisions futures un Agent conserve-t-il ?

On peut l'appeler taux de fidélité d'état.

Car il ne mesure pas combien de tokens peuvent être intégrés dans le contexte, mais plutôt combien d'informations clés de conception restent disponibles après appel d'outils, compression, traversée de sessions et récupération de mémoire. Cela signifie également que la mémoire à long terme d'un Agent ne peut pas reposer uniquement sur un contexte plus long.

Certaines connaissances sont mieux adaptées à la mémoire, comme les méthodes de construction de projets et les habitudes de développement ; certaines décisions doivent être intégrées dans des ADR structurés ou un index de code ; tandis que celles qui, si elles sont violées, compromettent les limites d'architecture du système, sont mieux adaptées à être directement intégrées dans les types, les tests, les règles de lint, les dépendances et le CI.

Une règle qui est devenue une contrainte exécutable par un logiciel n'a plus besoin d'être "mémorisée" par l'agent. Au prochain tour, l'agent peut oublier un échange, mais ne peut pas facilement contourner le compilateur et les tests.

Si le taux de fidélité est faible, plus l'Agent fonctionne longtemps, plus il enterrera de mines dans le système.

Cela pourrait également être la ligne que l'Agent de codage doit franchir pour passer de « savoir écrire du code » à « pouvoir maintenir un logiciel à long terme » : déplacer les connaissances en conception à partir d'une mémoire linguistique probabiliste vers un état logiciel récupérable, vérifiable et exécutable.

Plus le temps d'exécution autonome s'allonge, plus un scénario absurde se dessine : l'Agent écrit du code de plus en plus vite, le projet évolue rapidement, mais à intervalles réguliers, il doit à nouveau comprendre le monde laissé par la période précédente.

L'une des phrases les plus courantes dans le code hérité est : « Ne touchez pas à cela, on ne sait pas pourquoi ça explose. »

Le code hérité de l'IA pourrait être encore plus étrange : le code est bien écrit par un Agent, mais les Agents ultérieurs ne savent plus pourquoi l'Agent précédent l'a écrit ainsi.