Tokens Claude : comprendre le coût d’un tour Claude Code

Quels sont les tokens dans Claude ?

Un token est l’unité de texte que Claude lit et écrit : un fragment de mot. Le glossaire d’Anthropic l’estime à environ 3.5 caractères anglais sur les modèles antérieurs à Claude Opus 4.7. Avec le tokenizer actuel, on est plutôt proche de 2.5, car Anthropic indique que 1M tokens correspondent à environ 2.5M caractères. Dans les deux cas, cela représente largement plus d’un token par mot une fois les espaces et la ponctuation comptabilisés. Un texte de 1,000 mots dépasse donc largement 1,300 tokens. Le code consomme davantage de tokens par ligne : les accolades, les opérateurs, les underscores et l’indentation produisent davantage de tokens par caractère que l’anglais. Un fichier source de quelques centaines de lignes représente généralement plusieurs milliers de tokens. Un fichier de 2,000 lignes que l’agent décide de lire représente une consommation à cinq chiffres avant même l’écriture d’une seule ligne de nouveau code.

Deux points concernant les tokenizers posent souvent problème. Premièrement, ils dépendent du modèle. En octobre 2026, Claude Opus 4.7 et tous les modèles ultérieurs, notamment Fable 5.1, Opus 5.5, Sonnet 5.5 et Haiku 5.5, utilisent un tokenizer plus récent. Celui-ci produit environ 30% de tokens supplémentaires pour un même texte par rapport aux anciens modèles Claude, comme Haiku 4.5. L’augmentation exacte dépend du contenu. Cela modifie tout budget calculé en tokens, même si le prix par token n’a pas augmenté. Deuxièmement, tiktoken, la bibliothèque utilisée dans presque tous les articles de blog, est le tokenizer d’OpenAI, pas celui de Claude. Ses décomptes ne correspondent donc pas à ceux facturés par Anthropic. Le seul décompte fiable provient du endpoint count_tokens, présenté plus bas.

Pourquoi votre session de programmation coûte ce qu’elle coûte

Chaque facturation Claude, qu’il s’agisse d’une facture API ou d’une limite d’abonnement, repose principalement sur un seul compteur : les tokens entrants et sortants. Quelques outils API ajoutent leur propre ligne — la recherche web coûte par exemple $10 pour 1 000 recherches en octobre 2026, en plus des tokens ajoutés par ses résultats —, mais dans une session de programmation, c’est le compteur de tokens qui évolue. La page tarifaire donne une impression de simplicité : un certain nombre de dollars par million de tokens d’entrée, et un autre par million de tokens de sortie. Elle n’indique pas que, dans une session de programmation agentique, le compteur d’entrée évolue beaucoup plus vite qu’on ne le pense, car toute la conversation est renvoyée à chaque tour. Je vends des infrastructures avec facturation à la consommation depuis quinze ans, et les tokens sont le premier compteur que je rencontre dont la plupart des clients ne savent réellement pas ce qui le fait tourner. Voici ce qu’il faut comprendre : ce qui compte comme entrée et sortie dans une session agentique, pourquoi la boucle de renvoi coûte si cher, pourquoi le prompt caching modifie complètement le calcul et quels leviers font réellement varier le montant.

Tout est une entrée : ce que le compteur mesure réellement

On pense souvent payer pour le code écrit par Claude. Dans une session agentique, cette ligne représente une faible part du coût. Les tokens d’entrée, facturés au tarif le plus bas mais utilisés en bien plus grande quantité, comprennent notamment :

• Le prompt système. Les instructions du propre harness de Claude Code, ainsi que votre CLAUDE.md et vos fichiers de mémoire, sont chargés au début de la session et présents dans chaque requête suivante.
• Les définitions des outils. Chaque schéma d’outil que l’agent peut appeler. Chaque serveur MCP que vous connectez augmente cette surcharge fixe. Claude Code reporte toutefois désormais par défaut le chargement complet des définitions des outils MCP : seuls les noms des outils restent dans le contexte jusqu’à la première utilisation d’un outil. Le coût diminue ainsi, sans disparaître.
• Chaque fichier lu par l’agent. Un Read d’un fichier source place son contenu complet dans le contexte, où il reste ensuite présent.
• Chaque résultat d’outil. Exécutions de tests, sortie de grep, sortie du terminal, journaux de build : tout revient sous forme de tokens d’entrée. Une suite de tests en échec qui affiche 8,000 lignes représente un petit livre. Depuis octobre 2026, Claude Code transmet directement par défaut environ 30,000 caractères de sortie de commande. Au-delà, la sortie est enregistrée dans un fichier et accompagnée d’un aperçu de 2,000 caractères maximum. Toute sortie inférieure à cette limite, ainsi que chaque lecture ultérieure du fichier enregistré, est facturée intégralement.
• L’intégralité de la conversation jusqu’à présent, renvoyée à chaque tour. Ce point mérite une section à lui seul.

