Consommation de tokens LLM : pourquoi une réponse de 4 tokens en facture 217

Posez une question de maths d’une ligne à GPT-5.6 : 88 % de la facture de sortie correspond à du reasoning que vous ne verrez jamais. 10 tokens visibles, 81 facturés. Et GPT-5.6 fait partie des cas modérés. La même question a facturé 217 tokens de complétion pour une réponse de 4 tokens sur GLM 5.2, et 1 104 pour la réponse identique sur Qwen3.7-max. Ce n’est pas une anomalie : c’est ainsi que les modèles de reasoning facturent, par conception. Et c’est seulement la première d’une série de catégories de tokens que la plupart des dashboards de coûts ne détaillent jamais. Cet article dissèque un vrai objet usage, catégorie par catégorie, chiffres mesurés à l’appui.

TL;DR

• Par défaut, GPT-5.6 a facturé 81 tokens pour une réponse de 10 tokens, dont 88 % de reasoning ; GLM 5.2 est monté à 98 % et Qwen3.7-max à 99,3 %.
• Claude Sonnet 5 a facturé 114 tokens de thinking sur une réponse de 5 tokens, sans qu’aucun paramètre de thinking ait été envoyé.
• Cinq familles ont répondu faux sans thinking (399, 400, 427, 466, 467) ; seul GPT-5.6 a répondu juste sans, et tous les runs avec reasoning ont donné 401.
• Une écriture puis une lecture de cache Claude de 1 181 tokens ont coûté 0,01246 $ et 0,00566 $, exactement conformes aux tarifs affichés.

Ce qui a servi de test

Toutes les mesures de cet article reposent sur le même prompt single-turn, envoyé à chaque modèle avec ses réglages par défaut, sauf mention contraire sur une ligne :

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

La bonne réponse est 401 (333 multiples de 3, plus 200 multiples de 5, moins 66 comptés deux fois, soit 467 ; on retire les 66 multiples de 15 et il reste 401). Le choix est délibéré : la réponse visible est minuscule et fait 3 à 4 tokens sur tous les tokenizers, il n’y a qu’une seule bonne réponse — donc « est-ce que le raisonnement a payé » est vérifiable — et c’est juste assez difficile pour que les modèles aient envie de réfléchir, ce qui est précisément le comportement audité.

Les cinq classes de tokens sur votre facture

Une complétion moderne facture jusqu’à cinq classes de tokens différentes, à quatre tarifs différents. Un simple chiffre global de « tokens consommés » masque tout ça.

Les noms de champs ci-dessus correspondent au format compatible OpenAI. Claude regroupe les mêmes cinq classes sous ses propres noms : input_tokens et output_tokens, le thinking étant reporté dans output_tokens_details.thinking_tokens et facturé comme de l’output, et l’écriture cache encore découpée par TTL dans un objet cache_creation (ephemeral_5m_input_tokens à 1,25x, ephemeral_1h_input_tokens à 2x). Même anatomie, étiquettes différentes : ce problème de parsing revient dans une section plus loin.

Les cinq classes et leurs multiplicateurs de prix, avec les noms de champs compatibles OpenAI et Anthropic. Le chiffre de 88 % correspond à la part de reasoning mesurée pour GPT-5.6 dans l’exemple ci-dessus.

Voici l’objet réel derrière le chiffre affiché, GPT-5.6 en configuration par défaut répondant à la question de test :

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

C’est là que se joue l’arithmétique de facturation, et ça vaut la peine de la détailler une fois. La réponse reçue, c’est completion_tokens moins reasoning_tokens : 81 − 71 = 10 tokens, le mot « 401 » et son formatage. Les 71 autres tokens sont du chain-of-thought facturé au plein tarif output, soit 88 % de la facture de sortie, et sur GPT-5.6 vous ne pouvez en lire aucun. Chaque chiffre de « réponse visible » dans cet article est calculé de la même façon. Le ratio ne fait qu’empirer ailleurs : GLM 5.2 a répondu à la même question avec 217 completion tokens pour une réponse de 4 tokens. Un modèle de coût qui interprète completion_tokens comme « ce que le modèle a dit » se trompe donc d’un facteur 8x ici et 54x là.

Le raisonnement, c’est le budget, et il est pilotable

