Statistiques d'utilisation des tokens de Claude Code (2026)

La facture de tokens de Claude Code se résume à une poignée de chiffres : combien de tokens une session consomme réellement, la répartition déséquilibrée entre ce qu'il lit et ce qu'il écrit, la remise que le caching vous offre sur le contexte répété, et le tarif par million de tokens du modèle qui le propulse. Cette page rassemble ces chiffres depuis des sources primaires pour que vous n'ayez pas à les reconstituer depuis un dashboard de facturation à 2 h du matin.

Je conçois des outils de réduction de tokens pour gagner ma vie, donc je lis ces analyses avec un intérêt bien réel — et le titre auquel je reviens toujours est peu glamour : ce qui coûte cher, c'est ce que l'agent lit, pas ce qu'il écrit. Les tarifs, les multiplicateurs de cache et le modèle par défaut ont été revérifiés dans la documentation d'Anthropic en octobre 2026 ; les versions de modèles et les tarifs évoluent vite, donc revérifiez à la source primaire avant de les citer dans un contrat.

Points clés

Combien de tokens une session Claude Code consomme-t-elle ?

Une session d'agentic coding typique de 50 tours consomme environ 1 000 000 input tokens et 40 000 output tokens — un ratio input/output de 25:1. [1] Ce ratio est le fait le plus important sur l'économie de Claude Code, et il surprend presque tout le monde la première fois qu'il le découvre.

Le mécanisme est simple une fois énoncé à voix haute. Claude Code est un agent : chaque tool call (lire un fichier, lancer un test, grep le dépôt) renvoie au modèle l'intégralité du contexte accumulé — system prompt, définitions d'outils, historique de la conversation, contenu des fichiers, sortie des commandes. Au tour 30 d'une session de débogage, l'agent relit 25 000 à 35 000 tokens d'historique à chaque requête. L'output qu'il écrit — un patch, un paragraphe d'explication — est minuscule en comparaison. [1]

Qu'est-ce que cela donne par personne ? La documentation de Claude Code d'Anthropic situe la moyenne des déploiements entreprise à environ 13 $ par développeur et par jour actif, soit 150–250 $ par développeur et par mois, avec des coûts sous 30 $ par jour actif pour 90 % des utilisateurs. [11] Les histoires viennent de la longue traîne : faire tourner plusieurs instances en parallèle ou brancher l'agent sur de l'automatisation vous fait vite sortir de ces 90 %. Si votre facture mensuelle ressemble à une ligne de salaire, le schéma d'accumulation du context window ci-dessus en est la cause.

Pourquoi l'input est-il le côté coûteux, alors que l'output coûte 5× plus par token ?

C'est la partie qui fait trébucher les gens. Sur chaque palier Claude, les output tokens sont facturés au 5× du tarif input — 50 $ contre 10 $ par million sur Fable 5.1, 20 $ contre 4 $ sur Opus 5.5, 10 $ contre 2 $ sur Sonnet 5.5, 5 $ contre 1 $ sur Haiku 4.5. [5] L'instinct naïf est donc de faire écrire moins à l'agent.

C'est le mauvais levier. Les input tokens tirent environ 85 % du coût total de la session en production, parce que l'écart de volume écrase l'écart de prix. [1] Un ratio de volume de 25:1 face à un ratio de prix de 5:1 signifie que l'input l'emporte quand même sur la facture par un facteur cinq. Dire à Claude Code d'« être concis » rogne la partie la moins chère et la plus petite de votre dépense.

Le mouvement à fort levier est l'inverse : contrôler ce que l'agent lit à chaque tour. Récupérer uniquement le code pertinent au lieu de déverser des fichiers entiers, élaguer l'historique de conversation périmé, et ne pas re-fournir au modèle de l'output qu'il a déjà vu. C'est précisément l'écart que l'output filtering et la semantic code search sont conçus pour combler.

Combien coûtent réellement les tokens ?

Le tarif par million de tokens dépend du modèle qui propulse Claude Code. Depuis la génération Opus 5.5 / Sonnet 5.5 / Haiku 5.5, la gamme Claude actuelle couvre une amplitude de 100× sur le prix de l'input, de Fable 5.1 en haut à Haiku 5.5 en bas. Le réglage de modèle default de Claude Code pointe sur Opus 5.5 pour les offres Pro, Max, Team, Enterprise et l'API Anthropic. [12]