Le renvoi que personne ne facture

L’API Claude est sans état. Elle ne mémorise pas votre session entre les requêtes, et rien ne le fait. Au tour 2, le client envoie donc le tour 1, sa réponse et votre nouveau message. Au tour 50, il renvoie tout ce qui est encore présent dans le contexte des tours 1 à 49, chaque fichier lu, chaque résultat d’outil et chaque diff qui n’a pas été supprimé par la compaction, puis le tour 50. (La compaction remplace l’ancien historique par un résumé. Les lectures de fichiers d’un sous-agent restent dans son propre contexte ; seul son résultat revient dans le contexte principal.) Le modèle relit l’intégralité de la transcription conservée à chaque requête, et chacun de ces tokens relus est facturé comme token d’entrée.

Conséquence : le coût par tour augmente à peu près linéairement avec la longueur de la session, et le coût total de la session augmente à peu près de manière quadratique. Un message qui coûtait un demi-cent au tour 3 peut coûter vingt fois plus au tour 60, pour la même question d’une ligne, parce qu’il transporte soixante tours de contenu. C’est le fait principal qui explique la plupart des tickets « pourquoi ma facture est-elle si élevée ? ». Ce n’est pas une particularité de Claude : tout produit LLM qui semble conserver un état repose en réalité sur une API sans état et une boucle de renvoi.

Sortie : ce que vous voyez, et le raisonnement qui ne s’affiche pas

Les tokens de sortie sont les plus coûteux : leur tarif est cinq fois supérieur à celui des tokens d’entrée pour toute la gamme actuelle ($10/$50 pour Fable 5.1, $4/$20 pour Opus 5.5, $2/$10 pour Sonnet 5.5, $0.10/$0.50 pour Haiku 5.5 avec des prompts allant jusqu’à 100,000 tokens, en octobre 2026). La sortie comprend le texte et le code générés par Claude, ainsi que les tokens de raisonnement : le raisonnement interne que le modèle effectue avant de répondre. Deux faits sont importants. Le raisonnement est facturé au tarif des tokens de sortie et compte dans max_tokens. Une réponse d’API qui s’arrête avec stop_reason: "max_tokens", ainsi qu’une réponse tronquée, signifient souvent que le raisonnement a consommé le budget avant la génération de la réponse. De plus, sur les modèles actuels, le résumé du raisonnement peut ne pas être affiché du tout. L’API l’omet par défaut sur Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5 et les modèles précédents jusqu’à Opus 4.7, mais le raisonnement a tout de même eu lieu et reste facturé. Ce qui est invisible n’est pas gratuit.

Claude Code active le raisonnement étendu par défaut, car il améliore de manière mesurable les tâches en plusieurs étapes. Le budget par défaut peut atteindre plusieurs dizaines de milliers de tokens par requête. Pour les tâches plus simples, vous pouvez le réduire : diminuez le niveau d’effort avec /effort ou dans /model, ou désactivez le raisonnement dans /config sur les modèles qui l’autorisent. En octobre 2026, Claude Code ne peut pas désactiver le raisonnement sur Opus 5.5, Sonnet 5.5, Haiku 5.5 ou les modèles Fable. Le niveau d’effort reste donc le réglage disponible dans ce cas. L’API vous donne davantage de latitude sur deux de ces modèles. Haiku 5.5 accepte thinking: {"type": "disabled"} avec un niveau d’effort élevé ou inférieur, tout comme l’ancien Opus 5. L’ancien Sonnet 5 l’accepte à tous les niveaux d’effort, y compris xhigh et max. Sonnet 5.5 refuse "disabled" et utilise thinking: {"type": "between_tools"} à la place. Cela supprime le raisonnement initial avec un niveau d’effort faible, moyen ou élevé. Une requête sans outils reçoit donc sa réponse sans raisonnement préalable. Seuls Opus 5.5 et les modèles Fable conservent le raisonnement quelle que soit la requête envoyée. Il s’agit d’un véritable réglage des coûts, pas d’une simple superstition.

