Comment mesurer la consommation de tokens d'un agent IA

Comment mesurer la consommation de tokens de votre agent de codage IA ?

Vous mesurez la consommation de tokens de votre agent de codage IA en lisant les comptes d'input/output tokens que chaque API de modèle renvoie déjà, en les attribuant aux quatre éléments qui les génèrent — les lectures de fichiers, les sorties d'outils, le manifeste MCP et le rejeu du transcript — puis en convertissant les tokens en dollars à l'aide du prix par million de tokens publié par le modèle. Tout le reste n'est que décoration. Si vous savez produire ces chiffres par session, vous pouvez trouver votre gaspillage en une après-midi. J'ai passé des années à faire de la recherche en IA avant de me lancer dans l'outillage autour des tokens, et l'erreur la plus courante que je vois, c'est des gens qui optimisent un chiffre qu'ils n'ont en réalité jamais regardé. Ils sentent que la facture est trop élevée, ils « rognent un peu le contexte », et ils n'ont aucune idée de savoir si ça a marché. Donc avant toute discussion sur l'optimisation, donnons-vous un vrai compteur. Ceci est le pendant « mesure » de Comment réduire la consommation de tokens d'un agent de codage IA — à lire ensuite une fois que vous voyez vos chiffres.

Qu'est-ce que vous mesurez exactement ?

Vous mesurez quatre quantités distinctes, et les confondre est la première erreur : les input tokens, les output tokens, les tokens mis en cache (cache read) et le coût en dollars auquel ils correspondent. Ils ne sont pas interchangeables, parce qu'ils sont tarifés très différemment. Un token est l'unité dans laquelle un modèle facture — environ 3 à 4 caractères d'anglais, produits par le tokenizer du modèle. Pour les agents de codage, trois choses comptent :

Les input tokens sont tout ce que vous envoyez au modèle à un tour donné : le system prompt, les définitions d'outils, tout l'historique de la conversation, et toute sortie de fichier ou de commande qui s'y trouve déjà. C'est presque toujours le coût dominant pour les agents.
Les output tokens sont ce que le modèle génère en retour. Ils sont tarifés plus cher par token — parfois 5x — mais il y en a généralement bien moins.
Les cache read tokens sont des input tokens servis depuis le prompt caching. Ils sont facturés à environ 10 % du tarif input normal, ce qui explique pourquoi un taux de cache-hit élevé change discrètement toute votre économie.

L'input domine à cause du fonctionnement des boucles agentiques : à chaque étape, l'agent renvoie tout le transcript jusqu'ici. Un fichier de 6 000 tokens que vous avez lu au tour 2 est re-facturé en input aux tours 3, 4, 5, et ainsi de suite. Cette re-facturation est invisible si vous regardez seulement « quelle était la taille de ce fichier » — et évidente dès l'instant où vous regardez les totaux d'input par tour grimper au fil d'une session.

D'où viennent réellement les chiffres ?

Les chiffres viennent de la réponse de l'API elle-même — vous n'avez pas besoin d'estimer. Chaque grand fournisseur renvoie un objet usage à chaque complétion. L'API Messages d'Anthropic renvoie usage avec input_tokens, output_tokens, cache_creation_input_tokens et cache_read_input_tokens (référence API). L'API d'OpenAI renvoie un objet usage avec prompt_tokens, completion_tokens et total_tokens (référence API). Ce sont les valeurs de référence — exactement les comptes qui vous sont facturés. Il y a trois endroits où les lire, par ordre croissant d'effort et de précision :

Le dashboard du fournisseur. La Console Anthropic et la page usage d'OpenAI affichent toutes deux les totaux de tokens et de dollars par jour et par clé API. Zéro configuration, mais grossier : vous obtenez un agrégat quotidien, pas « quelle session, quel fichier, quel outil ».
Le compteur propre à l'agent. Claude Code affiche un compteur de tokens/coût en continu par session ; Cursor expose l'usage dans ses réglages. Bon pour un contrôle au feeling, faible pour l'attribution — ils vous disent rarement ce qui a dépensé les tokens.
Le champ usage, journalisé par appel. C'est le vrai compteur. Si vous pouvez intercepter chaque appel de modèle et ajouter son usage à un journal avec un libellé (quelle session, quelle étape), vous pouvez répondre à toutes les questions qui comptent. C'est exactement ce que fait un dashboard d'économies pour vous.

