Un matin, Claude Code refuse de démarrer. Crédits épuisés. J'avais un plan à 200€, un système de veille automatisée qui tourne en continu, et Claude Code que j'utilise comme pair-programmeur pour tout le reste. Jusque-là, rien d'anormal — mais le crédit partait deux fois plus vite que prévu et je n'arrivais pas à comprendre pourquoi.
La veille, oui. Le CLI appelé en boucle toutes les 12h, ça se calcule. Mais les sessions interactives semblaient raisonnables. En creusant, j'ai trouvé le vrai coupable : dix plugins Claude Code actifs en même temps, dont la moitié que je n'utilisais jamais.
Ce que j'avais installé
Au fil des semaines, j'avais activé les plugins au fur et à mesure des besoins :
superpowers pour les skills structurés, context7 pour la
doc des librairies, playwright pour le scraping, code-review,
frontend-design. Plus quelques autres. Le principe : avoir l'outil
sous la main si le besoin arrive.
C'est là l'erreur de raisonnement. J'ai traité les plugins comme des extensions de navigateur — présentes en arrière-plan, inertes tant qu'on ne les clique pas. Les plugins Claude Code ne fonctionnent pas comme ça.
Ce que les plugins font vraiment
Chaque plugin actif injecte du contenu dans le system prompt à chaque échange. Pas à la demande. Pas uniquement quand vous les invoquez. À chaque message, dans chaque session.
Le plugin superpowers, par exemple, liste l'intégralité des skills
disponibles dans chaque system reminder. context7 injecte ses
instructions d'utilisation. playwright également. Multipliez ça par
dix plugins, et chaque tour de conversation démarre avec un contexte alourdi de
plusieurs milliers de tokens — avant même que vous ayez tapé quoi que ce soit.
La formule est simple : token injecté = token facturé, même s'il correspond à un plugin que vous n'avez pas utilisé depuis deux semaines.
Le calcul concret
Avec Sonnet 4.6, les tokens d'input coûtent $3 par million. Un plugin de taille moyenne injecte environ 2 000 tokens de contexte par message. Dix plugins : 20 000 tokens d'input supplémentaires par échange.
Sur une session active de 50 échanges, ça représente 1 million de tokens d'input supplémentaires — soit $3 — uniquement dus aux plugins passifs. Sur une journée avec plusieurs sessions, ça s'accumule vite.
Ce n'est pas catastrophique pris isolément. Mais combiné avec une veille automatisée qui consomme déjà des dizaines d'appels par jour, les deux effets se cumulent et vident le crédit bien plus vite que ce que l'usage réel laisserait supposer.
Comment diagnostiquer votre situation
La consommation de tokens n'est pas visible directement dans Claude Code, mais
vous pouvez déduire ce que vos plugins injectent. Dans ~/.claude/settings.json,
la clé enabledPlugins liste ce qui est actif :
{
"enabledPlugins": {
"superpowers@claude-plugins-official": true,
"context7@claude-plugins-official": true,
"playwright@claude-plugins-official": true,
"code-review@claude-plugins-official": true,
"frontend-design@claude-plugins-official": true
}
}
Pour chaque plugin à true, posez-vous la question : "Est-ce que
j'utilise ce plugin dans au moins la moitié de mes sessions ?" Si non,
désactivez-le. Vous pouvez le réactiver en 30 secondes via /plugin
quand le besoin arrive.
La bonne stratégie d'utilisation
La règle que j'applique maintenant : aucun plugin actif par défaut, activation à la demande. Les plugins ne sont pas des features permanentes — ce sont des abonnements à du contexte. Chaque plugin actif est une ligne de frais fixes sur chaque message.
Pour les workflows récurrents comme la création d'articles ou le debug de la
veille, les skills intégrés dans les CLAUDE.md ou les skills locaux
(~/.claude/skills/) sont une meilleure alternative : ils ne
s'injectent que quand vous les invoquez explicitement.
La même logique s'applique aux fichiers CLAUDE.md : chaque ligne chargée à chaque session est un token facturé. Un CLAUDE.md de 8 Ko qui documente l'architecture complète du projet coûte plus cher qu'un CLAUDE.md minimal qui pointe vers des fichiers de référence. Il vaut mieux avoir plusieurs CLAUDE.md spécialisés et laisser Claude lire le code que de tout pré-mâcher dans le contexte.
Conclusion
La surprise n'est pas que les plugins coûtent des tokens — c'est que rien dans l'interface ne le rende visible. Vous activez un plugin, vous l'oubliez, il continue de peser sur chaque échange en silence.
Si votre crédit part plus vite que prévu, avant d'optimiser les prompts ou
de changer de modèle, commencez par lister ce qui est actif dans
settings.json. La réponse est souvent là.