Réduire sa consommation de tokens Claude : 6 correctifs

Personne ne budgète ses tokens. Puis un mois chargé arrive, la facture double, et soudain toute l'équipe devient experte en fenêtres de contexte. Nous avons audité assez de setups Claude Code pour connaître le schéma : la facture est rarement portée par le travail que vous avez demandé. Elle est portée par tout ce qui voyage avec.

Ce guide est le playbook que nous utilisons vraiment. Les correctifs sont classés par impact, ce qui signifie que les correctifs structurels ennuyeux viennent en premier et le plus amusant (le routage de modèles) en dernier, parce que c'est là que se trouve l'argent. Les prix ci-dessous sont les tarifs API à la mi-2026 : environ 3 $ par million de tokens d'entrée sur Sonnet, 5 $ sur Opus, 1 $ sur Haiku, les tokens de sortie coûtant environ cinq fois plus. Si vous êtes sur un abonnement Pro ou Max, vous payez en limites d'usage plutôt qu'en dollars, mais chaque correctif ci-dessous vous achète la même chose : plus de travail par session avant de heurter le mur.

Où partent réellement les tokens

Chaque requête que Claude Code envoie à l'API transporte l'intégralité de votre session en cours, plus un préambule fixe : le prompt système, votre CLAUDE.md, la description de chaque skill installé, et le schéma complet de chaque outil de chaque serveur MCP connecté. Ce préambule est facturé à chaque tour, que le tour l'utilise ou non.

Dans un setup mature, cela s'accumule vite. Les quatre postes de dépense que nous voyons le plus, dans l'ordre :

Le premier : les relectures de contexte. Un agent qui a lu votre fichier de configuration de 2 000 lignes hier le relit aujourd'hui, parce que les sessions ne se souviennent de rien. Multipliez par chaque fichier qu'il « vérifie au cas où » et la redécouverte devient une ligne de facture.

Le deuxième : les schémas d'outils MCP. Chaque serveur connecté injecte ses définitions d'outils dans chaque requête. Pas quand l'outil est utilisé. Toujours. Cinq serveurs peuvent représenter 15 000 à 25 000 tokens de schémas assis devant votre vraie question, toute la journée, tous les jours.

Le troisième : un CLAUDE.md obèse. Un fichier mémoire de 3 000 lignes, c'est environ 30 000 tokens taxés sur chaque requête de chaque session, pour toujours. La plupart de ces lignes concernent peut-être une session sur dix.

Le quatrième : la ré-explication. « Utilise les commits conventionnels. Ne touche pas au dossier legacy. On préfère pnpm. » Si vous tapez vos préférences dans le chat chaque matin, vous payez pour enseigner la même leçon quotidiennement, et la leçon voyage ensuite dans l'historique de session à chaque tour suivant.

Le cache de prompt adoucit tout cela. Le contexte stable répété est facturé environ un dixième du prix d'entrée normal. Mais les écritures en cache coûtent une prime, le contenu mis en cache occupe toujours votre fenêtre de contexte, et un seul octet modifié en haut du prompt invalide tout ce qui suit. Le cache est une remise, pas un correctif.

Mesurez avant d'optimiser

Deviner où fuient les tokens est un gaspillage en soi. Dix minutes de mesure vous disent lequel des six correctifs ci-dessous compte vraiment pour votre setup.

Dans Claude Code, /cost montre ce que la session en cours a dépensé, et /context montre ce qui occupe la fenêtre en ce moment, détaillé par prompt système, outils, fichiers mémoire et messages. Ce second est le miroir honnête : si les schémas d'outils et CLAUDE.md prennent 40 000 tokens avant que vous n'ayez rien tapé, vous avez trouvé votre problème.

Pour l'historique, l'outil communautaire ccusage lit les fichiers de transcription que Claude Code garde déjà sur disque et vous donne des ventilations par jour et par modèle. Les utilisateurs API voient la même chose dans la page d'usage de la console Anthropic, par clé. Et si vous voulez savoir ce que coûte un fichier précis, l'endpoint count_tokens de l'API donne un chiffre exact ; y passer votre CLAUDE.md est un dégrisement de trente secondes.

