Comment réduire l'utilisation des tokens de Claude Code ?
On réduit les tokens de Claude Code en ciblant les quatre sources qui dominent réellement le coût : les lectures de fichiers entiers par défaut, les sorties de commandes brutes déversées dans le transcript, le manifeste des outils MCP renvoyé à chaque tour, et une conversation qui s'allonge et refacture chaque lecture passée. Serrer chacune de ces sources fait chuter le coût — sans perte de qualité, car on élague le bruit, pas le signal. Cet article est le pendant spécifique à Claude Code de Comment réduire l'utilisation des tokens d'un agent de codage IA. Pour une vue agent-agnostique, commencez par là. Ici, nous appliquons les mêmes leviers aux comportements concrets de Claude Code : comment il lit les fichiers, quelles commandes il tend à exécuter, comment le transcript grossit, et ce que fait réellement la commande/compact.
Pourquoi Claude Code brûle-t-il autant de tokens ?
Claude Code brûle des tokens principalement parce qu'il lit plus que nécessaire, puis relit à chaque tour suivant. La cause profonde est architecturale : à chaque étape d'une boucle agentique, Claude relit l'intégralité de l'historique de conversation et les résultats des outils. Toute lecture surdimensionnée effectuée tôt est donc payée à nouveau à chaque tour qui suit. Quatre patterns spécifiques génèrent l'essentiel de la facture : Lectures de fichiers entiers par défaut. Lorsqu'on lui demande de « comprendre » un module, Claude Code lit le fichier en entier. Un fichier TypeScript de 500 lignes représente environ 5 000 à 7 000 tokens — et Claude Code peut lire une douzaine de fichiers avant d'écrire une seule ligne de code. Si le context window transporte ces lectures pendant 20 tours, vous avez payé chacune d'elles 20 fois. Sorties d'outils non filtrées. Claude Code exécute des commandes shell —git status, npm test, tsc --noEmit, outils de build — et la sortie brute s'écoule directement dans le transcript. Un npm test en échec peut émettre 15 000 tokens de stack traces, coches de tests réussis et tableaux de timing. Claude Code en avait besoin de 50 environ : le nom du test en échec et l'assertion cassée. Le reste est du cargo.
Le manifeste MCP. Chaque serveur MCP connecté annonce ses définitions d'outils à chaque tour, qu'un outil soit utilisé ou non. Cinq serveurs avec dix outils chacun représente une surcharge constante non négligeable qui s'accumule silencieusement sur toute la session. Voir MCP pour le fonctionnement du protocole et Les meilleurs serveurs MCP pour Claude Code pour les serveurs qui valent la peine d'être conservés.
Un transcript sans limite. Les sessions Claude Code qui s'étendent sur plusieurs tâches ou revisitent les mêmes fichiers répétitivement peuvent construire des transcripts qui coûtent plus cher à relire qu'à produire. Chaque nouveau tour paye le contexte de tous les tours précédents.
Identifier quel pattern domine votre flux de travail est la première étape. Consultez le compteur de tokens dans votre interface Claude.ai ou un tableau de bord d'utilisation — la réponse pointe généralement immédiatement vers le bon levier.
Quels sont les plus grands leviers spécifiques à Claude Code ?
Les plus grands leviers sont la récupération de fichiers, le output filtering et l'élagage MCP — à peu près dans cet ordre pour la plupart des sessions Claude Code.Faire chercher plutôt que lire à Claude Code
Le pattern par défaut — « liresrc/auth/login.ts » — donne à Claude un fichier entier alors qu'il n'avait besoin que d'une fonction. Le meilleur pattern consiste à orienter Claude Code vers le symbole précis : « trouve la fonction qui valide le JWT et montre-moi sa signature. » Quand la récupération fonctionne bien, Claude Code lit 2 000 tokens au lieu de 20 000.
En pratique, cela signifie :
- Demander à Claude Code de localiser d'abord le symbole pertinent, puis de lire le corps de cette fonction
- Éviter les formulations comme « lire le dépôt », « vérifier tous les fichiers dans X », « parcourir la base de code » — ce sont des instructions de lecture de fichiers à périmètre ouvert
- Lors du démarrage d'une nouvelle tâche dans un grand dépôt, décrire le comportement qu'on veut changer (« où gère-t-on les erreurs de connexion ») plutôt que les fichiers qu'on pense être concernés
Filtrer la sortie des commandes avant qu'elle entre dans le transcript
C'est souvent le changement unique le plus rentable pour les projets avec des suites de tests actives ou des pipelines de build. L'objectif est d'intercepter la sortie des outils entre le shell et le transcript, et de ne donner à Claude Code que ce dont il a besoin. Concrètement :- Préférer les options de commandes concises :
git status --porcelainplutôt que le simplegit status,jest --silentpour supprimer le bruit des tests réussis,tsc --noEmit 2>&1 | grep errorpour ne faire remonter que les erreurs de type - Pour les systèmes de build, ne capturer que les lignes d'erreur plutôt que le journal complet
- Pour les exécuteurs de tests, ne faire remonter que les tests en échec avec leur assertion, pas la sortie complète de l'exécuteur
Élaguer le manifeste MCP
Chaque serveur MCP connecté à Claude Code ajoute ses définitions d'outils au contexte de chaque tour, que vous appeliez ou non l'un de ses outils. Si vous avez constitué une configuration MCP riche au fil du temps — systèmes de fichiers, bases de données, API externes — la surcharge du manifeste peut être substantielle. Faites l'inventaire de ce que vous utilisez réellement par session et désactivez le reste temporairement. Les outils dont le binaire ou le service sous-jacent ne tourne pas sont particulièrement coûteux — leurs définitions sont payées mais les outils ne peuvent pas aboutir. Le chargement paresseux (n'annoncer les outils que lorsqu'ils sont pertinents) réduit le manifeste par tour aux seuls outils importants pour la tâche en cours.Gérer CLAUDE.md avec soin
CLAUDE.md est relu au début de chaque session et peut être injecté dans le contexte à chaque tour selon votre configuration. Un CLAUDE.md long et instable est doublement coûteux : il consomme des tokens et il annule le prompt caching, car les hits de cache nécessitent que le préfixe soit identique d'un tour à l'autre.
Limitez CLAUDE.md aux conventions durables du projet — commandes de build, règles de style de code, décisions d'architecture qui ne changent pas d'une semaine à l'autre. Supprimez les notes transitoires, les listes de tâches en cours et tout ce qui est spécifique à une session. Un CLAUDE.md concis et stable reste favorable au cache et recharge le cache à chaque session après la première.
Utiliser /compact et une bonne hygiène de session
La commande /compact de Claude Code compresse l'historique de conversation en remplaçant les tours précédents par un résumé. Elle est plus efficace lorsqu'on l'exécute entre des sous-tâches distinctes plutôt que de laisser le transcript complet s'accumuler indéfiniment.
Bonnes pratiques d'hygiène de session pour Claude Code :
- Démarrer une nouvelle session pour les tâches sans rapport. Continuer une longue session sur une nouvelle tâche transporte tout le contexte antérieur même quand il est hors de propos.
- Exécuter
/compactaux points de rupture naturels — après qu'une fonctionnalité est terminée, après une session de débogage, avant d'entamer un refactor. - Ne pas coller de gros fichiers ou de longs journaux directement dans le chat. Claude Code dispose d'outils fichiers ; utilisez-les de façon sélective plutôt que de précharger le contexte.
- Préférer des descriptions de tâches précises. « Corriger le test en échec dans
auth/login.test.ts» produit une récupération bien plus ciblée que « améliorer le système d'authentification » — et une récupération plus ciblée signifie une boucle plus courte.
Comment appliquer cela aujourd'hui
- Arrêter d'ouvrir des fichiers entiers. Orienter Claude Code vers la fonction ou le symbole dont vous avez besoin, pas le fichier qui le contient.
- Ajouter des options concises aux commandes que Claude Code exécute le plus :
--porcelain,--quiet,--silent,2>&1 | grep error. - Faire l'inventaire de vos serveurs MCP. Désactiver ceux que vous n'avez pas utilisés cette semaine ; les réactiver selon les besoins.
- Alléger
CLAUDE.mdaux règles qui ne changeront pas pendant des mois. Supprimer les notes transitoires. - Exécuter
/compactentre les sous-tâches, pas seulement quand l'avertissement de contexte apparaît. - Démarrer des sessions fraîches pour les tâches sans rapport avec ce sur quoi vous venez de travailler.
Ce qui va mal (anti-patterns)
« Lire tout le projet d'abord. » Cela ressemble à de la rigueur ; c'est en réalité une grenade à tokens. Claude Code précharge des dizaines de milliers de tokens qu'il va largement ignorer, et paye chacun d'eux à nouveau à chaque tour suivant. Laisser des journaux bruts dans le chat. Coller un build raté en verbatim — ou laisser Claude Code le déverser sans filtrage — peut coûter plus de tokens que la correction. Filtrer d'abord, puis laisser Claude Code voir la ligne d'erreur. Traiter l'optimisation des sorties comme la solution. Demander à Claude Code d'« être bref » réduit sa sortie (la partie bon marché). Dans la tarification de Claude, les output tokens coûtent environ 5× les input tokens, mais le volume de sortie est faible — ce sont les entrées qu'on continue d'injecter qui dominent. La direction coûteuse, c'est l'entrée. Une session sans fin pour tout faire. Un historique de conversation non borné refacture chaque lecture ancienne à chaque nouveau tour. Compacter ou redémarrer entre les tâches n'est pas un contournement — c'est une gestion correcte des sessions. Ignorer le manifeste MCP. Ajouter des serveurs MCP est facile ; le coût de chacun s'accumule invisiblement. Chaque définition d'outil est payée à chaque tour, que vous en ayez besoin ou non.Foire aux questions
Réduire les tokens détériore-t-il les réponses de Claude Code ?
Non — quand c'est fait correctement, elles s'améliorent. Les leviers décrits ici suppriment le contexte de faible valeur : sorties de commandes génériques, contenu de fichiers hors de propos, définitions d'outils inutilisés. Ils ne suppriment pas le signal sur lequel Claude Code raisonne. Étant donné que les modèles accordent le moins d'attention aux informations enfouies dans un context window surchargé, supprimer le bruit améliore le rapport signal/bruit. La seule façon de nuire à la qualité est de compresser quelque chose d'essentiel — c'est pourquoi les lectures structure-first conservent chaque signature de fonction, et les filtres de sortie conservent l'erreur réelle.Que fait réellement /compact ?
/compact remplace les premiers tours de l'historique de conversation de Claude Code par un résumé compressé, libérant ainsi le context window. Il préserve les faits pertinents à la tâche (ce qui a été construit, quelles erreurs ont été observées, les décisions prises) et abandonne les sorties d'outils et les lectures de fichiers verbatim qui les ont générés. L'exécuter de façon proactive entre les sous-tâches — plutôt que seulement quand l'avertissement de contexte se déclenche — signifie commencer chaque sous-tâche avec une base plus légère et moins coûteuse.
Quelle économie peut-on espérer ?
Cela dépend de votre mix de sessions. Les sessions à forte densité de navigation de fichiers et de cycles build/test — le pattern courant pour les fonctionnalités greenfield ou le débogage — ont le plus à gagner, car ce sont les activités les plus gourmandes en tokens. Les sessions où le modèle écrit principalement du nouveau code à partir d'une spec claire ont moins de marge, puisque la sortie est déjà la partie incompressible. L'approche honnête : mesurez votre baseline avec un compteur d'utilisation, appliquez les leviers qui correspondent à votre goulot d'étranglement, puis comparez.CLAUDE.md affecte-t-il le prompt caching ?
Oui, directement. Le prompt caching sur Claude nécessite que le préfixe soit identique d'un tour à l'autre pour obtenir un hit de cache, facturé à environ 10 % d'un token frais. UnCLAUDE.md qui change fréquemment — parce qu'il contient des notes en cours ou des rappels spécifiques à une tâche — annule le cache et est refacturé au prix plein à chaque session. Le garder stable et concis est à la fois une réduction directe des tokens et un multiplicateur de hits de cache. Voir prompt caching pour les mécanismes.
Ces techniques fonctionnent-elles aussi avec des outils comme Cursor ou Windsurf ?
Oui. Les mécanismes sont agent-agnostiques — tout agent facturé au token qui relit son transcript à chaque tour bénéficie des mêmes leviers. Le guide plus large couvre le tableau cross-agent, et context engineering va plus loin dans la discipline derrière ces patterns.À lire aussi :
- Comment réduire l'utilisation des tokens d'un agent de codage IA — le pilier cross-agent dont cet article est issu.
- Context engineering pour les agents de codage IA — la discipline derrière chaque levier ci-dessus.
- Les meilleurs serveurs MCP pour Claude Code — quels outils MCP valent la peine d'être conservés chargés.
- Les meilleurs optimiseurs de tokens Claude Code — une comparaison des options d'outillage.
- Coût en tokens des agents de codage IA — les chiffres de tarification derrière les calculs.
Up to 88% fewer tokens. Zero config.
Tokenade is the simplest way to cut what your coding agent sends to the model — set it up once, save on every prompt. Works with Claude Code, Cursor, Codex, Copilot & more.