Pour le panorama complet inter-fournisseurs — gammes d'OpenAI et de Google incluses — voir la référence tarification des tokens des API LLM et la ventilation des coûts en tokens des agents de coding IA. Le détail qui compte ici : les cache read chez Anthropic ne sont plus un 10 % uniforme. Ils sont facturés à 10 % du prix de base de l'input sur Sonnet et Haiku, 5 % sur Opus 5.5 et 2,5 % sur Fable 5.1. [5]

Dans quelle mesure le prompt caching change-t-il la facture de Claude Code ?

Le prompt caching d'Anthropic facture les cache read tokens à 10 % du prix de base de l'input sur la plupart des modèles — 5 % sur Opus 5.5, 2,5 % sur Fable 5.1 — tandis qu'un cache write coûte 1,25× le prix de base de l'input pour un TTL de 5 minutes, ou 2× pour un TTL d'une heure. La durée de vie par défaut est de 5 minutes, renouvelée à chaque réutilisation du préfixe. [3] [5]

Le hic, c'est que le préfixe mis en cache doit être identique octet pour octet d'une requête à l'autre. Réordonnez une seule instruction et le cache rate. GitHub a mesuré le problème du préfixe dans ses propres workflows agentiques en mai 2026 : le gaspillage le plus fréquent venait des outils MCP enregistrés mais inutilisés (un serveur GitHub MCP de 40 outils ajoute 10 à 15 Ko de schéma à chaque tour), et après correction, les « effective tokens » pondérés par le coût ont baissé de 19 % à 62 % selon le workflow, tandis qu'un workflow a augmenté de 5 %. [6] Quand le préfixe dérive — ce qui est le défaut pour beaucoup de harnais d'agents — vous payez plein tarif.

Le caching aide pour le préfixe stable. Il ne fait rien pour la partie de la facture qui est réellement neuve-mais-redondante : le même fichier relu à trois tours d'écart, la sortie de test sur laquelle vous avez déjà agi, le listing de répertoire que vous avez maintenant vu cinq fois. Ce résidu est l'essentiel de ce que la context compression cible.

Quelle part de la facture Claude Code n'est que du contexte renvoyé ?

Une bonne part. Un audit LeanOps de 2026 portant sur 30 équipes d'ingénierie faisant tourner de l'IA agentique en production a constaté que le contexte renvoyé représente ≈62 % de la facture totale. [4] Le même audit rapportait que les équipes atteignant 50 à 70 % de réduction de coûts en deux semaines combinaient systématiquement des plafonds de budget par utilisateur, le prompt caching, le routage par palier de modèle et l'élagage du context window. [4]

C'est le chiffre phare pour quiconque cherche à réduire une facture Claude Code : environ six dollars sur dix correspondent au modèle relisant des choses qu'il a déjà vues. Vous ne pouvez pas corriger cela en changeant de modèle ou en écrivant des prompts plus laconiques — seulement en changeant ce qui est envoyé.

Combien Claude Code coûte-t-il réellement à grande échelle ?

Des points de données d'entreprises et d'individus de 2026 donnent une idée concrète de la façon dont la dépense en tokens évolue avec l'intensité d'usage.

Uber a épuisé l'intégralité de son budget d'outils IA 2026 dès avril — quatre mois après le début — après que l'adoption de Claude Code est passée de 32 % à 84 % parmi ses 5 000 ingénieurs. L'ingénieur moyen coûtait 150–250 $ par mois ; les utilisateurs intensifs cumulaient 500–2 000 $ par ingénieur et par mois, et la direction d'Uber a reconnu ne pas pouvoir encore quantifier le retour de productivité alors qu'environ 70 % du code commité venait d'outils d'IA. [2]

L'équipe de Peter Steinberger a fait tourner une centaine d'instances Codex dans le cloud pendant un mois, sur le projet OpenClaw, et a publié une facture de 1,3 million de dollars — 603 milliards de tokens sur 7,6 millions de requêtes. Une réserve à garder : les chiffres exacts proviennent d'une capture d'écran du post de Steinberger, pas d'une déclaration publiée. Mais les chiffres restent le benchmark public le plus concret pour l'agentic coding autonome à grande échelle. [7]

