Comment réduire l’usage de jetons avec des agents IA pour le code : 4 outils utiles
Réduisez la consommation de jetons en limitant l’encombrement du contexte, le bruit du terminal, les réponses verbeuses et le code sur‑ingénieré grâce à des outils légers qui optimisent automatiquement les workflows des agents de code.
Si vous avez déjà atteint la limite de jetons de votre offre d’agent IA après seulement quelques requêtes, vous vous êtes sans doute demandé où tous ces jetons étaient passés.
Vous demandez à l’agent de corriger un bug, de refactorer une fonctionnalité ou d’inspecter un dépôt, et soudain une grande partie de votre quota part en fumée.
Ce n’est pas nécessairement un problème lié à votre fournisseur ou à votre abonnement.
Les agents IA pour le code consomment tout simplement bien plus de jetons que les chatbots classiques. Ils ne se contentent pas de répondre à votre invite. Ils lisent des fichiers, recherchent dans la base de code, inspectent des logs, exécutent des tests, appellent des outils, génèrent du code, relisent leurs propres modifications, et répètent ces étapes plusieurs fois avant de terminer une tâche.
La bonne nouvelle : vous pouvez réduire une grande partie de cette consommation inutile de jetons.
Il existe des outils qui rendent les agents moins bavards, évitent la sur‑ingénierie des tâches simples, compressent le bruit du terminal et empêchent les réponses volumineuses d’outils de saturer la fenêtre de contexte.
Dans ce guide, nous allons voir quatre outils pour réduire l’usage de jetons avec des agents de code : Caveman, Ponytail, RTK et Context Mode.
Nous verrons le rôle de chacun, comment les configurer, et comment les combiner pour accomplir davantage avec des abonnements comme Claude Code et Codex avant d’atteindre vos limites d’usage.
Pourquoi les workflows agentiques utilisent-ils autant de jetons ?
Un chatbot classique prend une invite et renvoie une réponse. Un agent fait généralement bien plus.
Il peut lire des fichiers, appeler des outils, inspecter des logs, récupérer des documents, écrire du code, et répéter ce processus plusieurs fois avant de finir.
Chaque étape ajoute des informations au contexte, et une grande partie de ce contexte est renvoyée au modèle lors des appels suivants.
Voici une boucle d’agent simplifiée :
La requête est envoyée au modèle, le modèle appelle un outil, l’outil renvoie un résultat, et ce résultat est réinjecté dans le contexte avant l’étape suivante. La flèche de rétroaction, c’est là que se trouve le coût : à chaque passage, on transporte l’historique précédent. Ainsi, une tâche qui nécessite six appels d’outils renverra une grande partie de cet historique au modèle six fois.
Cela engendre plusieurs sources classiques de gaspillage de jetons :
Réponses verbeuses : l’agent explique trop quand une réponse courte suffirait.
Sur‑ingénierie du code : une petite tâche se transforme en fichiers, abstractions et dépendances supplémentaires.
Sorties d’outils volumineuses : logs, tests, diffs Git et commandes terminal peuvent renvoyer des milliers de jetons.
Trop de contexte : documents récupérés, définitions d’outils et résultats précédents remplissent vite la fenêtre de contexte.
Sessions longues : plus l’agent travaille longtemps, plus il doit transporter d’historique et de résultats intermédiaires.
Le vrai défi ne porte donc pas seulement sur le nombre de jetons qu’un agent génère, mais sur le nombre qu’il lit, propage et retraitre au fil du workflow.
C’est précisément ce que des outils comme Caveman, Ponytail, RTK et Context Mode cherchent à réduire, chacun ciblant une source différente de gaspillage de jetons.
1. Caveman : faire parler votre agent moins
Caveman est une façon simple de rendre les agents de code plus concis.
Au lieu de laisser l’agent narrer chaque étape, répéter l’évidence ou ajouter du remplissage, il oriente les réponses vers l’information qui compte vraiment.
C’est particulièrement utile pour les longues sessions de code, où des réponses verbeuses augmentent non seulement les jetons de sortie.
Elles finissent aussi dans l’historique de la conversation et sont réutilisées aux tours suivants.
Elle supprime le remplissage, les politesses, les précautions de langage et la narration superflue, tout en laissant intacts les éléments importants comme les blocs de code, commandes, noms d’API et messages d’erreur exacts.
Elle assouplit aussi le style concis lorsque la clarté prime, par exemple pour des avertissements de sécurité ou des actions irréversibles.
Il existe aussi un proxy local optionnel qui s’attaque à l’autre versant du problème : ce que l’agent lit.
Il se place entre l’agent et le fournisseur de modèle et compresse le contexte éligible avant l’envoi de la requête.
La compétence et le proxy fonctionnent indépendamment : vous pouvez commencer par la compétence, légère, puis ajouter le proxy si vous avez besoin d’une réduction plus agressive du contexte.
Voici une manière simple de le visualiser, illustrée ci‑dessous :
À gauche, l’agent encadre son code d’un préambule puis le réexplique après coup. À droite, vous obtenez la réponse utile et le code, rien de plus. Même travail, bien moins de jetons dépensés en narration.
Cela démarre le proxy local de Caveman et fait transiter l’agent par sa couche de compression de contexte.
Pour la plupart, commencez par la compétence seule.
Elle est simple à ajouter, ne change pas votre manière de coder, et s’attaque directement à l’une des sources les plus simples de gaspillage : un agent qui en dit beaucoup trop.
2. Ponytail : éviter la sur‑ingénierie par l’agent
Ponytail cible un autre type de gaspillage : les agents qui écrivent plus de code que nécessaire.
Une demande simple peut parfois entraîner de nouvelles dépendances, des classes auxiliaires, des composants enveloppe et des configurations supplémentaires.
Ponytail cherche à éviter cela en orientant l’agent vers la plus petite solution sensée en premier.
Comment fonctionne Ponytail
Avant d’écrire du code, Ponytail fait passer l’agent par une courte échelle de décision :
À chaque barreau, l’agent a une chance de s’arrêter avant d’écrire quoi que ce soit de nouveau. Il n’atteint la dernière étape — écrire le minimum de code qui fonctionne — qu’une fois la bibliothèque standard, les fonctionnalités natives de la plateforme et les dépendances existantes écartées.
Par exemple, au lieu d’installer une bibliothèque de sélecteur de date et de construire un composant enveloppe, Ponytail peut décider que le navigateur propose déjà :
L’objectif n’est pas de raccourcir tout aveuglément.
Ponytail préserve explicitement la validation, la sécurité, l’accessibilité et la protection contre la perte de données.
L’idée est d’être économe sur l’implémentation, sans compromettre la justesse.
Dans son propre benchmark agentique, Ponytail a produit environ 54 % de code en moins et 22 % de jetons en moins sur 12 tâches de code, par rapport au même agent sans la compétence.
Un benchmark indépendant a également constaté des implémentations sensiblement plus petites, tout en notant que des réglages trop agressifs peuvent parfois rogner la robustesse sur des cas limites non explicités.
Premiers pas avec Ponytail
Avec Claude Code, ajoutez la place de marché :
/plugin marketplace add DietrichGebert/ponytailPropulsé par
Une fois installé, vous pouvez régler l’intensité de la simplification :
/ponytail lite
/ponytail full
/ponytail ultra
/ponytail offPropulsé par
full est la valeur par défaut et constitue probablement le meilleur point de départ. lite construit toujours ce que vous demandez, mais signale des alternatives plus simples, tandis que ultra applique YAGNI de manière bien plus énergique.
Vous pouvez aussi passer en revue une modification existante pour traquer une complexité inutile :
Ponytail est particulièrement efficace avec les agents de code, car réduire le code inutile a un effet domino : l’agent écrit moins de jetons maintenant, produit des diffs plus petits et laisse moins de code à relire plus tard.
3. RTK : réduire le bruit des sorties d’outils
RTK, pour Rust Token Killer, cible une autre source de gaspillage : tout ce que votre agent récupère depuis le terminal.
Des commandes comme git status, les exécutions de tests, les logs, les recherches et la sortie des gestionnaires de paquets peuvent renvoyer des centaines voire des milliers de lignes.
La plupart de ces informations sont utiles pour un humain au terminal, mais un agent n’a souvent besoin que de l’essentiel.
RTK s’intercale entre la commande et l’agent et compresse la sortie avant qu’elle n’arrive au modèle.
Comment fonctionne RTK
RTK applique, selon la commande, du filtrage, du regroupement, de la troncation et de la déduplication pour enlever le bruit tout en conservant les informations utiles : erreurs, échecs, fichiers modifiés et résumés.
Par exemple :
Dans le flux normal, l’agent exécute pytest et lit chaque ligne imprimée, dont la plupart indiquent des tests réussis inutiles pour lui. Avec RTK au milieu, la même exécution revient avec les échecs et un résumé : l’agent lit quelques dizaines de lignes au lieu de plusieurs centaines.
Avec les agents pris en charge, RTK peut s’accrocher automatiquement aux appels shell. Une commande telle que :
L’agent reçoit alors la sortie allégée, sans devoir appeler RTK explicitement à chaque fois.
RTK annonce environ 60 à 90 % de jetons en moins pour la sortie des commandes de développement courantes. Cela ne signifie pas que votre facture LLM totale baisse de 60 à 90 % : cela ne concerne que la sortie terminal compressée par RTK.
RTK prend aussi en charge Cursor, OpenCode, Copilot, Cline, Windsurf et plusieurs autres agents de code.
Une fois configuré, continuez à utiliser vos commandes terminal habituelles.
RTK gère la compression en arrière‑plan, ce qui est particulièrement utile pour les agents qui passent beaucoup de temps à exécuter des tests, rechercher dans le code, inspecter des changements Git et lire des logs.
4. Context Mode : garder les grosses sorties d’outils hors du contexte
Context Mode se concentre sur ce qui se passe après que l’agent commence à utiliser des outils.
Une capture navigateur, une liste d’issues GitHub, une recherche de fichiers ou la sortie d’une grosse commande peuvent injecter un volume massif d’informations directement dans la fenêtre de contexte.
Pire encore, ces informations peuvent ensuite être transportées aux tours suivants.
Context Mode cherche à éviter cela en gardant les données brutes volumineuses hors du contexte LLM actif et en ne ramenant que les parties réellement utiles à l’agent.
Comment fonctionne Context Mode
Context Mode s’exécute comme un serveur MCP et fournit des outils en bac à sable pour des opérations qui génèrent normalement des sorties volumineuses.
Les informations brutes peuvent être stockées localement dans un index de recherche basé sur FTS5, afin que l’agent puisse y revenir sans réinjecter l’intégralité du résultat dans la conversation.
Dans un exemple du projet, 315 Ko de sortie brute ont été réduits à 5,4 Ko de contexte, soit une réduction de 98 %.
Il s’agit d’un exemple issu de la charge du projet, pas d’une garantie pour chaque appel d’outil.
Premiers pas avec Context Mode
Avec Claude Code, le plus simple est de passer par la marketplace des plugins :
/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-modePropulsé par
Redémarrez Claude Code, puis vérifiez la configuration :
et l’enregistrer comme serveur MCP dans des clients compatibles comme Cursor, Gemini CLI, GitHub Copilot CLI, JetBrains, etc.
Une fois en marche, vous pouvez consulter les économies de contexte via ses outils de statistiques.
Context Mode est particulièrement utile pour des agents longs et très outillés, où les résultats navigateur, logs, lectures de fichiers, réponses MCP et autres données intermédiaires risquent sinon de saturer la fenêtre de contexte.
Comparer les quatre outils d’économie de jetons
Ces quatre outils ciblent différentes étapes du workflow d’un agent de code, de ce que l’agent écrit à la quantité de sortie d’outils qu’il conserve en contexte.
Outil
Problème principal
Ce qu’il réduit
Idéal pour
Résultat annoncé par le projet
Caveman
Réponses verbeuses de l’agent
Sortie de l’agent et, avec le proxy optionnel, contexte d’entrée répété
Agents de code trop bavards
Jusqu’à 65 % de jetons de sortie en moins dans son benchmark de compétence
Ponytail
Solutions sur‑ingénierées
Code, abstractions et travail agent inutile
Agents de code qui génèrent plus que nécessaire
54 % de code en moins et 22 % de jetons en moins dans son benchmark
RTK
Sortie terminal bruyante
Commandes shell, sortie Git, tests, logs et recherches
Workflows d’agents de code très orientés CLI
60 à 90 % de jetons en moins sur la sortie des commandes prises en charge
Context Mode
Pollution du contexte
Grosses sorties MCP et d’outils injectées dans le contexte actif
Agents de code longs et très outillés
315 Ko → 5,4 Ko, soit 98 % de contexte en moins dans un exemple documenté
La façon la plus simple de retenir la différence :
Caveman réduit ce que l’agent dit
Ponytail réduit ce qu’il construit
RTK réduit ce que renvoie le terminal
Context Mode réduit ce que les résultats d’outils conservent dans le contexte
Peut-on utiliser ces outils ensemble ?
Oui, mais je ne superposerais pas tout dès le départ.
Une meilleure approche consiste à commencer par Ponytail.
Il est simple à ajouter aux agents de code et, pour de nombreux workflows, réduire le code inutile suffit déjà. Je l’utilise avec des outils comme Zcode, Claude Code et Codex, et je suis satisfait des gains obtenus.
Pour aller plus loin, essayez Ponytail + Caveman. Ponytail réduit le code superflu, Caveman réduit l’explication superflue : ils se complètent bien.
Si votre workflow produit encore beaucoup de sorties lourdes en jetons (tests, logs, Git, commandes terminal), essayez Ponytail + Caveman + RTK.
Si RTK ne correspond pas à votre usage, notamment si vous utilisez beaucoup d’outils MCP, d’outils navigateur, d’API ou d’autres sorties d’outils volumineuses, essayez plutôt Ponytail + Caveman + Context Mode.
Il n’existe pas de combinaison parfaite pour tout le monde.
L’objectif est d’expérimenter et de trouver la configuration qui vous offre moins de jetons consommés sans dégrader les performances de votre agent. Pour certains, Ponytail seul suffira. Pour d’autres, la combinaison de deux ou trois outils fonctionnera mieux.
Autres moyens de réduire l’usage et le coût des jetons
Vous n’avez pas toujours besoin d’un nouvel outil.
Claude Code intègre déjà plusieurs fonctions pour garder un contexte plus léger et réduire les dépenses inutiles.
Désactivez la mémoire quand vous n’en avez pas besoin
Claude Code peut stocker et recharger automatiquement des mémoires de sessions précédentes. Pour des tâches courtes ou isolées, cela peut ajouter un contexte superflu.
De là, vous pouvez désactiver l’auto‑mémoire ou supprimer des informations devenues inutiles.
Compactez les longues sessions
Au fil d’une session, Claude transporte l’historique, le contenu des fichiers et les sorties d’outils. Claude Code compacte automatiquement, mais vous pouvez l’anticiper :
Vous repartez ainsi avec un contexte vide au lieu de transporter du travail sans rapport. Anthropic souligne aussi que repartir de zéro peut parfois mieux marcher que de compacter une session très longue à répétition.
Désactivez les serveurs MCP inutilisés
Les outils MCP consomment eux aussi du contexte. Claude Code diffère désormais les schémas MCP complets par défaut, mais des serveurs non utilisés peuvent encore ajouter de la charge.
Utilisez : /mcp pour passer en revue vos serveurs connectés et désactiver ceux dont vous n’avez pas besoin actuellement.
Vous pouvez aussi exécuter /context pour voir l’espace occupé par les différentes parties de la session.
Gardez CLAUDE.md léger
CLAUDE.md est chargé dans le contexte de Claude ; évitez d’en faire un manuel géant du projet.
Conservez uniquement les consignes réellement indispensables au fil des tâches : conventions importantes, commandes et règles du projet.
Utilisez /context pour vérifier l’espace pris par vos mémoires et fichiers d’instructions. Pour des règles propres à certains dossiers, Claude Code permet des règles ciblées plutôt que de tout placer dans le CLAUDE.md principal.
Utilisez un modèle moins coûteux pour les tâches simples
Vous n’avez probablement pas besoin du modèle le plus cher pour chaque modification.
La documentation de Claude Code recommande Sonnet pour la plupart des tâches de code, en réservant Opus aux travaux plus architecturaux ou très exigeants en raisonnement.
Pour des sous‑agents dédiés à des tâches simples, vous pouvez également les configurer sur Haiku.
Pour conclure
L’un des grands atouts de ces outils, c’est le peu d’effort requis une fois en place.
Selon l’outil, vous n’avez pas besoin de retenir une commande slash ni de l’activer manuellement pour chaque tâche.
Ponytail peut guider l’agent vers des implémentations plus simples, Caveman garder les réponses concises, RTK compresser la sortie du terminal et Context Mode empêcher les gros résultats d’outils d’inonder le contexte actif.
Après configuration, une grande partie de cette optimisation se fait dans le cours normal de votre travail de développement.
Vous en verrez souvent l’effet dans le récapitulatif d’exécution de l’agent, le code généré, la sortie du terminal ou les statistiques de contexte.
L’agent accomplira le même travail, mais avec moins de code inutile, moins de narration, des sorties d’outils plus petites et moins d’informations transportées d’une étape à l’autre.
Le mieux, c’est que vous pouvez aussi combiner ces outils.
Cependant, empiler les quatre n’assure pas automatiquement la consommation minimale. Ils ciblent des parties différentes du workflow agentique, et le bénéfice dépend fortement de votre agent, du modèle, du dépôt et des tâches exécutées.
Je vous recommande de les tester dans votre propre harnais de code. Commencez par un outil, mesurez la différence, puis ajoutez‑en un autre si vous voyez encore des sources évidentes de gaspillage de jetons.
Vous constaterez peut‑être qu’un seul outil suffit, alors qu’une autre configuration profitera de deux ou trois en synergie.
Personnellement, j’utilise Ponytail sur la plupart de mes workflows de code, car il est simple à configurer et l’agent comprend vite comment travailler avec.
Je l’emploie surtout avec Zcode by Z.ai, où il aide à garder les implémentations ciblées sans changer ma manière de prompt l’agent.
Au fond, réduire l’usage de jetons ne consiste pas à forcer un agent à faire moins de travail utile. Il s’agit d’éliminer le gaspillage autour de ce travail.
Essayez Caveman, Ponytail, RTK et Context Mode séparément et en combinaison, mesurez l’impact dans votre propre workflow, et gardez la configuration qui vous donne le meilleur équilibre entre consommation de jetons, qualité du code et performances de l’agent.
Qu’est-ce que le prompt caching, et est-ce que cela réduit les coûts en jetons pour les agents de code ?⌄
Le prompt caching est une fonctionnalité native d’API (disponible sur des modèles comme Claude, Sonnet et Gemini Pro) qui met temporairement en cache des contextes fréquemment utilisés, tels que des instructions système, de la documentation d’API et la structure d’un dépôt. Au lieu de retraiter toute la base de code à chaque tour de boucle agentique, le modèle réutilise le contexte mis en cache. Cela peut réduire les coûts en jetons d’entrée jusqu’à 90 % et accélérer nettement les réponses lors de longues sessions de développement.
Pourquoi les jetons de sortie sont-ils nettement plus chers que les jetons d’entrée ?⌄
Quand vous consultez la tarification API des LLM, les jetons de sortie coûtent typiquement 3 à 5 fois plus que les jetons d’entrée. Lire le contexte d’entrée est hautement parallélisable et donc moins coûteux en calcul. Générer une sortie, en revanche, est séquentiel : le modèle doit effectuer un passage complet pour prédire et produire chaque jeton. Les outils qui empêchent les agents d’écrire du code superflu ou des explications verbeuses réduisent directement cette génération de sortie, très onéreuse.
En quoi les limites de jetons des abonnements fixes diffèrent‑elles de l’usage via API ?⌄
Les abonnements fixes pour le code assisté par IA (comme Cursor Pro ou GitHub Copilot) offrent généralement un quota mensuel de requêtes sur des modèles « rapides » ou premium. Comme les workflows agentiques bouclent plusieurs fois par invite pour lire des fichiers et exécuter des tests, une seule requête de votre part peut consommer 10 à 20 requêtes agent en arrière‑plan, épuisant rapidement le quota mensuel. La facturation à l’API (Bring Your Own Key) supprime ce plafond de requêtes et facture strictement au jeton, rendant essentiels les outils de réduction de jetons pour éviter les coûts incontrôlés.
Le filtrage des logs de terminal et du contexte d’outils peut‑il masquer des bugs à l’IA ?⌄
Oui, si c’est appliqué trop agressivement. Les outils qui tronquent le bruit du terminal ou restreignent le contexte d’outils se basent sur une compression avec perte. Si un agent enquête sur un bug profondément imbriqué, un filtrage trop fort peut masquer la ligne de stack trace précise, un avertissement de dépendance caché, ou un code d’échec silencieux nécessaire au diagnostic. Pour limiter ce risque, appliquez une compression forte aux sorties notoirement bruyantes (comme l’installation de paquets), tout en autorisant la sortie brute pour le débogage d’erreurs directes.
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
Si vous avez déjà atteint la limite de jetons de votre offre d’agent IA après seulement quelques requêtes, vous vous êtes sans doute demandé où tous ces jetons étaient passés.
Vous demandez à l’agent de corriger un bug, de refactorer une fonctionnalité ou d’inspecter un dépôt, et soudain une grande partie de votre quota part en fumée.
Ce n’est pas nécessairement un problème lié à votre fournisseur ou à votre abonnement.
Les agents IA pour le code consomment tout simplement bien plus de jetons que les chatbots classiques. Ils ne se contentent pas de répondre à votre invite. Ils lisent des fichiers, recherchent dans la base de code, inspectent des logs, exécutent des tests, appellent des outils, génèrent du code, relisent leurs propres modifications, et répètent ces étapes plusieurs fois avant de terminer une tâche.
La bonne nouvelle : vous pouvez réduire une grande partie de cette consommation inutile de jetons.
Il existe des outils qui rendent les agents moins bavards, évitent la sur‑ingénierie des tâches simples, compressent le bruit du terminal et empêchent les réponses volumineuses d’outils de saturer la fenêtre de contexte.
Dans ce guide, nous allons voir quatre outils pour réduire l’usage de jetons avec des agents de code : Caveman, Ponytail, RTK et Context Mode.
Nous verrons le rôle de chacun, comment les configurer, et comment les combiner pour accomplir davantage avec des abonnements comme Claude Code et Codex avant d’atteindre vos limites d’usage.
Pourquoi les workflows agentiques utilisent-ils autant de jetons ?
Un chatbot classique prend une invite et renvoie une réponse. Un agent fait généralement bien plus.
Il peut lire des fichiers, appeler des outils, inspecter des logs, récupérer des documents, écrire du code, et répéter ce processus plusieurs fois avant de finir.
Chaque étape ajoute des informations au contexte, et une grande partie de ce contexte est renvoyée au modèle lors des appels suivants.
Voici une boucle d’agent simplifiée :
La requête est envoyée au modèle, le modèle appelle un outil, l’outil renvoie un résultat, et ce résultat est réinjecté dans le contexte avant l’étape suivante. La flèche de rétroaction, c’est là que se trouve le coût : à chaque passage, on transporte l’historique précédent. Ainsi, une tâche qui nécessite six appels d’outils renverra une grande partie de cet historique au modèle six fois.
Cela engendre plusieurs sources classiques de gaspillage de jetons :
Le vrai défi ne porte donc pas seulement sur le nombre de jetons qu’un agent génère, mais sur le nombre qu’il lit, propage et retraitre au fil du workflow.
C’est précisément ce que des outils comme Caveman, Ponytail, RTK et Context Mode cherchent à réduire, chacun ciblant une source différente de gaspillage de jetons.
1. Caveman : faire parler votre agent moins
Caveman est une façon simple de rendre les agents de code plus concis.
Au lieu de laisser l’agent narrer chaque étape, répéter l’évidence ou ajouter du remplissage, il oriente les réponses vers l’information qui compte vraiment.
C’est particulièrement utile pour les longues sessions de code, où des réponses verbeuses augmentent non seulement les jetons de sortie.
Elles finissent aussi dans l’historique de la conversation et sont réutilisées aux tours suivants.
Comment fonctionne Caveman
Caveman comporte deux volets distincts.
La compétence Caveman change la manière d’écrire de l’agent.
Elle supprime le remplissage, les politesses, les précautions de langage et la narration superflue, tout en laissant intacts les éléments importants comme les blocs de code, commandes, noms d’API et messages d’erreur exacts.
Elle assouplit aussi le style concis lorsque la clarté prime, par exemple pour des avertissements de sécurité ou des actions irréversibles.
Il existe aussi un proxy local optionnel qui s’attaque à l’autre versant du problème : ce que l’agent lit.
Il se place entre l’agent et le fournisseur de modèle et compresse le contexte éligible avant l’envoi de la requête.
La compétence et le proxy fonctionnent indépendamment : vous pouvez commencer par la compétence, légère, puis ajouter le proxy si vous avez besoin d’une réduction plus agressive du contexte.
Voici une manière simple de le visualiser, illustrée ci‑dessous :
À gauche, l’agent encadre son code d’un préambule puis le réexplique après coup. À droite, vous obtenez la réponse utile et le code, rien de plus. Même travail, bien moins de jetons dépensés en narration.
Premiers pas avec Caveman
Le plus simple pour installer la compétence :
Puis activez‑la dans votre agent de code :
Vous pouvez revenir aux réponses normales avec :
Caveman propose aussi des options d’installation natives pour des outils comme Claude Code, Codex, Gemini CLI, Cursor et OpenCode.
Si vous souhaitez également réduire le contexte envoyé au modèle, installez le CLI :
Puis lancez un agent compatible via ce CLI, par exemple :
Cela démarre le proxy local de Caveman et fait transiter l’agent par sa couche de compression de contexte.
Pour la plupart, commencez par la compétence seule.
Elle est simple à ajouter, ne change pas votre manière de coder, et s’attaque directement à l’une des sources les plus simples de gaspillage : un agent qui en dit beaucoup trop.
2. Ponytail : éviter la sur‑ingénierie par l’agent
Ponytail cible un autre type de gaspillage : les agents qui écrivent plus de code que nécessaire.
Une demande simple peut parfois entraîner de nouvelles dépendances, des classes auxiliaires, des composants enveloppe et des configurations supplémentaires.
Ponytail cherche à éviter cela en orientant l’agent vers la plus petite solution sensée en premier.
Comment fonctionne Ponytail
Avant d’écrire du code, Ponytail fait passer l’agent par une courte échelle de décision :
À chaque barreau, l’agent a une chance de s’arrêter avant d’écrire quoi que ce soit de nouveau. Il n’atteint la dernière étape — écrire le minimum de code qui fonctionne — qu’une fois la bibliothèque standard, les fonctionnalités natives de la plateforme et les dépendances existantes écartées.
Par exemple, au lieu d’installer une bibliothèque de sélecteur de date et de construire un composant enveloppe, Ponytail peut décider que le navigateur propose déjà :
L’objectif n’est pas de raccourcir tout aveuglément.
Ponytail préserve explicitement la validation, la sécurité, l’accessibilité et la protection contre la perte de données.
L’idée est d’être économe sur l’implémentation, sans compromettre la justesse.
Dans son propre benchmark agentique, Ponytail a produit environ 54 % de code en moins et 22 % de jetons en moins sur 12 tâches de code, par rapport au même agent sans la compétence.
Un benchmark indépendant a également constaté des implémentations sensiblement plus petites, tout en notant que des réglages trop agressifs peuvent parfois rogner la robustesse sur des cas limites non explicités.
Premiers pas avec Ponytail
Avec Claude Code, ajoutez la place de marché :
Puis installez Ponytail :
Envoyez ces deux commandes séparément.
Une fois installé, vous pouvez régler l’intensité de la simplification :
fullest la valeur par défaut et constitue probablement le meilleur point de départ.liteconstruit toujours ce que vous demandez, mais signale des alternatives plus simples, tandis queultraapplique YAGNI de manière bien plus énergique.Vous pouvez aussi passer en revue une modification existante pour traquer une complexité inutile :
Ou auditer une base de code plus large :
Ponytail est particulièrement efficace avec les agents de code, car réduire le code inutile a un effet domino : l’agent écrit moins de jetons maintenant, produit des diffs plus petits et laisse moins de code à relire plus tard.
3. RTK : réduire le bruit des sorties d’outils
RTK, pour Rust Token Killer, cible une autre source de gaspillage : tout ce que votre agent récupère depuis le terminal.
Des commandes comme
git status, les exécutions de tests, les logs, les recherches et la sortie des gestionnaires de paquets peuvent renvoyer des centaines voire des milliers de lignes.La plupart de ces informations sont utiles pour un humain au terminal, mais un agent n’a souvent besoin que de l’essentiel.
RTK s’intercale entre la commande et l’agent et compresse la sortie avant qu’elle n’arrive au modèle.
Comment fonctionne RTK
RTK applique, selon la commande, du filtrage, du regroupement, de la troncation et de la déduplication pour enlever le bruit tout en conservant les informations utiles : erreurs, échecs, fichiers modifiés et résumés.
Par exemple :
Dans le flux normal, l’agent exécute pytest et lit chaque ligne imprimée, dont la plupart indiquent des tests réussis inutiles pour lui. Avec RTK au milieu, la même exécution revient avec les échecs et un résumé : l’agent lit quelques dizaines de lignes au lieu de plusieurs centaines.
Avec les agents pris en charge, RTK peut s’accrocher automatiquement aux appels shell. Une commande telle que :
peut être réécrite en coulisse en :
L’agent reçoit alors la sortie allégée, sans devoir appeler RTK explicitement à chaque fois.
RTK annonce environ 60 à 90 % de jetons en moins pour la sortie des commandes de développement courantes. Cela ne signifie pas que votre facture LLM totale baisse de 60 à 90 % : cela ne concerne que la sortie terminal compressée par RTK.
Premiers pas avec RTK
Sur macOS ou Linux, installez‑le avec Homebrew :
Ou via le script d’installation :
Puis vérifiez que vous avez le bon RTK :
La commande
rtk gainaffiche un tableau de bord d’économies de jetons. Ce contrôle est utile, car un autre projet non lié utilise aussi le nomrtk.Pour Claude Code, initialisez RTK globalement :
Pour Codex :
Et pour Gemini CLI :
RTK prend aussi en charge Cursor, OpenCode, Copilot, Cline, Windsurf et plusieurs autres agents de code.
Une fois configuré, continuez à utiliser vos commandes terminal habituelles.
RTK gère la compression en arrière‑plan, ce qui est particulièrement utile pour les agents qui passent beaucoup de temps à exécuter des tests, rechercher dans le code, inspecter des changements Git et lire des logs.
4. Context Mode : garder les grosses sorties d’outils hors du contexte
Context Mode se concentre sur ce qui se passe après que l’agent commence à utiliser des outils.
Une capture navigateur, une liste d’issues GitHub, une recherche de fichiers ou la sortie d’une grosse commande peuvent injecter un volume massif d’informations directement dans la fenêtre de contexte.
Pire encore, ces informations peuvent ensuite être transportées aux tours suivants.
Context Mode cherche à éviter cela en gardant les données brutes volumineuses hors du contexte LLM actif et en ne ramenant que les parties réellement utiles à l’agent.
Comment fonctionne Context Mode
Context Mode s’exécute comme un serveur MCP et fournit des outils en bac à sable pour des opérations qui génèrent normalement des sorties volumineuses.
Les informations brutes peuvent être stockées localement dans un index de recherche basé sur FTS5, afin que l’agent puisse y revenir sans réinjecter l’intégralité du résultat dans la conversation.
Dans un exemple du projet, 315 Ko de sortie brute ont été réduits à 5,4 Ko de contexte, soit une réduction de 98 %.
Il s’agit d’un exemple issu de la charge du projet, pas d’une garantie pour chaque appel d’outil.
Premiers pas avec Context Mode
Avec Claude Code, le plus simple est de passer par la marketplace des plugins :
Redémarrez Claude Code, puis vérifiez la configuration :
Le doctor vérifie le bon fonctionnement du plugin, des hooks, des runtimes et des composants de recherche locale.
Vous pouvez aussi installer Context Mode globalement :
et l’enregistrer comme serveur MCP dans des clients compatibles comme Cursor, Gemini CLI, GitHub Copilot CLI, JetBrains, etc.
Une fois en marche, vous pouvez consulter les économies de contexte via ses outils de statistiques.
Context Mode est particulièrement utile pour des agents longs et très outillés, où les résultats navigateur, logs, lectures de fichiers, réponses MCP et autres données intermédiaires risquent sinon de saturer la fenêtre de contexte.
Comparer les quatre outils d’économie de jetons
Ces quatre outils ciblent différentes étapes du workflow d’un agent de code, de ce que l’agent écrit à la quantité de sortie d’outils qu’il conserve en contexte.
Outil
Problème principal
Ce qu’il réduit
Idéal pour
Résultat annoncé par le projet
Caveman
Réponses verbeuses de l’agent
Sortie de l’agent et, avec le proxy optionnel, contexte d’entrée répété
Agents de code trop bavards
Jusqu’à 65 % de jetons de sortie en moins dans son benchmark de compétence
Ponytail
Solutions sur‑ingénierées
Code, abstractions et travail agent inutile
Agents de code qui génèrent plus que nécessaire
54 % de code en moins et 22 % de jetons en moins dans son benchmark
RTK
Sortie terminal bruyante
Commandes shell, sortie Git, tests, logs et recherches
Workflows d’agents de code très orientés CLI
60 à 90 % de jetons en moins sur la sortie des commandes prises en charge
Context Mode
Pollution du contexte
Grosses sorties MCP et d’outils injectées dans le contexte actif
Agents de code longs et très outillés
315 Ko → 5,4 Ko, soit 98 % de contexte en moins dans un exemple documenté
La façon la plus simple de retenir la différence :
Peut-on utiliser ces outils ensemble ?
Oui, mais je ne superposerais pas tout dès le départ.
Une meilleure approche consiste à commencer par Ponytail.
Il est simple à ajouter aux agents de code et, pour de nombreux workflows, réduire le code inutile suffit déjà. Je l’utilise avec des outils comme Zcode, Claude Code et Codex, et je suis satisfait des gains obtenus.
Pour aller plus loin, essayez Ponytail + Caveman. Ponytail réduit le code superflu, Caveman réduit l’explication superflue : ils se complètent bien.
Si votre workflow produit encore beaucoup de sorties lourdes en jetons (tests, logs, Git, commandes terminal), essayez Ponytail + Caveman + RTK.
Si RTK ne correspond pas à votre usage, notamment si vous utilisez beaucoup d’outils MCP, d’outils navigateur, d’API ou d’autres sorties d’outils volumineuses, essayez plutôt Ponytail + Caveman + Context Mode.
Il n’existe pas de combinaison parfaite pour tout le monde.
L’objectif est d’expérimenter et de trouver la configuration qui vous offre moins de jetons consommés sans dégrader les performances de votre agent. Pour certains, Ponytail seul suffira. Pour d’autres, la combinaison de deux ou trois outils fonctionnera mieux.
Autres moyens de réduire l’usage et le coût des jetons
Vous n’avez pas toujours besoin d’un nouvel outil.
Claude Code intègre déjà plusieurs fonctions pour garder un contexte plus léger et réduire les dépenses inutiles.
Désactivez la mémoire quand vous n’en avez pas besoin
Claude Code peut stocker et recharger automatiquement des mémoires de sessions précédentes. Pour des tâches courtes ou isolées, cela peut ajouter un contexte superflu.
Exécutez :
De là, vous pouvez désactiver l’auto‑mémoire ou supprimer des informations devenues inutiles.
Compactez les longues sessions
Au fil d’une session, Claude transporte l’historique, le contenu des fichiers et les sorties d’outils. Claude Code compacte automatiquement, mais vous pouvez l’anticiper :
Vous pouvez aussi indiquer ce qui compte :
C’est particulièrement utile quand vous avez fini une partie de la tâche mais souhaitez poursuivre dans la même session.
Repartez de zéro lorsque la tâche change
Parfois, compacter n’en vaut pas la peine. Si vous passez à une tâche complètement différente, exécutez :
Vous repartez ainsi avec un contexte vide au lieu de transporter du travail sans rapport. Anthropic souligne aussi que repartir de zéro peut parfois mieux marcher que de compacter une session très longue à répétition.
Désactivez les serveurs MCP inutilisés
Les outils MCP consomment eux aussi du contexte. Claude Code diffère désormais les schémas MCP complets par défaut, mais des serveurs non utilisés peuvent encore ajouter de la charge.
Utilisez :
/mcppour passer en revue vos serveurs connectés et désactiver ceux dont vous n’avez pas besoin actuellement.Vous pouvez aussi exécuter
/contextpour voir l’espace occupé par les différentes parties de la session.Gardez CLAUDE.md léger
CLAUDE.mdest chargé dans le contexte de Claude ; évitez d’en faire un manuel géant du projet.Conservez uniquement les consignes réellement indispensables au fil des tâches : conventions importantes, commandes et règles du projet.
Utilisez
/contextpour vérifier l’espace pris par vos mémoires et fichiers d’instructions. Pour des règles propres à certains dossiers, Claude Code permet des règles ciblées plutôt que de tout placer dans leCLAUDE.mdprincipal.Utilisez un modèle moins coûteux pour les tâches simples
Vous n’avez probablement pas besoin du modèle le plus cher pour chaque modification.
La documentation de Claude Code recommande Sonnet pour la plupart des tâches de code, en réservant Opus aux travaux plus architecturaux ou très exigeants en raisonnement.
Vous pouvez basculer avec :
Pour des sous‑agents dédiés à des tâches simples, vous pouvez également les configurer sur Haiku.
Pour conclure
L’un des grands atouts de ces outils, c’est le peu d’effort requis une fois en place.
Selon l’outil, vous n’avez pas besoin de retenir une commande slash ni de l’activer manuellement pour chaque tâche.
Ponytail peut guider l’agent vers des implémentations plus simples, Caveman garder les réponses concises, RTK compresser la sortie du terminal et Context Mode empêcher les gros résultats d’outils d’inonder le contexte actif.
Après configuration, une grande partie de cette optimisation se fait dans le cours normal de votre travail de développement.
Vous en verrez souvent l’effet dans le récapitulatif d’exécution de l’agent, le code généré, la sortie du terminal ou les statistiques de contexte.
L’agent accomplira le même travail, mais avec moins de code inutile, moins de narration, des sorties d’outils plus petites et moins d’informations transportées d’une étape à l’autre.
Le mieux, c’est que vous pouvez aussi combiner ces outils.
Cependant, empiler les quatre n’assure pas automatiquement la consommation minimale. Ils ciblent des parties différentes du workflow agentique, et le bénéfice dépend fortement de votre agent, du modèle, du dépôt et des tâches exécutées.
Je vous recommande de les tester dans votre propre harnais de code. Commencez par un outil, mesurez la différence, puis ajoutez‑en un autre si vous voyez encore des sources évidentes de gaspillage de jetons.
Vous constaterez peut‑être qu’un seul outil suffit, alors qu’une autre configuration profitera de deux ou trois en synergie.
Personnellement, j’utilise Ponytail sur la plupart de mes workflows de code, car il est simple à configurer et l’agent comprend vite comment travailler avec.
Je l’emploie surtout avec Zcode by Z.ai, où il aide à garder les implémentations ciblées sans changer ma manière de prompt l’agent.
Au fond, réduire l’usage de jetons ne consiste pas à forcer un agent à faire moins de travail utile. Il s’agit d’éliminer le gaspillage autour de ce travail.
Essayez Caveman, Ponytail, RTK et Context Mode séparément et en combinaison, mesurez l’impact dans votre propre workflow, et gardez la configuration qui vous donne le meilleur équilibre entre consommation de jetons, qualité du code et performances de l’agent.
Pour approfondir le fonctionnement des agents IA, nous vous recommandons le parcours de compétences AI Agent Fundamentals.