Comment réduire les tokens sur les longues sessions d'agent

Comment réduit-on les tokens sur les longues sessions d'agent ?

On réduit les tokens sur une longue session d'agent en s'attaquant à la seule chose qui distingue les longues sessions des courtes : la transcription est renvoyée à chaque tour, donc chaque token que vous laissez entrer tôt est refacturé à chaque tour suivant. Réduisez ce qui entre dans le context — des recherches plutôt que des lectures de fichiers entiers, une sortie d'outil filtrée plutôt que des dumps bruts, un manifeste MCP élagué — et segmentez la session pour que la transcription ne grossisse jamais sans limite. C'est tout le jeu. Je passe mes journées à construire des outils qui font exactement cela, alors laissez-moi être franc sur le mécanisme d'abord, car la plupart des conseils « économisez des tokens » le sautent. Une longue session n'est pas chère parce qu'elle est longue. Elle est chère à cause de la manière dont les boucles agentiques relisent l'historique. Comprenez ça de travers et vous optimiserez la mauvaise chose. Ceci est le complément « longues sessions » de Comment réduire l'usage de tokens des agents de coding IA. Si vous voulez d'abord les fondations indépendantes de l'agent, commencez par là. Ici, je me concentre sur la seule variable qui domine dès qu'une session dépasse, disons, vingt tours : le context accumulé.

Pourquoi les longues sessions coûtent-elles tellement plus que les courtes ?