Si vous voulez une estimation rapide hors ligne avant qu'un appel ne parte — par exemple pour dimensionner un prompt — un compteur de tokens tokenisera le texte localement pour que vous voyiez le compte sans rien dépenser.

Comment transformer les tokens en dollars ?

Vous transformez les tokens en dollars en multipliant chaque classe de tokens par son prix par million de tokens (MTok) et en additionnant. La formule est ennuyeuse et exacte :

cost = (input_tokens × input_price_per_MTok / 1_000_000)
+ (cache_read_tokens × input_price_per_MTok × 0.10 / 1_000_000)
+ (output_tokens × output_price_per_MTok / 1_000_000)

Voici les prix actuellement publiés pour les modèles sur lesquels tournent la plupart des agents de codage, en input / output par MTok :

Modèle	Input	Output
Claude Opus 4.8	$5	$25
Claude Sonnet 4.6	$3	$15
Claude Haiku 4.5	$1	$5
GPT-5.5	$5	$30

Les cache reads sont facturés à ≈10 % du tarif input, ce qui est la principale raison pour laquelle le coût mesuré et les « tokens envoyés » divergent. Deux sessions qui envoient le même nombre d'input tokens peuvent différer de 9x en coût selon le taux de cache-hit. Si vous faites l'arithmétique à la main sur les sessions d'une journée, un calculateur de coût de tokens LLM fera la multiplication par modèle à votre place ; pour le tableau tarifaire plus large, voyez notre analyse des coûts en tokens des agents de codage IA et de la tarification des tokens des API LLM. Un exemple chiffré. Disons qu'une seule tâche agentique a tourné sur 18 tours avec Sonnet 4.6, et que vos journaux totalisent 2,4M d'input tokens, dont 1,6M étaient des cache reads, plus 40K output tokens :

Input non mis en cache : 0,8M × $3 = $2.40
Input mis en cache : 1,6M × $3 × 0,10 = $0.48
Output : 0,04M × $15 = $0.60
Total : $3.48 pour une tâche.

Ce chiffre de 2,4M d'input est révélateur. Quarante mille output tokens signifient que le modèle a écrit peut-être 300 lignes de code — mais il a lu l'équivalent d'un petit roman, la plupart du temps les mêmes fichiers renvoyés à chaque tour. Vous savez maintenant exactement où regarder.

Comment attribuer l'usage aux quatre facteurs de coût ?

Vous attribuez l'usage en libellant chaque appel journalisé avec ce qu'il a fait, puis en regroupant. Les tokens en agrégat vous disent que vous avez un problème ; les tokens par catégorie vous disent lequel. Les quatre paniers, et comment repérer chacun dans vos journaux : Les lectures de fichiers. Regardez le saut d'input tokens aux tours où l'agent a appelé un outil de lecture/fichier. Un fichier source de 500 lignes fait environ 5 000 à 7 000 tokens ; si vous en voyez une douzaine tôt dans une session, c'est votre facture de récupération — et elle est re-facturée à chaque tour ultérieur. La solution est de lire moins en cherchant d'abord ; voyez la semantic code search. Les sorties d'outils. Surveillez la croissance d'input juste après les commandes shell. Un npm test en échec peut déverser 15 000 tokens de stack traces alors que l'agent avait besoin d'environ 50 — le nom du test en échec et l'assertion. Ce delta est du pur gaspillage et le cas d'école de l'output filtering. Le manifeste MCP. Celui-ci est sournois parce qu'il n'a pas de tour déclencheur évident — c'est une taxe constante. Chaque serveur MCP connecté re-annonce le schéma complet de ses outils à chaque tour, utilisé ou non. Mesurez-le en comptant les input tokens sur un tour où l'agent n'a fait que réfléchir : ce plancher est en grande partie votre manifeste. Charger les définitions d'outils en lazy-loading en supprime l'essentiel. Le rejeu du transcript. Tracez les input tokens par tour au fil d'une session. Si la courbe grimpe régulièrement alors que le travail n'avance pas, vous payez la taxe du context window — re-facturer d'anciennes lectures à l'infini. C'est aussi pourquoi le context engineering et une context compression disciplinée comptent plus que n'importe quel prompt rogné isolé. Une fois que chaque tour porte un libellé, un group-by de cinq lignes vous donne la répartition en pourcentage. En pratique, c'est déséquilibré : pour la plupart des agents que j'ai profilés, les lectures de fichiers plus les sorties d'outils non filtrées écrasent tout le reste.

