4,07 milliards. C'est le nombre de tokens que mes sessions Claude Code ont consommés en cache read en quelques semaines de travail. Quand j'ai découvert ce chiffre, j'ai d'abord cru à une erreur de mon script d'analyse.
Ce n'en était pas une.
La plupart des développeurs utilisent Claude Code comme on conduit une voiture sans jamais regarder la jauge d'essence. On avance, on produit du code, on résout des problèmes. Mais personne ne se demande combien de tokens chaque session consomme réellement, ni où partent ces tokens. Dans cet article, je partage les résultats de mon audit sur 351 sessions et les règles que j'ai mises en place pour réduire le gaspillage de 20 à 30 %.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
Le constat : 351 sessions sous le microscope
Pour comprendre où partaient mes tokens, j'ai écrit un script Python qui parse les fichiers JSONL générés par Claude Code.
Chaque session est un fichier structuré contenant les messages, les appels d'outils, les résultats et les métadonnées d'utilisation.
| Métrique | Valeur |
|---|---|
| Sessions analysées | 351 |
| Turns utilisateur | 25 032 |
| Cache read total | 4,07 milliards tokens |
| Cache create total | 230 millions tokens |
| Output total | 4,56 millions tokens |
| Stockage JSONL | 1,79 Go |
Le top cinq des projets par consommation cache révèle une répartition inégale. Un seul workspace Svelte5 représente 37,5 % de la consommation totale avec 1,52 milliard de tokens, suivi par le même projet en local (12,7 %), mon projet article (10,5 %), la configuration Claude elle-même (8,9 %) et un projet Symfony (8,2 %).
En pratique, cela signifie que cinq projets concentrent 78 % de la consommation. Le reste se répartit sur dix projets secondaires.
Les quatre coupables identifiés
L'audit ne s'est pas arrêté aux totaux. J'ai catégorisé chaque token par source pour identifier les gaspillages.
Les lectures de fichiers : 39 % du contexte
C'est le coupable numéro un. Sur ma session d'analyse (646 turns), les lectures de fichiers représentaient 39 % des tokens de contenu, soit 110 712 tokens. Le seuil d'alerte est à 25 %. J'étais 14 points au-dessus.
L'analyse détaillée montre 38 lectures volumineuses dépassant 1 000 tokens chacune, totalisant 95 180 tokens. Les cinq fichiers les plus coûteux pesaient entre 3 705 et 6 873 tokens pièce.
La cause racine est simple : les agents lisent les fichiers en entier avant chaque modification, même quand seules quelques lignes sont pertinentes. Un fichier de 700 lignes comme agent-router.ts est lu intégralement pour modifier trois lignes. C'est l'équivalent de photocopier un livre entier pour corriger une faute de frappe.
Les sorties Bash : 16 % du contexte
Deuxième coupable : les commandes dont la sortie n'est pas filtrée. Les requêtes psql qui retournent des tableaux complets, les scripts Python qui affichent des rapports texte de dix sessions, les listes de fichiers sans limite.
24 sorties dépassaient 500 tokens, totalisant 31 608 tokens. Les trois plus volumineuses atteignaient 2 496, 2 563 et 3 216 tokens.
La croissance du cache prompt
Chaque turn dans Claude Code ré-envoie l'intégralité du contexte au modèle. En début de session, le prompt système et les règles pèsent environ 33 000 tokens. À mi-session, l'accumulation des messages pousse ce chiffre à 86 000. En fin de session, on atteint 103 000 tokens.
Le taux de hit cache est excellent (95,9 %) — l'infrastructure Anthropic fonctionne bien. Mais chaque turn expédie quand même 100 000 tokens ou plus au cache, ce qui augmente la latence et le coût CPU.
Les outils MCP
Quatrième source de consommation, moins critique : les résultats de recherche sémantique GrepAI. Sur le projet Svelte5, douze appels au serveur MCP ont généré 21 493 tokens. Les résultats sont rarement filtrés par limite ou format compact.
Les règles d'optimisation : la solution
Face à ces constats, j'ai implémenté un fichier de règles dans .claude/rules/token-optimization.md. Ce fichier est chargé automatiquement dans le prompt système de chaque session Claude Code. Le principe directeur tient en une phrase : « Grep avant Read, head après Bash, compact à 50 %. »
Cibler les lectures de fichiers
La règle la plus impactante : ne jamais lire un fichier en entier quand on peut cibler. En pratique :
- Grep ou Glob d'abord pour localiser les lignes pertinentes
- Read avec offset et limit pour extraire uniquement la section nécessaire
- Ne jamais re-lire un fichier déjà présent dans le contexte de conversation
- Préférer Edit à la séquence Read + Write quand on connaît la chaîne exacte à remplacer
Pour un fichier de 400 lignes, passer de « lire les 400 lignes » à « Grep pour trouver la ligne 247, puis Read offset=240 limit=20 » réduit la consommation de 95 %.
Filtrer les sorties Bash
Chaque commande susceptible de produire une sortie volumineuse doit être filtrée :
- | head -50 pour les commandes de listing
- -t (tuples only) et LIMIT pour les requêtes PostgreSQL
- Redirection vers /tmp/output.txt puis Read --limit 20 pour les gros résultats
L'objectif est de ne jamais injecter plus de 500 tokens de sortie Bash dans le contexte quand 50 suffisent.
Gérer la pression du contexte
La fenêtre de contexte n'est pas infinie. Deux règles pour la préserver :
- Compacter à 50 % : quand le contexte dépasse la moitié de la capacité, déclencher une compaction manuelle pour résumer les échanges précédents
- Découper en sous-agents : pour les workflows dépassant 200 turns, dispatcher des sous-agents avec un contexte frais plutôt que d'accumuler
Discipliner les sous-agents
Les sous-agents héritent du problème si on ne leur impose pas de contraintes. Chaque dispatch doit inclure :
- Un budget maximum de lectures de fichiers
- Des limites sur les sorties Bash
- Le pourcentage actuel d'utilisation du contexte
- La préférence pour le modèle Haiku sur les tâches simples (recherche, éditions mineures)
Mesurer l'impact : les KPI à suivre
Des règles sans métriques, c'est de l'espoir. Voici les indicateurs que je suis après chaque session :
| KPI | Avant optimisation | Cible |
|---|---|---|
| Lectures fichiers (% contexte) | 26-39 % | < 20 % |
| Sorties Bash (% contexte) | 15-23 % | < 12 % |
| Lectures volumineuses (> 3K tokens) | 5-10 par session | < 3 |
| Sorties Bash volumineuses (> 500 tokens) | 24 par session | < 10 |
| Taille prompt en fin de session | ~103K tokens | < 80K |
Le monitoring passe par le même script Python d'analyse des JSONL, enrichi d'un tableau de bord pgvector pour le suivi dans le temps. L'idée est la même que pour le monitoring d'applications : on ne peut pas optimiser ce qu'on ne mesure pas.
La boucle vertueuse est simple : mesurer, identifier les hotspots, appliquer une règle, re-mesurer. Comme en performance applicative, les gains les plus importants viennent des premières optimisations. Passer les lectures de fichiers de 39 % à 20 % libère près de 20 % de la fenêtre de contexte pour du contenu utile.
Contrairement à une idée reçue, l'optimisation des tokens n'est pas une contrainte. C'est un levier de productivité. Moins de tokens gaspillés signifie des sessions plus longues avant d'atteindre la limite, des réponses plus rapides (moins de contexte à traiter), et une meilleure qualité des réponses (le modèle se concentre sur le signal, pas le bruit).
Conclusion
Sans audit, impossible de savoir où partent vos tokens. Mon audit de 351 sessions a révélé que 39 % du contexte était consommé par des lectures de fichiers non ciblées — un gaspillage invisible qui ralentissait mes sessions et réduisait leur durée utile.
Les règles que j'ai mises en place sont simples et actionnables. Elles ne demandent aucun outil supplémentaire, juste de la discipline dans la façon dont on interagit avec Claude Code. Un fichier de règles dans .claude/rules/, chargé automatiquement, suffit à transformer les habitudes.
Commencez par auditer une seule session. Comptez vos lectures de fichiers, mesurez vos sorties Bash, regardez la taille de votre prompt en fin de conversation. Les résultats surprennent toujours.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100% IA.
Apprendre à optimiser sa consommation de tokens sur claude code