La même question d’une ligne, posée sur tous les réglages de « thinking » qu’acceptent les trois familles pilotables, via une seule gateway, le 2026-07-13/14 (au sein de chaque famille, les lignes vont du raisonnement le plus faible au plus élevé ; les valeurs par défaut des modèles phares des autres familles sont dans la section suivante) :

Quatre points à lire honnêtement dans ce tableau :

• Le levier est puissant là où il fonctionne. reasoning_effort: none a répondu correctement pour $0.000062, soit 8,5x moins que le défaut de luna, et sur des tâches plus difficiles on a mesuré 20x sur GLM 5.2. Le choix du tier fait partie du même levier : le modèle phare de GPT-5.6 a répondu à cette question sans raisonnement par défaut (section suivante), donc un modèle plus gros qui n’a pas besoin de réfléchir peut revenir moins cher qu’un plus petit qui doit le faire.
• Et quasi inerte là où il ne fonctionne pas. L’amplitude du réglage est une caractéristique de famille : monotone avec un écart de coût de 5x sur Sonnet 5 (84 à 249), faible et non ordonnée sur GPT-5.6, quasi inerte sur Qwen3.7-max (low consomme encore 974 tokens de raisonnement contre 1 096 pour le défaut), morte sur DeepSeek V4 Pro (267 contre 269).
• Les labels ne sont pas monotones et les défauts ne sont pas déterministes. Le high de GPT-5.6 a consommé moins de tokens que son medium ici ; le low de GLM a dépassé son high dans notre article précédent ; Sonnet 5 a réfléchi pendant 114 tokens sur une requête sans aucun paramètre de thinking ; et la même requête GLM par défaut a consommé 213 tokens de raisonnement lors d’un run et 1 312 lors d’un autre, un facteur six d’écart. Mesurez l’effet réel du réglage sur votre charge de travail ; ne le déduisez pas du label.
• Le « pas cher mais faux » est l’échec récurrent. Les deux familles qui ont répondu sans réflexion ici ont donné la mauvaise réponse (GLM 399, Sonnet 5 467) ; l’appel complet des cinq familles est dans la section suivante. Le raisonnement est un budget de justesse, et savoir si le couper est rentable dépend de la tâche, pas du modèle.

La règle pratique : traitez reasoning_tokens comme un poste de coût à part entière. Il est facturé au tarif de sortie, il éclipse régulièrement la réponse visible, et il réagit à des paramètres dont vous devez mesurer l’effet réel. Sur GPT-5.6, notez que les règles de tarification ont aussi changé ; le guide de coût GPT-5.6 couvre le surcoût d’écriture et l’exigence de clé de cache.

Peux-tu vraiment lire ce que tu as payé ?

« Séparé de la réponse » ne veut pas toujours dire caché, et la distinction mérite qu’on soit précis. Nous avons regardé les corps de réponse, pas seulement l’usage :

• GLM 5.2, DeepSeek, Qwen3.7-max et MiniMax renvoient le texte complet du raisonnement dans un champ reasoning_content à côté de la réponse (respectivement 3 987, 1 604, 2 509 et 581 caractères ici). Un développeur peut lire chaque token facturé ; les utilisateurs finaux ne le voient que si tu l’affiches, et la plupart des applications ne le font pas.
• GPT-5.6 ne livre pas la chaîne de raisonnement brute ; au mieux tu obtiens un résumé. La réponse peut porter un reasoning.summary rédigé par le modèle (359 caractères ici), mais les 91 tokens facturés correspondent au texte brut caché, pas au résumé. Ce qui s’en approche le plus est reasoning.encrypted_content : un blob chiffré que tu peux renvoyer pour assurer la continuité sur plusieurs tours, mais jamais déchiffrer. Les tokens que tu as payés sont dans ton propre corps de réponse, illisibles.
• Pour Claude, tout dépend de la façon dont tu demandes. Notre appel Sonnet 5 en adaptive-thinking a renvoyé un bloc thinking dont le texte était vide, alors que thinking_tokens facturait 114 : la preuve qu’il a réfléchi, mais rien à lire. Fable 5 s’est comporté pareil avec son mode always-on par défaut (59 facturés, bloc vide). Pourtant, le même Sonnet 5 appelé avec un budget de raisonnement explicite a renvoyé le vrai texte du raisonnement (73 tokens facturés, texte présent). C’est ta façon de demander qui décide de ce que tu peux voir.