Le cache des prompts change complètement les calculs

Le prompt caching explique pourquoi la boucle de renvoi ne ruine pas tout le monde. L’API peut mettre en cache une partie stable de votre prompt : system prompt, définitions des outils, historique de la conversation. À la requête suivante, elle la sert à une fraction du prix. En octobre 2026, les multiplicateurs sont les suivants : une écriture dans le cache coûte 1.25× le tarif d’entrée de base (2× pour la variante d’1 heure), tandis qu’une lecture dans le cache coûte 0.1× sur la plupart des modèles, 0.05× sur Claude Opus 5.5 et Claude Sonnet 5.5, et 0.025× sur Claude Fable 5.1. Les écritures sont facturées avec une majoration ; les lectures bénéficient d’une remise de 90 % sur la plupart des modèles, de 95 % sur Opus 5.5 et Sonnet 5.5, et de 97.5 % sur Fable 5.1. (Le tarif de lecture de Sonnet 5.5 est passé de 0.1× à 0.05× le 7 octobre 2026.) Une seule lecture suffit déjà à compenser largement la majoration d’écriture valable pendant 5 minutes.

Claude Code gère le cache pour vous et, dans une session qui fonctionne normalement, presque tout ce renvoi volumineux est servi depuis le cache. Mais le cache expire après une période d’inactivité. En octobre 2026, Claude Code applique à votre conversation principale un cache d’une heure avec un abonnement, dans la limite de l’usage inclus dans votre forfait. Avec une API key, un cloud provider ou lorsque vous utilisez des crédits d’usage, le cache dure 5 minutes après la dernière utilisation (le réglage promptCacheTtl peut alors demander une durée d’une heure, avec un tarif d’écriture de 2×). Avec un cache de 5 minutes, si vous vous éloignez pour prendre un café et revenez plus tard, puis envoyez un message, le cache a expiré. Tout le préfixe accumulé est alors réécrit à 1.25× au lieu d’être lu au tarif du cache. Dans une session de 150K tokens, ce tour à froid écrit les 150K tokens à 1.25×, alors qu’un tour à chaud les aurait lus à 0.1× : l’écart est de 12.5 fois sur le préfixe (25 fois sur Opus 5.5 et Sonnet 5.5, 50 fois sur Fable 5.1). Il faut retenir ce résultat contre-intuitif : un rythme fait d’une période d’inactivité suivie d’une reprise peut coûter plus cher qu’un travail continu, car chaque période d’inactivité dépassant le TTL transforme le tour suivant d’une lecture peu coûteuse en une réécriture coûteuse. Travaillez par sessions concentrées ; avec un cache de 5 minutes, évitez d’alimenter une session volumineuse à raison d’un message toutes les dix minutes.

Si vous appelez l’API depuis votre propre application sur un VPS, rien de tout cela ne se produit automatiquement : vous devez activer le mécanisme avec cache_control. Le piège classique consiste à interpoler un timestamp ou un request ID dans le system prompt. Les octets du préfixe changent alors à chaque requête et le caching est désactivé silencieusement. L’indice est usage.cache_read_input_tokens qui reste à zéro sur des appels visiblement identiques.

La formule, avec un exemple détaillé

Ne tenez pas compte des chiffres qui annoncent qu’une « session coûte X $ » de manière forfaitaire. Le coût d’une session peut varier de deux ordres de grandeur. La formule à retenir est la suivante :

turn cost = (uncached input        x base input price)
          + (cache writes          x 1.25 x base input price)
          + (cache reads           x read multiplier x base input price)
          + (output incl. thinking x output price)

read multiplier = 0.10 on most models, 0.05 on Opus 5.5 and Sonnet 5.5, 0.025 on Fable 5.1
session cost = sum over all turns

Exemple détaillé avec Claude Opus 4.8, désormais un modèle ancien, mais toujours disponible et facturé, en octobre 2026, 5 $ par million de tokens d’entrée et 25 $ par million de tokens de sortie. Pour un tour au milieu d’une session, avec 80,000 tokens de contexte accumulé : 75,000 lus depuis le cache, 3,000 nouvellement écrits, 2,000 tokens d’entrée récents non mis en cache et 1,500 tokens de sortie, raisonnement compris.