Établissez une semaine de référence avant de changer quoi que ce soit. Chaque affirmation que nous faisons sur nos propres chiffres ci-dessous vient d'avoir fait exactement cela, et le skill Token Budget Auditor existe pour automatiser tout l'exercice (nous y revenons au correctif 6).

Correctif 1 : remplacez les prompts répétés par des skills

C'est le changement au meilleur levier pour la plupart des gens, et il fonctionne grâce à une décision de conception : la divulgation progressive. Les instructions complètes d'un skill ne se chargent que lorsque le skill se déclenche. Le seul coût payé à chaque requête est sa description de déclenchement, en général 30 à 60 tokens. Si le format est nouveau pour vous, notre explication des skills Claude en couvre la mécanique.

Faites le calcul sur un prompt que vous collez quotidiennement. Disons 2 000 mots, environ 2 600 tokens : vos règles de style, votre checklist de revue, ce que vous gardez dans une note et collez chaque matin. Une fois collé, il siège dans l'historique de session et est renvoyé à chaque tour. À 30 tours par session, ce seul bloc génère environ 78 000 tokens d'entrée par session. Sur 22 jours ouvrés, environ 1,7 million de tokens par mois. Sur Sonnet, autour de 5 $ sans cache, disons 1 à 2 $ avec de bons taux de cache.

En skill, le même contenu coûte sa description de 50 tokens par tour, environ 33 000 tokens par mois, plus le corps complet de 2 600 tokens uniquement dans les sessions où il se déclenche réellement. Comptez une réduction de 95 à 98 % pour ce bloc.

Cinq dollars par mois ne semblent rien jusqu'à ce que vous vous rappeliez deux choses. Personne n'a un seul prompt collé ; les setups que nous auditons en ont cinq à dix. Et le coût en dollars n'est même pas le principal dégât : ces tokens occupent du contexte, ce qui pousse les longues sessions vers la compaction plus tôt, ce qui déclenche des relectures, qui coûtent plus cher que le prompt lui-même. Convertir les prompts collés en skills est le changement au meilleur rapport effort/économies que nous connaissions.

Correctif 2 : mettez CLAUDE.md au régime

CLAUDE.md est du contexte toujours actif. C'est toute sa valeur et tout son coût. Le test pour chaque ligne est simple : s'applique-t-elle à la plupart des sessions de ce projet ?

A sa place dans CLAUDE.md : les commandes de build et de test, l'organisation du dépôt, les trois contraintes non évidentes qui cassent des choses quand on les viole, les règles dures comme « ne jamais commiter directement sur main ». Cela fait typiquement 30 à 60 lignes.

N'a pas sa place : les instructions de workflow pour des tâches hebdomadaires (c'est un skill), les guides de style pour du travail occasionnel comme la documentation ou les migrations (skill), les longues explications d'architecture que Claude peut lire dans le code, et tout ce que vous avez copié « au cas où ». Si une section concerne moins de la moitié de vos sessions, elle paie un loyer permanent pour un travail à temps partiel. Déplacez-la vers un skill et elle ne coûte rien jusqu'au jour où elle devient pertinente.

Nous continuons de voir des CLAUDE.md de plus de 2 000 lignes, et leurs propriétaires sont généralement surpris deux fois : d'abord par le compte de tokens (passez-le dans count_tokens), puis par la découverte que l'alléger a rendu Claude plus obéissant, pas moins. Les instructions se disputent l'attention. Quarante lignes nettes battent deux mille lignes molles.

Correctif 3 : élaguez les serveurs MCP que vous n'utilisez pas