Les longues sessions coûtent plus cher parce que l'input par tour grossit avec la transcription, donc le coût total sur une session croît à peu près de façon quadratique, pas linéaire. À chaque étape d'une boucle agentique, le modèle relit toute la conversation jusqu'ici — vos prompts, son raisonnement antérieur, et chaque résultat d'outil — avant de produire l'action suivante. Une lecture que vous avez engagée au tour 3 est repayée aux tours 4, 5, 6 et ainsi de suite jusqu'à la fin de la session ou la compaction du context. Mettons des chiffres dessus. Disons que chaque tour ajoute environ 2 000 tokens de nouveau context (deux ou trois lectures de fichiers, la sortie d'une commande). Au tour 30, la transcription cumulée fait ≈60 000 tokens d'input, et vous la renvoyez intégralement à chaque tour. Additionnez l'input sur les 30 tours et vous facturez de l'ordre de 900 000 tokens d'input pour une session dont le contenu unique ne faisait que 60 000. Ce multiplicateur de ≈15x est le vrai coût de la longueur, et c'est pourquoi une seule lecture négligente de 15 000 tokens tôt dans une session est tellement pire que la même lecture vers la fin. La context window est le plafond ici, pas le budget. Vous pouvez rester bien en dessous de la limite de la fenêtre et payer quand même une fortune, parce que le coût est l'aire sous la courbe de l'input par tour, pas le pic. Les gens fixent « context : 40 % plein » et se sentent en sécurité. La facture n'est pas d'accord. Deux choses adoucissent partiellement cela, et vous devriez en connaître les limites :

Prompt caching. Un cache read coûte environ 10 % du prix d'input normal, donc le préfixe renvoyé d'une transcription stable est bon marché — à condition qu'il reste identique octet pour octet. Dès que quelque chose mute le context précoce (un outil dont la sortie change, un system prompt édité), le cache se brise à partir de ce point et vous repayez plein tarif. Le caching récompense la stabilité ; les longues sessions sont précisément là où la stabilité meurt en silence.
Compaction native. La plupart des agents (le /compact de Claude Code, la synthèse de Cursor) finiront par résumer les anciens tours. Utile, mais avec perte et réactif — cela se déclenche après que vous ayez déjà payé pour accumuler le surplus, et cela peut écarter le seul détail dont vous aviez besoin trois tours plus tard.

Quel est le levier le plus important ?

Le levier le plus important est d'empêcher le déchet d'entrer dans la transcription en premier lieu, car tout ce que vous excluez au tour N est exclu de chaque renvoi après le tour N. La prévention se compose ; le nettoyage non. Par ordre approximatif d'impact sur une longue session de coding : 1. Chercher plutôt que lire. La source dominante de surplus accumulé, ce sont les lectures de fichiers entiers dont l'agent n'a jamais eu besoin. Un fichier de 500 lignes fait ≈5 000–7 000 tokens ; un agent qui « se repère » pourrait en tirer une douzaine avant d'écrire une ligne. Le semantic code search renvoie les trois fonctions pertinentes au lieu de trois fichiers entiers, ce qui peut faire la différence entre 600 tokens et 18 000 — et rappelez-vous, sur une longue session vous multipliez cet écart par chaque tour restant. 2. Filtrer la sortie des outils. Les longues sessions lancent beaucoup de commandes, et la sortie brute d'une commande est le pire genre de surplus : volumineuse, à faible signal, et collante. Un npm test qui échoue peut émettre 15 000 tokens de stack traces et de coches de tests réussis quand l'agent n'avait besoin que du nom du test en échec et de l'assertion cassée — peut-être 50 tokens. L'output filtering garde le signal et jette le superflu avant même qu'il n'atterrisse dans la transcription. Plus de détails dans Output filtering pour les logs de commandes. 3. Élaguer le manifeste MCP. Chaque serveur MCP connecté ré-annonce ses définitions d'outils à chaque tour, utilisé ou non. Sur une session courte, c'est une note de bas de page ; sur une session de 40 tours, c'est une taxe constante payée 40 fois. Déconnectez les serveurs que vous n'utilisez pas cette session, ou utilisez le lazy loading pour que les définitions ne soient envoyées que lorsqu'un outil est réellement appelé. Voir MCP et Meilleurs serveurs MCP pour Claude Code. 4. Compresser ce que vous devez garder. Quand l'agent a réellement besoin de la forme d'un fichier mais pas de ses corps, la compression de context via des squelettes — signatures, types, docstrings, moins les implémentations — garde la structure utile à une fraction des tokens.

Comment empêcher la transcription de grossir sans limite ?

On arrête la croissance illimitée par de la discipline sur les frontières de session : terminez une session quand sa tâche est faite, et démarrez-en une fraîche pour la tâche suivante plutôt que de laisser un chat absorber tout votre après-midi. C'est l'optimisation la moins chère qui existe, et elle ne demande aucun outillage. L'instinct de garder un seul chat à longue durée « pour qu'il se souvienne du context » est exactement à l'envers côté coût. L'agent ne se souvient pas gratuitement — il repaie cette mémoire à chaque tour. Si la tâche B ne dépend pas réellement de la transcription de la tâche A, une nouvelle session est strictement moins chère et produit généralement un meilleur résultat, car le modèle n'est pas distrait par du context périmé. Concrètement :

Une tâche, une session. Terminez la fonctionnalité, fermez le chat. La correction de bug suivante démarre propre.
Compactez de façon proactive, pas réactive. Si votre agent supporte la compaction manuelle, déclenchez-la à un point de rupture naturel (tests au vert, fonctionnalité finie) plutôt que d'attendre le déclenchement automatique qui se produit après que le surplus soit déjà payé.
Passez le relais via des artefacts, pas la transcription. Si la tâche B a besoin du context de la tâche A, écrivez ce context dans un fichier — une courte note de conception, un CLAUDE.md, une checklist — et laissez la nouvelle session lire ce fichier de ≈300 tokens au lieu de ré-ingérer une transcription de 60 000 tokens.
Surveillez l'input par tour, pas seulement le remplissage de la fenêtre. Si l'input de chaque tour ne cesse de grimper, vous accumulez. Cette courbe, pas la barre de pourcentage de remplissage, est votre coût.

Si vous voulez savoir ce qu'est réellement un token et comment le texte en devient un, l'entrée de glossaire tokenizer est la version en deux minutes ; pour la vue d'ensemble des coûts, voyez notre décomposition des coûts en tokens des agents de coding IA.

À quoi cela ressemble-t-il en argent réel ?

Cela ressemble à la différence entre une facture mensuelle confortable et une inconfortable, et le modèle que vous choisissez met à l'échelle toute la courbe. Aux tarifs API actuels — Claude Opus 4.8 à $5 / $25 par MTok (input / output), Sonnet 4.6 à $3 / $15, Haiku 4.5 à $1 / $5, GPT-5.5 à $5 / $30 — ce multiplicateur de longueur de 15x frappe le plus fort côté input, qui est précisément le côté qu'une longue transcription gonfle. Reprenez l'exemple précédent : une session de 30 tours facturant ≈900 000 tokens d'input dont seulement ≈60 000 étaient uniques. Sur l'input d'Opus 4.8 à $5/MTok, vous avez payé environ $4.50 pour de l'input que vous auriez pu livrer comme $0.30 de contenu unique — et c'est avant l'output. Le prompt caching peut récupérer la majeure partie du préfixe renvoyé à ≈10 % du prix d'input, mais seulement sur la portion stable, et les longues sessions sont là où la stabilité s'érode. Réduisez plutôt l'apport par tour et vous rétrécissez le multiplicateur à sa source, ce que le caching amplifie alors au lieu de devoir le sauver. Faites vos propres calculs avec le calculateur de coût de tokens LLM avant de supposer que tout cela est trop petit pour compter. Pour la plupart des gens qui livrent quotidiennement, ce n'est pas le cas.

Comment appliquer ceci aujourd'hui

Auditez une vraie longue session. Trouvez votre chat récent le plus long et demandez : quelle part de cette transcription était des lectures de fichiers entiers et de la sortie de commande brute ? C'est votre surplus récupérable.
Activez la récupération search-first. Mettez par défaut l'agent sur la recherche sémantique plutôt que la lecture de fichiers entiers ; réservez les lectures complètes aux fichiers qu'il va réellement éditer.
Filtrez la sortie de commande à la source. Faites passer les commandes bruyantes par un filtre pour que seul le signal entre dans la transcription.
Élaguez MCP aux besoins de cette session. Déconnectez les serveurs inutilisés ; chargez le reste en lazy-load.
Segmentez sans pitié. Nouvelle tâche, nouvelle session. Passez le relais via un petit artefact, jamais la transcription entière.
Mesurez. Suivez les tokens par session pour voir les leviers fonctionner au lieu de deviner.

C'est le workflow que Tokenade automatise pour que vous n'ayez pas à le surveiller : recherche sémantique au lieu de lectures empressées, output filtering sur les appels d'outils, compression par squelette pour les lectures structure-seulement, et lazy loading MCP — plus un dashboard d'économies qui montre les tokens économisés par session, pour que la courbe soit visible au lieu de théorique. Ça marche avec Claude Code, Cursor, Codex, Copilot, Windsurf et les autres, le tier gratuit couvre ≈10M de tokens par mois, et c'est source-available (MIT) pour que vous puissiez lire exactement ce que ça fait à votre context avant de lui faire confiance avec.

Ce qui tourne mal (anti-patterns)

L'erreur la plus courante est d'optimiser le pic au lieu de l'aire. Les gens regardent la barre de remplissage de la context window et se détendent quand elle est à 40 %. Mais le coût est l'input par tour additionné sur chaque tour, pas le point haut. Une session qui plafonne à 40 % pendant 60 tours peut coûter plus qu'une qui pointe à 90 % et se termine en cinq. La deuxième est de traiter la compaction comme de la prévention. L'auto-compaction est une ceinture de sécurité, pas un frein — elle se déclenche après que vous ayez déjà accéléré dans le surplus. Le temps qu'elle résume, vous avez payé pour accumuler tout ce qu'elle s'apprête à jeter. La troisième est de thésauriser un chat éternel pour le confort de la continuité. La continuité n'est pas gratuite ; vous la rachetez à chaque tour. Si la tâche suivante ne dépend pas vraiment de la transcription de la précédente, une session fraîche est moins chère et plus affûtée. La quatrième est de casser votre propre cache sans raison. Le prompt caching ne paie que sur un préfixe stable octet pour octet. Si vous éditez sans cesse le system prompt ou lancez des outils dont la sortie fluctue, vous invalidez le cache en milieu de session et payez discrètement plein tarif sur les renvois. Stabilisez le context précoce, puis laissez-le filer. Si vous en êtes encore à la phase « voyons ce que ça fait » du travail avec les agents, le vibe coding et la discipline du context engineering sont les deux extrémités du spectre — et le coût des longues sessions est exactement là où la seconde commence à se rentabiliser.

Voir aussi :