• Lectures depuis le cache : 75,000 × 0.50 $/M = 0.0375 $
• Écritures dans le cache : 3,000 × 6.25 $/M = 0.019 $
• Entrée non mise en cache : 2,000 × 5 $/M = 0.010 $
• Sortie : 1,500 × 25 $/M = 0.0375 $

Environ 0.10 $ pour le tour ; cinquante tours de ce type coûtent environ 5 $. Considérons maintenant le même tour après expiration du cache : les 78,000 tokens pouvant être mis en cache sont réécrits au tarif de 6.25 $/M. Avec les mêmes 2,000 tokens d’entrée non mis en cache à 5 $/M, le total atteint environ 0.50 $ avant la sortie, soit environ cinq fois le coût du tour complet avec un cache encore valide, pour un travail identique. Cet écart résume à lui seul l’impact de la mise en cache. Avec Claude Opus 5.5 actuellement proposé à 4 $/20 $ (les lectures depuis le cache étant facturées à 0.05×), le même tour avec un cache valide coûte environ 0.07 $ (lectures : 0.015 $, écritures : 0.015 $, entrée non mise en cache : 0.008 $, sortie : 0.030 $). La version sans cache coûte 0.40 $ avant la sortie, soit près de six fois le coût du tour avec cache. Ces quatre lignes constituent également la seule méthode honnête pour comparer les fournisseurs, car les tarifs affichés ne tiennent compte ni des lectures depuis le cache ni du raisonnement. Leur exécution sur trois tâches réelles montre où se situe la facture Claude par rapport à celle d’OpenAI.

Si vous souhaitez comprendre l’unité de facturation elle-même plutôt que le coût d’un seul tour, ce que représentent un million de tokens en pages, fichiers et dollars reprend le même calcul à un niveau supérieur. Pour situer les ordres de grandeur, et non pour établir une prévision : selon les chiffres publiés par Anthropic pour les déploiements de Claude Code en entreprise, en octobre 2026, la moyenne est d’environ 13 $ par développeur et par jour d’activité, et de 150 $ à 250 $ par mois ; 90 % des utilisateurs restent sous 30 $ par jour. Le coût réel dépend du modèle choisi, de la gestion des sessions et de la taille de la base de code. C’est précisément pour cette raison que les leviers présentés ci-dessous sont importants.

Consulter votre propre consommation

Dans Claude Code, la commande est /usage (/cost fonctionne toujours, car il s’agit d’un alias). Le bloc Session, en haut de l’écran, affiche les statistiques de tokens et une estimation du coût calculée localement pour la session en cours. Avec les abonnements, le même écran affiche les barres correspondant aux limites du forfait ainsi qu’une ventilation de la consommation récente entre les skills, les sous-agents, les plugins et chaque serveur MCP. Dans les versions récentes, le bloc Session contient également une ligne Prompt cache (main). Elle indique la part des entrées servie depuis le cache, les échecs de cache et l’état actuel du cache. Pour connaître la facturation exacte des comptes API, consultez la page d’utilisation dans la Claude Console. La valeur affichée par la CLI est une estimation. /context affiche une grille colorée de ce qui occupe la fenêtre de contexte : prompt système, outils, définitions MCP, fichiers et historique. C’est le moyen le plus rapide de repérer un CLAUDE.md trop volumineux ou un serveur MCP trop bavard. En mode plein écran, la ventilation par élément est réduite. L’option all permet de la développer.

Avec l’API, chaque réponse indique exactement ce qui s’est produit :