Les serveurs MCP sont le poste de dépense le plus discret parce que le coût est invisible à l'usage. Connecter un serveur signifie que ses schémas d'outils sont sérialisés dans chaque requête. Un serveur typique expose 10 à 30 outils à quelques centaines de tokens de schéma chacun ; les gros serveurs officiels font pire. Quand nous avons mesuré notre propre setup, un serveur populaire ajoutait à lui seul environ 20 000 tokens par requête, et nous l'avions utilisé deux fois dans le mois.

Lancez claude mcp list et soyez impitoyable. Pour chaque serveur, demandez-vous quand vous l'avez réellement utilisé pour la dernière fois. Notre règle après avoir fait cet exercice sur nos propres machines : deux serveurs par projet suffisent largement, et ils devraient être limités aux projets qui en ont besoin plutôt que configurés globalement. Un serveur de base de données n'a rien à faire à taxer vos sessions de rédaction de blog.

Reconsidérez aussi si chaque serveur restant doit vraiment être un serveur. Beaucoup de connexions MCP existent pour envelopper une CLI que Claude pourrait simplement exécuter via bash, sans coût permanent. Nous avons rédigé le cadre de décision complet dans skills vs MCP, mais la version courte : MCP mérite sa taxe de schémas quand vous avez besoin d'un accès authentifié en direct à un système externe. Pour les instructions, les workflows et tout ce qui est orienté fichiers, un skill fait le travail sans le loyer par requête.

L'élagage est aussi le rare correctif instantané. Pas de refactoring, pas de migration. Retirez trois serveurs inactifs et votre toute prochaine requête est allégée de 30 000 tokens.

Correctif 4 : des habitudes de session qui gardent le contexte petit

La structure règle les coûts fixes. Les habitudes règlent les coûts variables.

Ouvrez une session fraîche par tâche. Une session immortelle qui erre d'une correction de bug à un refactoring puis à « mets aussi à jour le README » traîne tout le contexte du bug dans chaque tour consacré au README. L'historique est renvoyé à chaque requête, donc les tours d'une longue session deviennent progressivement plus chers. Quand le sujet change, /clear ou une nouvelle session est presque toujours moins cher que de continuer, et la qualité de sortie s'améliore généralement aussi, parce qu'un contexte périmé égare plus qu'il n'aide.

Utilisez /compact aux frontières naturelles, pas à la dernière minute. Claude Code compacte automatiquement quand la fenêtre se remplit, mais à ce moment-là vous payez déjà plein tarif sur un historique gonflé depuis une heure. Compacter juste après un jalon (« les tests passent, prochaine fonctionnalité ») réduit l'historique pendant que vous contrôlez ce qui vaut d'être gardé. La compaction coûte une passe de résumé ; transporter du poids mort coûte à chaque tour.

Cadrez vos demandes. « Trouve où on valide les e-mails et corrige la regex » envoie Claude en expédition grep à travers une douzaine de fichiers, chacun lu dans le contexte et facturé pour le reste de la session. Si vous savez que c'est dans src/lib/validators.ts, dites-le. Dix secondes de précision économisent régulièrement 50 000 tokens d'exploration. Même logique pour les lectures : pointer Claude vers une plage de lignes vaut mieux que le laisser ingérer un fichier de 2 000 lignes pour en utiliser 40.

Rien de tout cela n'exige de discipline au-delà de l'observation. Surveillez /context pendant une journée et les schémas de gaspillage s'identifient d'eux-mêmes.

Correctif 5 : routez les sous-tâches bon marché vers des modèles moins chers

Oui, le routage de modèles fait économiser de l'argent. Nous le listons cinquième parce que dans chaque audit que nous avons mené, les équipes s'y précipitaient pendant qu'un CLAUDE.md obèse et six serveurs MCP inactifs brûlaient trois fois plus. La structure d'abord, le routage ensuite.