Comment mettre en place un vrai compteur dès aujourd'hui

Choisissez l'option la plus légère qui répond à votre vraie question, puis n'escaladez que si vous avez besoin d'attribution :

Contrôle quotidien au feeling (5 minutes). Ouvrez le dashboard de votre fournisseur, notez la dépense et le total de tokens du jour. Faites-le pendant une semaine pour apprendre votre référence. Si le chiffre ne vous dérange pas, arrêtez-vous ici — l'optimisation prématurée est réelle.
Totaux par session (30 minutes). Encapsulez le client API de votre agent et journalisez l'objet usage après chaque appel avec un ID de session. Additionnez par session. Vous verrez immédiatement quels types de tâches sont coûteux.
Attribution par catégorie (une après-midi). Ajoutez le nom de l'outil / le type de tour à chaque ligne de journal et regroupez par ce critère. C'est là que vous trouvez la surprise — presque toujours soit des lectures trop hâtives, soit des sorties non filtrées.
Convertir en dollars. Appliquez la formule ci-dessus pour raisonner en argent, pas en tokens abstraits. L'argent rend les arbitrages évidents, pour vous comme pour quiconque à qui vous rendez compte.

Si vous préférez ne pas construire et maintenir cela, c'est littéralement pour ça que j'ai créé Tokenade. Il se place devant Claude Code, Cursor, Codex, Copilot, Windsurf et les autres, journalise l'usage de chaque appel, l'attribue aux quatre facteurs, et affiche le chiffre en dollars sur un dashboard d'économies — tout en réduisant aussi le gaspillage via la semantic code search, l'output filtering, la skeleton compression et le chargement MCP en lazy-loading. Le palier Free couvre jusqu'à ≈10M de tokens par mois ; Pro est à 19,90 €/mois (hors taxes), postes illimités. C'est source-available sous licence MIT, vous pouvez donc lire exactement comment le compteur calcule chaque chiffre — je préfère que vous fassiez confiance à l'arithmétique plutôt qu'à mon marketing.

Ce qui tourne mal quand on mesure les tokens

L'échec le plus courant est de mesurer des totaux sans attribution, puis d'« optimiser » à l'aveugle. Voici les pièges, et comment éviter chacun :

Compter l'output, ignorer l'input. L'output est le chiffre visible et gratifiant — le code que l'agent a écrit. Il est généralement une erreur d'arrondi à côté de l'input. Si votre dashboard met en avant les output tokens, il mesure la mauvaise chose.
Ignorer complètement le cache. Deux sessions d'apparence identique peuvent coûter 9x différemment sur le seul taux de cache-hit. Tout compteur qui ne détaille pas cache_read_input_tokens vous induira en erreur sur l'endroit où part l'argent. Comprenez le prompt caching avant de faire confiance à un total.
Estimer avec le mauvais tokenizer. Les heuristiques par comptage de caractères (« ÷4 ») conviennent pour un ordre de grandeur mais dérivent sur le code, le JSON et le texte non anglais. Quand le chiffre doit être juste, lisez le usage de l'API, n'estimez pas depuis un autre tokenizer.
Mesurer un appel au lieu de la session. Ce qui coûte cher avec les agents, c'est le rejeu au fil des tours, pas un appel isolé. Une vue par appel cache l'effet de cumul. Additionnez toujours la session.
Confondre tokens et rate limits. Atteindre une limite de débit est un problème de throughput, pas un problème de coût. Sur le moment ils se ressemblent et nécessitent des solutions complètement différentes.

Mesurez honnêtement et le travail d'optimisation se planifie pratiquement tout seul : vous verrez une grosse barre dans le graphique d'attribution, et vous saurez précisément quel levier actionner en premier.

À voir aussi :