Tu lances Claude Code, tu envoies deux prompts pas bien méchants, et là : “usage limits”. Et le pire, c’est l’effet psychologique. Tu te dis que tu as forcément fait une connerie, qu’un agent a aspiré ton repo en douce, ou que tu as oublié un flag. Sauf que non, il y a un scénario bien plus tordu et très plausible : des “phantom tokens” qui te sont facturés alors que tu ne les as pas vraiment “demandés”, souvent visibles côté métriques sous un champ du genre cache_creation_input_tokens.
L’objectif ici n’est pas de râler contre un outil. C’est de reprendre la main : constater, prouver, réduire l’impact, et mettre en place deux trois garde-fous pour éviter que ton équipe se fasse gaslight par un quota qui part en fumée.
Le symptôme : “usage limits” alors que ton activité est normale
Le pattern est assez reconnaissable. Tu as une session Claude Code qui a l’air “light” côté usage humain, mais tu observes une explosion soudaine de tokens et souvent une latence qui devient étrange. Le truc qui met la puce à l’oreille, c’est quand ça arrive sur des actions qui devraient coûter peu : une question simple, un refactor court, ou une commande de contexte que tu utilises depuis des semaines.
Si tu es dans ce cas, ne perds pas une heure à “optimiser tes prompts” au hasard. La première question à te poser, c’est : est-ce que je paye pour un gros contexte ou pour une création de cache que je ne contrôle pas ? Parce que ça change complètement le diagnostic.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le vrai signal : des tokens facturés en “cache_creation_input_tokens”
Sur certains setups, l’explosion n’apparaît pas comme “input_tokens” classique, mais comme une ligne associée au cache, typiquement cache_creation_input_tokens. Ce détail est important, parce que ça pointe vers une mécanique où l’outil (ou le backend) génère une forme de “préparation” de contexte et la facture comme une création de cache, même si ton prompt, lui, n’a rien d’énorme.
Concrètement, ça peut se traduire par des gros incréments (des milliers, voire des dizaines de milliers) à des moments où tu n’as pas fait grand-chose. Et si en plus tu as l’impression que la commande /context devient peu fiable (ou que l’outil “oublie” ce qu’il vient de scanner), tu tiens un combo assez cohérent : cache instable + facturation cache qui part en vrille.
Prouver le problème sans débat : un protocole simple et reproductible
Le piège, c’est de rester dans le ressenti. “J’ai l’impression que ça consomme plus.” Ça ne pèse rien face à un support ou une équipe. Ce que tu veux, c’est un petit protocole qui te donne un avant/après propre.
Je fais généralement comme ça. Je prends un repo neutre (ou un sous-ensemble minimal de mon repo), je prépare un prompt fixe que je peux rejouer à l’identique, et je teste deux versions de l’outil si j’ai un doute qu’une release ait changé quelque chose. L’idée n’est pas de benchmarker des modèles, c’est de vérifier si le coût “caché” est stable ou s’il y a un saut anormal qui colle à une version.
Ensuite je note trois trucs : le moment exact, l’action exacte (commande, prompt), et ce que je vois dans les métriques d’usage (surtout si un champ “cache_creation_input_tokens” existe et grimpe). Si tu peux relier ça à un request id ou un identifiant de trace côté outil, c’est encore mieux. Là, tu arrêtes de discuter : tu montres.
Mettre un proxy HTTP devant Claude Code pour capturer des preuves
Quand tu veux passer du “je pense” au “voilà la requête”, un proxy HTTP est ton meilleur allié. Pas pour sniffer des secrets, mais pour confirmer ce qui part vers l’API, et surtout corréler une action locale avec une requête distante et son timing.
Selon ton environnement, tu peux utiliser mitmproxy, Proxyman, Charles, ou un proxy d’entreprise si tu en as un. Le point important : Claude Code (ou ton wrapper) doit respecter HTTPS_PROXY/HTTP_PROXY. Si ça ne passe pas, tu peux quand même capturer au niveau système, mais c’est plus pénible.
# Exemple avec mitmproxy en local (macOS/Linux)
# 1) Lance le proxy
mitmproxy -p 8080
# 2) Dans un autre terminal, force l'outil à passer par le proxy
export HTTPS_PROXY=http://127.0.0.1:8080
export HTTP_PROXY=http://127.0.0.1:8080
# 3) Lance Claude Code depuis ce même shell
claude-codeAttention : selon les outils, tu vas te heurter à TLS, aux certificats, et à des sécurités qui empêchent l’interception. Ce n’est pas grave. Même sans déchiffrer tout le contenu, tu peux déjà observer la fréquence des appels, leur taille, et le fait qu’une action “petite” déclenche soudainement un gros trafic ou une séquence d’appels qui ressemble à une indexation complète.
Pourquoi certains repos déclenchent l’explosion : workspace énorme, fichiers toxiques, contexte “aspirateur”
Sur le terrain, les cas qui partent en vrille sont rarement des petits projets propres. Ça arrive quand ton workspace ressemble à une vraie vie : monorepo, dossiers build, dumps JSON, fixtures lourdes, fichiers générés, ou même des binaires qui traînent parce que quelqu’un a fait un zip et l’a commité “juste pour tester”.
Dans ce contexte, une feature de récupération de contexte peut devenir un aspirateur. Et même si l’outil “devrait” filtrer, “devrait” respecter .gitignore, “devrait” plafonner, la réalité c’est que les edge cases existent. Le résultat côté facture, lui, ne fait pas de distinction entre “contexte utile” et “contexte accidentel”.
Si tu vois le problème surtout sur un repo précis, c’est un signal. Et si tu peux reproduire en ajoutant un dossier lourd (ou en augmentant la taille du workspace), tu as quasiment une preuve par l’absurde : le coût suit la surface scannée, pas ton prompt.
Mitigations pragmatiques : limiter la casse sans casser ton flow
Le workaround le plus rentable, quand tu suspectes une régression, c’est souvent le plus bête : pinner une version de Claude Code qui ne déclenche pas le souci, au moins temporairement. Ce n’est pas “propre”, mais c’est mieux que de griller un quota d’équipe ou de tuer la confiance dans l’outil. Et oui, ça veut dire accepter de ne pas courir après la dernière release pendant quelques jours.
Ensuite, tu peux réduire les chances de déclenchement. Typiquement, réduis la taille du workspace quand tu démarres une session IA. Ouvre un sous-dossier pertinent plutôt que la racine du monorepo. Évite de travailler avec un dossier qui contient build, dist, caches, vendor, node_modules, ou des exports. Si tu as des commandes de contexte automatiques ou des “pré-scans”, coupe-les ou limite-les. Ça fait moins magique, mais tu reprends le contrôle.
Dernier levier : fais la chasse aux fichiers “toxiques” pour ce genre d’outil. Le fichier de logs de 200 Mo, le dump SQL, le JSON énorme, le zip, le PDF. Même si l’IA est censée ne pas les ingérer, ils peuvent suffire à déclencher des comportements bizarres. Et quand tu es en mode incident, tu veux enlever des variables, pas en ajouter.
Routine de monitoring : retrouver un coût normal, puis le surveiller
Une fois que tu as stabilisé, ne te contente pas d’un “ça a l’air mieux”. Mets en place un mini rituel : un prompt de test identique, sur un repo neutre, à fréquence régulière, et tu notes l’usage observé. Tu n’as pas besoin d’un dashboard BI. Tu as besoin d’un “thermomètre” que tu peux ressortir quand tu updates une version ou quand quelqu’un dans l’équipe dit “tiens c’est lent” ou “tiens j’ai encore un usage limit”.
Et si tu bosses en équipe, je le dis franchement : centralise l’info. Un canal Slack, un ticket, un doc court, avec la version qui marche, la version qui casse, et un lien vers une trace. Sinon tu vas revivre la même histoire tous les trois jours avec une personne différente.
Quand ce n’est pas des phantom tokens : les faux positifs classiques
Il y a quand même des cas où le “quota cramé” est 100% explicable. Le plus courant, c’est la multiplication des agents ou des tâches parallèles. L’outil te donne une impression de conversation linéaire, mais derrière tu lances des opérations qui se recouvrent, se relancent, ou repassent sur les mêmes fichiers. Autre cas : un prompt “innocent” qui déclenche en réalité une grosse analyse parce que tu as demandé un audit global, une migration, ou une recherche dans tout le repo.
Et puis il y a le facteur humain : on sous-estime souvent la taille du contexte effectif. Entre les fichiers ouverts dans l’IDE, le contexte récupéré automatiquement, les instructions d’agent, et la conversation qui s’allonge, tu peux monter haut. D’où l’intérêt de faire le protocole de test sur un environnement maîtrisé. S’il explose quand même, tu as quelque chose.
Mon avis : sur l’IA, les métriques de tokens sont une vraie métrique de DX
Quand un outil IA devient “imprévisible” sur le coût, c’est une dette de dev experience. Ça tue l’usage, ça crée des comportements débiles (ne plus oser demander des choses), et ça fait perdre du temps à l’équipe en contournements. Donc oui, ça vaut le coup d’être carré, de collecter des preuves, et de poser des règles simples, même temporairement.
Et si tu maintiens un workflow IA dans une équipe, retiens ça : pinner une version et réduire le périmètre scanné, c’est parfois la différence entre “outil utile” et “outil anxiogène”. Ce n’est pas glamour, mais c’est ça qui fait tenir une intégration en prod.