La facturation est donc universelle, la visibilité non : chaque famille facture le raisonnement au tarif output, et ta capacité à auditer le texte acheté va de « en entier » à « résumé seulement » jusqu’à « un bloc vide signé ».

Quand le texte revient, tu peux le noter mécaniquement. Notre question comporte cinq résultats intermédiaires fixes (333, 200, 66, 467, 401), et chaque texte de raisonnement renvoyé les contenait tous : GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code et MiniMax M3 ont chacun livré une dérivation complète, tandis que les variantes low-effort ont laissé tomber une étape chacune. Pour qui a besoin du processus et pas seulement de la réponse, c’est là que se joue la différence : avec reasoning_content tu peux vérifier ce que tu as payé ; avec un résumé ou un bloc vide, tu dois le croire sur parole. Invisible Tokens, Visible Bills formalise ce déficit de traçabilité, et PALACE estime le raisonnement caché depuis l’extérieur.

La même question posée au meilleur modèle de chaque famille

Le tableau de pilotage utilisait des paliers précis pour montrer les réglages. Voici le tout dernier flagship de chaque famille sur la même question, en configuration par défaut :

Jetons de sortie facturés par modèle phare pour la même question (hachures orange = part de raisonnement ; vert = la réponse visible). L’astérisque sur MiniMax : son utilisation ne comporte aucun décompte de raisonnement, la part est donc reconstituée par soustraction, vérifiée par rapport au texte de raisonnement qu’il renvoie. La coche sur GPT-5.6 sol indique la seule exécution correcte sans raisonnement ; la croix sur Gemini 3.5 Flash indique la seule réponse erronée d’un modèle phare (466).

Tous les styles de reporting dans un seul graphique :

• Sept flagships sur huit ont répondu juste, à des prix radicalement différents pour le même 401. Qwen3.7-max a dépensé 1 096 tokens de reasoning, 22 secondes et 0,0084 $ ; le flagship de GPT-5.6 a dépensé zéro token de reasoning et 0,00031 $. Un écart de coût de 27x et un écart de latence de 7x pour une réponse juste identique : c’est le budget de reasoning rendu visible.
• MiniMax renvoie son texte de reasoning mais sans décompte. 260 tokens de complétion pour une réponse visible de 3 tokens : la réponse contient toute la dérivation dans reasoning_content, mais completion_tokens_details n’a aucune ligne de reasoning. Quand le décompte manque, reconstruis-le par soustraction : complétion moins tokens visibles donne ton nombre de tokens de sortie cachés.
• Gemini 3.5 Flash est l’exception : le seul flagship à répondre faux (466), avec 3 tokens de complétion et aucun décompte de reasoning nulle part. Son cousin 2.5 Flash a un jour passé 12,5 secondes à produire un 401 de 3 tokens sans que la facture n’explique pourquoi, et un run répété a répondu 427.
• C’est dans les paliers plus petits et avec le thinking désactivé que se trouvent les mauvaises réponses. GLM avec le thinking désactivé a répondu 399 ; Sonnet 5 désactivé a répondu 467 ; l’ancien qwen3-max n’a pas réfléchi du tout (3 tokens) et a répondu 400 ; Kimi K2.5, qui n’a pas de canal de reasoning, a raisonné à voix haute sur 144 tokens visibles facturés, a dérivé 401 dans sa propre prose, puis a conclu 400. Cinq familles, cinq mauvaises réponses différentes : 399, 400, 427, 466, 467 ; seul GPT-5.6 était correct sans reasoning.

Tokens de cache : deux directions, un facteur 12 d’écart