Cela dit, l'arithmétique est réelle : Haiku coûte un cinquième de Sonnet, lui-même un cinquième d'Opus. La façon propre de l'exploiter dans Claude Code, ce sont les sous-agents. Exploration, résumé d'un long fichier, génération de tests boilerplate, premiers jets de messages de commit : déléguez cela à un sous-agent Haiku pendant que la boucle principale reste sur votre modèle principal. L'architecture de Claude Code fait cela en interne pour certaines tâches de recherche, ce qui vous dit qu'Anthropic juge le schéma sain.

Ce que nous ne recommandons pas : basculer le modèle de la session principale en cours de tâche. Les caches de prompt sont par modèle, donc chaque bascule jette votre préfixe en cache et repaie plein tarif pour le reconstruire. Choisissez un modèle par session ; routez à la frontière des sous-agents. Et gardez le raisonnement difficile sur le modèle fort. Un modèle bon marché qui produit un mauvais plan coûte plus cher qu'un modèle coûteux qui a raison du premier coup. Nous avons mesuré cela aussi, hélas.

Correctif 6 : les skills d'efficacité en tokens que nous testons

Nous suivons une catégorie Efficacité en tokens dédiée, et nous la tenons à un standard plus strict que toute autre : un verdict doit s'accompagner d'une facture avant/après mesurée, pas de ressenti. Cela rend les verdicts plus lents. Voici l'état honnête des lieux.

Token Budget Auditor lit vos transcriptions et votre setup et nomme vos principaux gouffres à tokens : contexte système gonflé, lectures de fichiers redondantes, boucles d'outils bavardes. C'est l'étape « mesurer d'abord » empaquetée en skill. Verdict en attente ; nous menons une comparaison de facturation avant/après sur nos propres comptes avant de le noter.

Context Compression empaquette la discipline résumer-et-continuer du correctif 4, pour que les longues sessions se compactent en résumés structurés au lieu de traîner l'historique brut. Dans la file de test ; nous mesurons l'économie de tokens contre la perte d'information sur une semaine de sessions réelles, parce qu'une compression qui oublie vos contraintes est pire que pas de compression.

Prompt Cache Optimizer restructure le contexte pour plaire au cache : contenu stable d'abord, contenu volatil en dernier. Le gaspillage le plus courant qu'il cible est un timestamp interpolé en haut d'un prompt, qui invalide silencieusement le cache à chaque requête. Correctif d'une ligne, économies à deux chiffres quand il s'applique. Nous mesurons les taux de hit de cache en conditions réelles avant de rendre un verdict.

Le seul skill adjacent qui a passé les tests est Memory Management, noté 9,2/10 dans notre essai d'une semaine. Il vit dans notre catégorie productivité, mais c'est un pari sur les tokens dans l'âme : la mémoire persistante convertit la redécouverte répétée (le mode d'échec le plus coûteux du correctif 4) en une écriture et des rappels bon marché. Claude qui se souvient des décisions de votre projet, c'est Claude qui ne relit pas douze fichiers pour les reconstituer.

La liste complète, avec notes de test et verdicts existants, est sur meilleurs skills d'efficacité. Nous préférons vous montrer une file avec des mesures en cours plutôt qu'une page de scores assurés que nous ne pouvons pas étayer.

L'Optimizer Pack, si vous voulez le raccourci

Un paragraphe honnête sur notre propre produit. L'Optimizer Pack est la configuration d'efficacité que nous installerions sur nos propres machines : les trois skills d'efficacité ci-dessus plus Memory Management, préconfigurés, avec un modèle de CLAUDE.md allégé et une checklist d'audit MCP, installés en une commande. Il coûte 10 $, surtout parce qu'empaqueter et maintenir les configurations prend un vrai temps. Tout ce qu'il contient est aussi disponible gratuitement sur les pages de skills individuelles ; le pack vous épargne une soirée de réglages, rien de plus. Si le bricolage vous amuse, passez votre chemin.

Un avant/après réaliste

Voici une esquisse fondée sur un composite d'utilisateurs intensifs que nous avons audités : un développeur faisant tourner Claude Code plus de quatre heures par jour sur Sonnet via l'API, avec un CLAUDE.md de 2 500 lignes, cinq serveurs MCP et des sessions marathon.