response = client.messages.create(model="claude-sonnet-5-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

Notez que input_tokens correspond uniquement au reste non mis en cache. La taille réelle du prompt est la somme des trois champs d’entrée. Un agent qui a fonctionné pendant une heure et affiche input_tokens: 4000 n’est pas économique : les 200,000 autres tokens ont été servis depuis le cache. Pour estimer la consommation avant l’envoi, utilisez l’endpoint de comptage des tokens. Son appel est gratuit, il dispose de sa propre limite de débit et utilise le tokenizer du modèle que vous indiquez. Considérez le résultat comme une estimation proche : la facturation repose sur la requête réelle.

count = client.messages.count_tokens(model="claude-sonnet-5-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

N’utilisez jamais tiktoken, pour la raison indiquée plus haut.

Forfaits avec abonnement ou facturation à l’usage

Le fonctionnement décrit dans ce guide est identique partout ; seule la facturation change. Avec une clé API, Anthropic facture à l’usage, par token, selon les tarifs publiés. Chaque montant indiqué plus haut correspond donc à une dépense réelle. Le compteur démarre plus tôt que ne le pensent la plupart des utilisateurs, car il n’existe pas de free tier sur lequel compter : vous disposez seulement d’un petit crédit à l’inscription et de quelques endpoints gratuits. C’est ce qu’un nouveau compte API reçoit réellement avant l’ajout d’une carte bancaire. Depuis le 7 octobre 2026, l’exception concerne les abonnements Max et Team : ces forfaits incluent désormais des crédits API mensuels pour vos propres applications et agents sur la Claude Platform. Le montant est de $100 par mois avec Max 5x et de $200 avec Max 20x. Avec Team, il s’élève à $20 par siège Standard et $100 par siège Premium, avec un pool plafonné à $500. Vous les activez en associant une organisation Console. Les crédits inutilisés expirent à la fin de chaque cycle de facturation. Ils ne couvrent pas l’utilisation interactive de Claude Code.

Avec un abonnement Claude (Pro, Max, Team et anciens forfaits Enterprise facturés par siège), l’utilisation de Claude Code est déduite du quota inclus dans votre forfait. En octobre 2026, ce quota repose sur une fenêtre glissante de cinq heures et une fenêtre hebdomadaire. Il est partagé entre les modèles et avec le chat claude.ai. Le montant en dollars /usage est informatif et ne correspond pas à une facture. En octobre 2026, deux exceptions s’appliquent. Les sièges Enterprise actuels facturés à l’usage n’incluent aucun quota : chaque token est donc facturé aux tarifs API standard. Les modèles Fable ne sont pas inclus dans le quota avec Pro, les sièges Team Standard ou les anciens sièges Enterprise standard ; leur utilisation est facturée à l’usage au moyen de crédits.

Lorsque vous épuisez une fenêtre, le message « You've hit your session limit » ou « You've hit your weekly limit » s’affiche avec l’heure de réinitialisation. Changer de modèle avec /model ne rétablit pas l’accès, car les fenêtres sont partagées entre les modèles. Ces fenêtres dépendent du compte, et non du client utilisé. Cela est utile à savoir si vous cherchez encore ce qui s’exécute nativement sous Linux et quel forfait couvre chaque interface. La fenêtre réellement épuisée détermine la durée de l’attente et les actions utiles entre-temps. Il est donc préférable de connaître les options disponibles lorsque vous atteignez une limite au milieu d’une tâche. Les forfaits peuvent aussi activer des crédits d’usage, gérés avec /usage-credits, pour acheter de l’utilisation au-delà du quota.

Je n’indique volontairement pas les quotas des forfaits. Ce sont les valeurs les plus susceptibles de changer dans ce sujet. Consultez plutôt claude.com/pricing et vos propres /usage barres. Les mécanismes liés aux tokens restent importants avec un abonnement : une session inefficace consomme votre fenêtre exactement comme elle consommerait des dollars. Pour la partie consacrée aux abonnements, consultez le forfait Claude adapté à votre utilisation.

Les leviers qui fonctionnent réellement

• Limitez ce que l’agent lit. « Corriger le bug de validation dans auth.py » lit un fichier ; « améliorer cette base de code » en lit quarante. Gardez CLAUDE.md concis : il est chargé dans chaque session. Limitez-le à l’essentiel et déplacez les instructions propres au workflow dans des skills chargées à la demande.
• Soyez clair et concis. /clear entre deux tâches sans rapport, le contexte obsolète est renvoyé et refacturé à chaque message suivant. Dans une longue tâche, /compact Focus on the failing tests and the diff résume progressivement l’historique et vous évite de suivre une courbe quadratique.
• Choisissez un modèle adapté. Sonnet suffit pour la plupart des tâches de développement à $2/$10 par million de tokens en octobre 2026, désormais un tarif standard et non plus un tarif de lancement : Sonnet 5.5 coûte $2/$10, et Sonnet 5 a conservé ce tarif de $2/$10 après l’annulation de l’augmentation prévue le 1er septembre, à $3/$15. À titre de comparaison, Opus 5.5 coûte $4/$20. Haiku 5.5 coûte $0.10/$0.50 pour les prompts jusqu’à 100,000 tokens, puis $0.50/$2.50 au-delà ; il convient aux tâches mécaniques des sous-agents, comme le tri des journaux. Fable 5.1 se situe à l’autre extrémité, à $10/$50, le même tarif que Fable 5 et deux fois et demie celui d’Opus 5.5 pour les tokens entrants comme sortants. Vérifiez donc quelles tâches justifient réellement ce tarif avant de le laisser sélectionné pour les tâches courantes. /model permet de changer de modèle en cours de session.
• Préfiltrez les sorties verbeuses. Un hook qui réduit l’exécution des tests aux échecs avec grep avant que Claude ne la reçoive transforme 20,000 tokens de résultat d’outil en 300. Cette réduction s’applique aussi à chaque nouvel envoi de ce tour.
• Regroupez les tâches qui ne nécessitent pas d’interaction. Pour vos propres pipelines API, la classification, les revues en masse et les tâches nocturnes, l’API Batches exécute les mêmes modèles avec une remise de 50 %, en échange d’une livraison asynchrone.
• Tenez compte de la durée de vie du cache. Travaillez par sessions continues. Une session Claude Code détachée dans tmux sur un VPS ne coûte rien lorsqu’elle est inactive : les tokens ne sont consommés que pendant l’exécution d’un tour. En revanche, une période d’inactivité supérieure au TTL du cache fait perdre le cache préchargé, et le tour suivant doit payer la réécriture.

FAQ

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

Il n’y a pas de nombre fixe. Un seul tour en milieu de session contient souvent plusieurs dizaines de milliers de tokens de prompt, une fois les fichiers et l’historique accumulés. Une session de travail atteint rapidement plusieurs millions de tokens, dont la plupart sont servis depuis le cache à un dixième du tarif de base ou moins, selon le modèle. À titre de référence, les chiffres publiés par Anthropic pour les entreprises en octobre 2026 indiquent une moyenne d’environ $13 par développeur et par jour d’activité, avec 90% des utilisateurs sous $30. Exécutez /usage dans votre propre session ; cinq minutes de surveillance valent mieux que n’importe quelle moyenne publiée.

Les tokens de réflexion sont-ils facturés même lorsque je ne peux pas les voir ?

Oui. Les tokens de réflexion sont facturés comme des tokens de sortie, au tarif le plus élevé, et sont comptabilisés dans max_tokens. Les modèles actuels les facturent même lorsque l’interface n’affiche pas le résumé du raisonnement. Si une réponse s’interrompt avec stop_reason: "max_tokens" avant la fin de la réponse visible, la réflexion a probablement consommé le budget. Dans Claude Code, réduisez le niveau d’effort avec /effort pour les tâches qui ne nécessitent pas un raisonnement approfondi.

Pourquoi une longue session Claude Code devient-elle plus coûteuse à chaque message ?

Parce que l’API est sans état : à chaque tour, elle renvoie toute la conversation encore présente dans le contexte, chaque lecture de fichier, chaque résultat d’outil et chaque échange précédent qui n’a pas été supprimé lors de la compaction. Tout cela est facturé comme des tokens d’entrée. Le tour 50 transporte donc les tours 1 à 49. La mise en cache du prompt sert le préfixe répété à un dixième du tarif de base des entrées sur la plupart des modèles (5% pour Opus 5.5 et Sonnet 5.5, 2.5% pour Fable 5.1), mais le préfixe continue de grandir. En outre, toute période d’inactivité dépassant le TTL du cache transforme le tour suivant en une nouvelle transmission facturée au plein tarif. /compact réduit l’historique ; /clear le réinitialise.

Comment vérifier ma consommation de tokens et mon coût Claude ?

Dans Claude Code, /usage affiche les statistiques de tokens de la session, une estimation locale du coût et les barres indiquant les limites du forfait pour les abonnements (/cost est un alias) ; /context indique ce qui occupe la fenêtre de contexte. Pour consulter la facturation API faisant autorité, utilisez la page d’utilisation dans la Claude Console. Dans votre propre code, lisez response.usage. La somme de input_tokens, cache_creation_input_tokens et cache_read_input_tokens donne la taille réelle du prompt. Pour faire une estimation à l’avance, utilisez le endpoint count_tokens, jamais tiktoken.