Un développeur sur Reddit a laissé une boucle Claude Code tourner toute la nuit — interrogeant les mises à jour logicielles toutes les 30 minutes — et s'est réveillé avec une facture de 6 000 $. La cause était une combinaison d'un context window de 800 000 tokens reconstruit de zéro à chaque cycle (Claude Code s'était mis à écrire de nombreuses requêtes avec un TTL de cache de 5 minutes au lieu d'une heure début mars 2026 ; Anthropic a ensuite expliqué dans le fil GitHub que le client choisit désormais le TTL requête par requête pour réduire le coût total) et d'une absence de plafond de dépense. Il n'y avait aucun dashboard en temps réel pour l'avertir ; la première alerte fut l'e-mail confirmant les dégâts. [8]

À l'autre extrémité de l'échelle, Henry Godnick a documenté une facture surprise de 80 $ générée par un script de traitement par lots qu'il avait laissé tourner sans surveillance — un rappel que même de petites boucles s'accumulent vite lorsque chaque itération reconstruit un contexte multi-tours. [9]

Ces points de données partagent une structure commune : le pic de coût n'est pas un seul gros appel de modèle mais de nombreux appels moyens, chacun renvoyant un contexte croissant. L'implication pratique est que le savings dashboard compte le plus précisément quand une session est longue ou qu'une boucle tourne — les moments exacts où vous êtes le moins susceptible de surveiller.

Que dit la recherche sur les coûts de gestion du contexte des agents ?

Une étude de Lindenbauer et al. (JetBrains Research), arXiv:2508.21433, mise en ligne en août 2025 et présentée au workshop DL4C de NeurIPS 2025, a évalué les stratégies de gestion du contexte pour les agents d'ingénierie logicielle basés sur des LLM sur SWE-bench Verified, à travers cinq configurations de modèles. [10]

La conclusion phare est contre-intuitive : le simple observation masking (tronquer les sorties d'outils plus anciennes) réduit de moitié le coût par rapport à la baseline brute de l'agent tout en égalant le taux de résolution d'une summarisation par LLM plus coûteuse. Avec Qwen3-Coder 480B, l'observation masking a réduit le coût par instance de 52,7 % (de 1,29 $ à 0,61 $) par rapport à la baseline brute, tandis que le taux de résolution passait de 53,4 % à 54,8 %. La révision d'octobre 2025 ajoute un hybride masking + summarisation qui retire encore 7 % de coût par rapport au masking seul. L'étude remet en cause l'hypothèse selon laquelle une gestion du contexte plus intelligente implique nécessairement plus d'appels LLM — parfois cela signifie simplement ne pas envoyer les anciennes données.

L'implication plus large pour les utilisateurs de Claude Code : la conception du harnais d'agent (ce qu'il garde, ce qu'il jette, comment il gère les longues sorties d'outils) est une variable de coût aussi importante que le palier de modèle que vous choisissez.

Note méthodologique

Les prix par token proviennent de la page de tarification officielle d'Anthropic (source primaire, vérifiée en octobre 2026). Les multiplicateurs du prompt caching proviennent de la documentation pricing et prompt caching d'Anthropic (source primaire). Les moyennes quotidiennes et mensuelles par développeur et le modèle par défaut proviennent de la documentation de Claude Code d'Anthropic (source primaire, octobre 2026). Les chiffres de volume de session et de répartition des coûts proviennent de l'analyse de production de Vantage. Le chiffre de 62 % de contexte renvoyé provient d'un audit industriel de 30 équipes en production, pas d'une étude académique, et doit être traité comme indicatif. Les données de coûts d'entreprise (Uber, OpenClaw) proviennent de reportages de presse contemporains. Le preprint arXiv de Lindenbauer et al. (2508.21433) est la source académique des benchmarks de coût de gestion du contexte sur SWE-bench Verified. Les coûts de session indicatifs utilisent les tarifs publiés d'Anthropic avec le profil de volume de Vantage et sans caching appliqué. Revérifiez chaque chiffre à sa source primaire avant de le citer dans un contexte commercial.