Avant : environ 140 millions de tokens d'entrée et 4 millions de tokens de sortie par mois. Avec une performance de cache médiocre (le CLAUDE.md avait un en-tête dynamique, le cache fonctionnait donc à peine), on est dans les eaux de 480 $ par mois.

Après application des correctifs 1 à 5 : élaguer trois serveurs MCP et réduire CLAUDE.md à 60 lignes a coupé le préambule par requête d'environ 45 000 tokens. Convertir sept prompts collés en skills a retiré une autre tranche d'historique à chaque tour. Sessions fraîches et compaction plus précoce ont raccourci l'historique moyen d'un tiers. Corriger l'invalidateur de cache a permis au contexte stable restant d'être enfin facturé au tarif en cache. Router les sous-agents d'exploration vers Haiku a rogné le reste. Nouvelle facture : environ 210 $ par mois.

C'est une réduction de 55 % sans aucun changement dans ce qui a été construit. Vos chiffres différeront, et nous traiterions avec suspicion quiconque promet un pourcentage exact, nous y compris. Mais diviser à peu près par deux la facture d'un utilisateur intensif par la seule structure correspond à ce que nous avons observé plus d'une fois. Le schéma tient aussi sur les abonnements : la même personne a cessé de heurter les limites du plan Max en milieu d'après-midi.

FAQ

Tout cela compte-t-il si je suis sur un abonnement Pro ou Max plutôt que sur l'API ? Oui, simplement dans une autre monnaie. Les abonnements vous mesurent via des limites d'usage, et ces limites sont consommées par les mêmes tokens qu'un utilisateur API paie. Un setup plus léger signifie plus de vrai travail avant d'atteindre le plafond. Les utilisateurs qui « heurtent constamment les limites » transportent généralement 40 000 tokens de préambule par requête sans le savoir.

Les skills installés coûtent-ils des tokens quand ils ne servent pas ? Seulement la description de déclenchement, typiquement 30 à 60 tokens par skill et par requête. Le corps se charge quand le skill se déclenche. Vingt skills installés coûtent environ 1 000 tokens de frais permanents, raison pour laquelle une grande bibliothèque de skills est bon marché quand un gros CLAUDE.md ne l'est pas. Le seul mode d'échec : les skills aux descriptions gonflées ; nous les signalons dans nos revues.

Combien de contexte un serveur MCP consomme-t-il réellement ? Cela varie énormément, raison pour laquelle vous devriez mesurer le vôtre : lancez /context avec le serveur connecté, puis déconnecté. Les petits serveurs ciblés ajoutent 1 000 à 3 000 tokens de schémas. Les gros serveurs officiels peuvent en ajouter 15 000 à 25 000. Le coût s'applique à chaque requête, que vous appeliez un outil ou non.

/compact vaut-il mieux qu'une session fraîche ? Des rôles différents. /compact sert à poursuivre un travail lié : il résume l'historique pour que le contexte continue en plus petit. Une session fraîche sert à changer de sujet, et c'est alors l'option la moins chère et la meilleure, parce qu'un historique sans rapport n'est pas seulement coûteux, il dégrade activement la sortie. Si vous compactez pour continuer quelque chose sans rapport, c'est /clear que vous vouliez.

Le cache de prompt ne règle-t-il pas tout cela automatiquement ? Il aide beaucoup et il est activé par défaut dans Claude Code, mais il fait une remise sur le gaspillage plutôt que de le supprimer. Les tokens en cache se facturent toujours à environ 10 %, remplissent toujours votre fenêtre de contexte et vous poussent toujours vers une compaction précoce. Et le cache casse en silence : le moindre changement dans le préfixe stable, comme un timestamp dans votre setup, et vous revoilà au plein tarif sans avertissement. Structurez bien votre contexte et le cache multiplie les économies ; structurez-le mal et le cache masque le problème jusqu'à la facture.