Le prompt caching sépare l’input en deux classes supplémentaires, et c’est l’écart de prix entre les deux qui justifie cette séparation : les écritures sont facturées à 1,25x le tarif input sur Claude (2x pour le TTL d’une heure), les lectures à 0,1x. Deux appels Opus 4.8 mesurés avec un system prompt de 1 181 tokens en cache ont coûté 0,01246 $ (écriture) puis 0,00566 $ (lecture), les deux se réconciliant avec les prix catalogue à la sixième décimale, la facturation côté input chutant d’environ 11x d’un appel à l’autre. Ce qui compte ici, c’est la comptabilité : si vous regroupez cache_creation_input_tokens et cache_read_input_tokens sous « input tokens », vous ne pouvez ni vérifier la réduction ni remarquer qu’elle cesse silencieusement de s’appliquer. Et elle cesse plus souvent que ne le laisse penser la doc : nos mesures de caching ont relevé des seuils effectifs de 1,4 à 2,4x au-dessus des minimums documentés, et le guide du prompt caching détaille la mécanique propre à chaque provider.

Pourquoi votre estimation locale ne colle jamais à la facture

On voit souvent le même schéma : estimer le coût côté client avec une lib de tokenizer, puis réconcilier plus tard. Trois raisons pour lesquelles les chiffres ne colleront pas :

• Les tokenizers diffèrent d’un fournisseur à l’autre. Compter du texte destiné à Claude avec un tokenizer OpenAI, c’est mesurer avec la mauvaise règle ; la même chaîne se tokenise différemment selon la famille.
• Vous facturez plus que votre message. Les system prompts et les schémas d’outils sont des input tokens sur chaque requête qui les transporte, et ils sont faciles à oublier dans une estimation locale.
• Le reasoning est imprévisible avant la réponse. Aucun comptage côté client ne peut prédire combien de thinking tokens un modèle va dépenser ; vous ne l’apprenez que dans le usage renvoyé.

L’objet usage renvoyé est le propre relevé de facturation de l’upstream, donc le compteur exact le moins cher consiste à arrêter d’estimer et à le lire. Le piège, c’est que chaque provider le structure différemment : les tokens en cache seuls apparaissent sous cached_tokens, prompt_cache_hit_tokens, total_cached_tokens ou cache_read_input_tokens selon la famille.

Les objets de détail n’ont pas non plus de schéma figé. La référence d’OpenAI documente quatre champs côté completion : reasoning_tokens, audio_tokens, et la paire Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens ; les rejected prediction tokens n’apparaissent jamais dans la sortie mais sont tout de même facturés comme des completion tokens. Côté prompt, la même structure ajoute text_tokens, audio_tokens et image_tokens à côté de cached_tokens ; GPT-5.6 ajoute cache_write_tokens, et on a déjà vu video_tokens dans la nature. Les fournisseurs l’étendent librement : Kimi K2.7 a renvoyé un completion_tokens_details.text_tokens non documenté, et Gemini compte séparément les thinking tokens et les tokens d’utilisation d’outils sous ses propres noms. Parsez défensivement : considérez les champs de détail inconnus comme attendus, et ne supposez jamais qu’un champ absent vaut zéro.

C’est là qu’un gateway prend tout son sens : Synthorai normalise tout ça dans un seul objet, avec reasoning_tokens et les deux directions de cache renseignés sur OpenAI, Anthropic, Gemini et les familles open-weight, de sorte qu’un seul parser couvre tous les modèles vers lesquels vous routez.

Passer de l’observation au blocage

Lire le registre, ce n’est que la moitié du travail. L’autre moitié consiste à rendre les dépassements impossibles plutôt que simplement visibles. Un tableau de bord de fin de mois signale une mauvaise surprise une fois l’argent parti, et un agent coincé dans une boucle de retry ne lit pas les tableaux de bord. Sur le gateway, chaque clé porte un quota avec un used_quota suivi et un plafond RPM, appliqués au moment de la requête : une clé qui épuise son budget reçoit une erreur explicite à la requête suivante, pas une facture plus salée trois semaines plus tard. L’attribution par requête (quelle clé, quel modèle, BYOK ou facturation plateforme) revient dans la même enveloppe de réponse, donc le coût par fonctionnalité tient dans un group-by, pas dans un chantier de reconstruction.

L’ordre des opérations découle des mesures : lire reasoning_tokens et les champs de cache avant d’optimiser quoi que ce soit, régler le curseur de raisonnement par tâche, et poser un quota strict sur chaque clé dont le mode de défaillance est une boucle. Pour voir ce que coûte un mix précis de modèles et de classes de tokens à votre volume, le cost optimizer le chiffre à partir des mêmes tarifs par token utilisés plus haut.

← Retour au blog