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

Posez une question de maths en une ligne à GPT-5.6 : 88 % du coût en sortie correspond à un raisonnement que vous ne verrez jamais. La réponse visible compte 10 tokens, mais 81 sont facturés. Et GPT-5.6 est encore un cas modéré. Pour la même question, GLM 5.2 a facturé 217 tokens de complétion pour une réponse de 4 tokens, et Qwen3.7-max en a facturé 1,104 pour une réponse identique. Ce n’est pas une anomalie : les modèles de raisonnement sont conçus pour facturer ainsi. C’est aussi la première des différentes classes de tokens que la plupart des tableaux de bord de coûts ne détaillent jamais. Cet article analyse un véritable objet usage, classe par classe, à partir de mesures réelles.

TL;DR

• Par défaut, GPT-5.6 a facturé 81 tokens pour une réponse de 10 tokens, dont 88 % de raisonnement ; cette part atteint 98 % sur GLM 5.2 et 99.3 % sur Qwen3.7-max.
• Claude Sonnet 5 a facturé 114 tokens de réflexion pour une réponse de 5 tokens, sans qu’aucun paramètre de réflexion soit envoyé.
• Cinq familles se sont trompées sans réflexion (399, 400, 427, 466, 467) ; seul GPT-5.6 a donné la bonne réponse sans raisonnement, tandis que toutes les exécutions avec raisonnement ont répondu 401.
• L’écriture puis la lecture d’un cache Claude de 1,181 tokens ont coûté $0.01246 et $0.00566, exactement comme le prévoient les tarifs publics.

Protocole de test

Toutes les mesures de cet article utilisent le même prompt en un seul tour, envoyé à chaque modèle avec ses réglages par défaut, sauf indication contraire dans le tableau :

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 les 66 comptés deux fois, soit 467 ; en retirant les 66 multiples de 15, il en reste 401. Ce choix est volontaire. La réponse visible est courte et stable, entre 3 et 4 tokens selon le tokenizer. Il n’existe qu’une seule bonne réponse, ce qui permet de vérifier si la réflexion a réellement servi. Enfin, le problème est juste assez difficile pour inciter les modèles à réfléchir, précisément le comportement que nous voulons mesurer.

Les cinq classes de tokens facturées

Une complétion moderne peut facturer jusqu’à cinq classes de tokens, selon quatre tarifs différents. Un simple total de « tokens consommés » masque toute cette structure.

Les noms de champs ci-dessus correspondent au format compatible OpenAI. Claude expose les mêmes cinq classes sous d’autres noms : input_tokens et output_tokens, la réflexion étant déclarée dans output_tokens_details.thinking_tokens et facturée comme sortie. L’écriture dans le cache est en outre ventilée par TTL dans un objet cache_creation : ephemeral_5m_input_tokens à 1.25x et ephemeral_1h_input_tokens à 2x. Même structure, autres libellés. Nous reviendrons plus loin sur ce problème de parsing.

Les cinq classes et leurs multiplicateurs tarifaires, avec les noms de champs compatibles OpenAI et Anthropic. Le chiffre de 88 % correspond à la part de raisonnement mesurée sur GPT-5.6 dans l’exemple précédent.

Voici l’objet réel à l’origine du chiffre annoncé : GPT-5.6 répondant à la question de test avec ses réglages par défaut.

{
  "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
}

Toute l’arithmétique de facturation se trouve ici. Le nombre de tokens de la réponse reçue correspond à completion_tokens moins reasoning_tokens : 81 − 71 = 10 tokens, soit le mot « 401 » et sa mise en forme. Les 71 autres tokens correspondent à la chaîne de raisonnement, facturée au plein tarif de sortie. Ils représentent 88 % du coût en sortie, sans qu’aucun d’eux soit lisible avec GPT-5.6. Tous les chiffres de « réponse visible » de cet article sont calculés de la même manière. Ailleurs, l’écart se creuse encore : GLM 5.2 a répondu à la même question avec 217 tokens de complétion pour une réponse de 4 tokens. Un modèle de coûts qui interprète completion_tokens comme « ce que le modèle a dit » se trompe donc d’un facteur 8 ici, et 54 là-bas.

Le raisonnement concentre le budget, et il se règle

Nous avons envoyé la même question en une ligne avec tous les réglages de réflexion acceptés par les trois familles configurables, via la même gateway, les 2026-07-13/14. Les lignes sont classées de la plus faible à la plus forte consommation de raisonnement au sein de chaque famille. Les modèles phares par défaut des autres familles figurent dans la section suivante.

Quatre conclusions à tirer de ce tableau :

• Quand ce réglage fonctionne, son effet est considérable. reasoning_effort: none a fourni la bonne réponse pour $0.000062, soit 8.5x moins que le réglage par défaut de luna. Sur des tâches plus difficiles, nous avons mesuré un facteur 20 sur GLM 5.2. Le choix du tier agit sur le même levier : le modèle phare GPT-5.6 a répondu ici sans aucun raisonnement par défaut, comme le montre la section suivante. Un modèle plus gros qui n’a pas besoin de réfléchir peut donc coûter moins cher qu’un modèle plus petit qui raisonne.
• Sur d’autres familles, le réglage agit à peine. L’amplitude dépend de la famille : elle est monotone avec un coût multiplié par 5 sur Sonnet 5, de 84 à 249 tokens ; faible et non ordonnée sur GPT-5.6 ; presque nulle sur Qwen3.7-max, où low consomme encore 974 tokens de raisonnement contre 1,096 par défaut ; et inexistante sur DeepSeek V4 Pro, avec 267 contre 269.
• Les niveaux ne sont pas monotones, et les réglages par défaut ne sont pas déterministes. Ici, le niveau high de GPT-5.6 a consommé moins de tokens que medium. Dans notre article précédent, le niveau low de GLM dépassait high. Sonnet 5 a réfléchi pendant 114 tokens alors que la requête ne contenait aucun paramètre de réflexion. Enfin, deux requêtes GLM identiques avec les réglages par défaut ont consommé respectivement 213 et 1,312 tokens de raisonnement, soit un rapport de six. Mesurez l’effet réel du réglage sur votre charge de travail ; son libellé ne suffit pas.
• Économiser au prix d’une mauvaise réponse est un échec récurrent. Les deux familles testées ici sans réflexion se sont trompées : GLM a répondu 399 et Sonnet 5, 467. La liste complète des cinq familles figure dans la section suivante. Le raisonnement est un budget de fiabilité. Le bénéfice de sa réduction dépend de la tâche, pas du modèle.

La règle pratique est simple : traitez reasoning_tokens comme un poste de coût à part entière. Ces tokens sont facturés au tarif de sortie, dépassent régulièrement la taille de la réponse visible et dépendent de paramètres dont l’effet réel doit être mesuré. Pour GPT-5.6, les règles tarifaires ont aussi changé ; le guide des coûts de GPT-5.6 détaille la majoration à l’écriture et l’obligation d’utiliser une clé de cache.

Peut-on lire ce que l’on paie ?

« Séparé de la réponse » ne veut pas toujours dire « masqué ». Nous avons inspecté le corps des réponses, pas seulement les données d’usage :

• GLM 5.2, DeepSeek, Qwen3.7-max et MiniMax renvoient l’intégralité du raisonnement dans un champ reasoning_content à côté de la réponse, soit respectivement 3,987, 1,604, 2,509 et 581 caractères ici. Un développeur peut lire chaque token facturé. L’utilisateur final ne le voit que si l’application l’affiche, ce que la plupart ne font pas.
• GPT-5.6 masque la chaîne de raisonnement brute ; seul un résumé peut être obtenu. La réponse peut contenir un reasoning.summary rédigé par le modèle, de 359 caractères dans notre test. Les 91 tokens facturés correspondent toutefois au texte brut masqué, pas au résumé. Le seul élément qui s’en rapproche est reasoning.encrypted_content : un bloc chiffré que vous pouvez renvoyer au modèle pour préserver la continuité entre plusieurs tours, mais que vous ne pouvez jamais déchiffrer. Les tokens payés se trouvent donc dans votre propre réponse, mais restent illisibles.
• Avec Claude, tout dépend de la façon dont la requête est formulée. Notre appel à Sonnet 5 avec réflexion adaptative a renvoyé un bloc thinking vide, tout en facturant 114 thinking_tokens : le modèle a bien réfléchi, mais rien n’est lisible. Fable 5 a eu le même comportement avec sa réflexion toujours active par défaut : 59 tokens facturés, bloc vide. En revanche, le même Sonnet 5 appelé avec un budget de raisonnement explicite a renvoyé le texte réel de sa réflexion : 73 tokens facturés, texte présent. La formulation de la requête détermine donc ce qui reste visible.

La facturation est uniforme, mais pas la visibilité : toutes les familles facturent le raisonnement au tarif de sortie. Selon le modèle, le texte acheté est disponible intégralement, réduit à un résumé ou remplacé par un bloc vide signé.

Lorsque le texte est renvoyé, il peut être évalué automatiquement. Notre question comporte cinq résultats intermédiaires fixes : 333, 200, 66, 467 et 401. Tous figuraient dans chaque raisonnement renvoyé. GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code et MiniMax ont chacun fourni une démonstration complète, tandis que les variantes à faible effort omettaient chacune une étape. Pour ceux qui ont besoin du raisonnement et pas uniquement de la réponse, la distinction est nette : avec reasoning_content, vous pouvez vérifier ce que vous avez payé ; avec un résumé ou un bloc vide, vous devez faire confiance au modèle. Tokens invisibles, factures bien visibles formalise ce déficit de traçabilité, tandis que PALACE estime de l’extérieur le raisonnement masqué.

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

Le tableau précédent utilisait des tiers précis afin d’illustrer les différents réglages. Voici maintenant le modèle phare le plus récent de chaque famille, avec les réglages par défaut, sur la même question :

Tokens de sortie facturés par modèle phare pour la même question (orange hachuré : part du raisonnement ; vert : réponse visible). L’astérisque sur MiniMax indique que ses données d’usage ne contiennent aucun décompte du raisonnement. La part est donc reconstituée par soustraction, puis vérifiée à l’aide du texte de raisonnement renvoyé. La coche sur GPT-5.6 sol signale la seule exécution correcte sans raisonnement ; la croix sur Gemini 3.5 Flash, la seule mauvaise réponse parmi les modèles phares, soit 466.

Ce graphique rassemble tous les modes de reporting :

• Sept modèles phares sur huit ont répondu correctement, à des coûts très différents pour le même résultat, 401. Qwen3.7-max a consommé 1,096 tokens de raisonnement, 22 secondes et $0.0084. Le modèle phare GPT-5.6 n’a consommé aucun token de raisonnement et a coûté $0.00031. Pour une réponse correcte identique, le coût varie d’un facteur 27 et la latence d’un facteur 7. Le budget de raisonnement devient ici directement visible.
• MiniMax renvoie le texte de son raisonnement, mais pas son nombre de tokens. La réponse compte 260 tokens de complétion pour seulement 3 tokens visibles. Le corps contient toute la démonstration dans reasoning_content, mais completion_tokens_details ne comporte aucune ligne dédiée au raisonnement. En l’absence de ce décompte, il faut le reconstituer par soustraction : tokens de complétion moins tokens visibles égale le volume de sortie masqué.
• Gemini 3.5 Flash fait exception : c’est le seul modèle phare à s’être trompé, avec 466, 3 tokens de complétion et aucun décompte du raisonnement. Son modèle apparenté 2.5 Flash avait déjà passé 12.5 secondes à produire une réponse 401 de 3 tokens, sans que la facture n’explique pourquoi. Une nouvelle exécution avait ensuite répondu 427.
• Les mauvaises réponses se concentrent sur les petits tiers et lorsque la réflexion est désactivée. GLM sans réflexion a répondu 399 ; Sonnet 5 avec réflexion désactivée, 467 ; l’ancien qwen3-max n’a pas réfléchi du tout, avec 3 tokens, et a répondu 400 ; Kimi K2.5, qui ne possède pas de canal de raisonnement, a raisonné à voix haute dans 144 tokens visibles et facturés, a obtenu 401 dans sa propre démonstration, puis a conclu 400. Cinq familles, cinq mauvaises réponses différentes : 399, 400, 427, 466 et 467. Seul GPT-5.6 a répondu correctement sans raisonnement.

Tokens de cache : deux sens, un écart de prix de 12x

Le prompt caching divise l’entrée en deux classes supplémentaires. Leur écart de prix justifie cette distinction : avec Claude, les écritures sont facturées à 1.25x le tarif d’entrée, ou 2x pour un TTL d’une heure, tandis que les lectures le sont à 0.1x. Deux appels mesurés sur Opus 4.8 avec un system prompt mis en cache de 1,181 tokens ont coûté $0.01246 pour l’écriture, puis $0.00566 pour la lecture. Les deux montants correspondent aux tarifs publics à la sixième décimale près, et le coût d’entrée a été divisé par environ 11 entre les deux appels. Du point de vue comptable, regrouper cache_creation_input_tokens et cache_read_input_tokens sous une même catégorie « tokens d’entrée » empêche aussi bien de vérifier la remise que de détecter sa disparition silencieuse. Or elle disparaît plus souvent que ne le suggère la documentation : nos mesures du cache ont relevé des seuils effectifs 1.4 à 2.4x supérieurs aux minimums documentés. Le guide du prompt caching détaille le fonctionnement propre à chaque fournisseur.

Pourquoi votre estimation locale ne correspond jamais à la facture

Une pratique courante consiste à estimer le coût côté client avec une bibliothèque de tokenization, puis à rapprocher les chiffres après coup. Ils ne correspondront pas, pour trois raisons :

• Chaque fournisseur utilise ses propres tokenizers. Compter un texte destiné à Claude avec un tokenizer OpenAI revient à utiliser la mauvaise unité de mesure. Une même chaîne est tokenisée différemment par chaque famille.
• La facture couvre plus que votre message. Les system prompts et les schémas d’outils comptent comme tokens d’entrée à chaque requête qui les contient. Une estimation locale les oublie facilement.
• Le volume de raisonnement reste imprévisible jusqu’à la réponse. Aucun calcul côté client ne peut prévoir le nombre de tokens de réflexion qu’un modèle utilisera. Seul l’objet usage renvoyé permet de le connaître.

L’objet usage renvoyé constitue le relevé de facturation du fournisseur. Le moyen le moins coûteux d’obtenir un comptage exact est donc d’arrêter les estimations et de lire cet objet. Chaque fournisseur le structure cependant à sa manière : selon la famille, les seuls tokens en cache apparaissent sous les noms cached_tokens, prompt_cache_hit_tokens, total_cached_tokens ou cache_read_input_tokens.

Les objets de détail ne suivent pas non plus un schéma immuable. La référence OpenAI documente quatre champs côté complétion : reasoning_tokens, audio_tokens, ainsi que les deux champs de Predicted Outputs, accepted_prediction_tokens et rejected_prediction_tokens. Les tokens de prédiction rejetés n’apparaissent jamais dans la sortie, mais restent facturés comme tokens de complétion. Côté prompt, le même format ajoute text_tokens, audio_tokens et image_tokens à côté de cached_tokens. GPT-5.6 ajoute cache_write_tokens, et nous avons déjà rencontré video_tokens en production. Les fournisseurs étendent librement ce schéma : Kimi K2.7 a renvoyé un champ non documenté completion_tokens_details.text_tokens, tandis que Gemini compte séparément les tokens de réflexion et d’utilisation des outils, sous ses propres noms. Le parsing doit être défensif : prévoyez des champs de détail inconnus et ne considérez jamais qu’un champ absent vaut zéro. Les champs audio suivent aussi leur propre modèle économique : nous avons mesuré séparément le coût de la transcription audio par minute audio facturée sur sept modèles ASR spécialisés.

C’est précisément là qu’une gateway devient utile : Synthorai normalise tous ces formats dans un seul objet. Les champs reasoning_tokens et les deux sens du cache sont renseignés pour OpenAI, Anthropic, Gemini et les familles open weight. Un seul parser suffit ainsi pour tous les modèles vers lesquels vous routez vos requêtes.

Observer les coûts, puis les bloquer

Lire le relevé ne suffit pas. Il faut aussi rendre les dépassements impossibles, au lieu de simplement les constater. Les tableaux de bord mensuels signalent une anomalie une fois l’argent dépensé, et un agent bloqué dans une boucle de retry ne les consulte pas. Au niveau de la gateway, chaque clé possède un quota, un compteur used_quota et une limite de RPM, tous appliqués au moment de la requête. Lorsqu’une clé épuise son budget, la requête suivante reçoit une erreur explicite, plutôt qu’une facture plus élevée trois semaines plus tard. Les données d’attribution par requête, clé utilisée, modèle appelé, facturation BYOK ou plateforme, reviennent dans la même enveloppe de réponse. Le coût par fonctionnalité s’obtient alors avec un simple group-by, sans travail de reconstitution.

Les mesures conduisent à un ordre d’action clair : commencez par lire reasoning_tokens et les champs de cache, réglez le niveau de raisonnement pour chaque tâche, puis imposez un quota strict à toute clé susceptible de partir en boucle. Pour calculer le coût d’un mix précis de modèles et de classes de tokens à votre volume, l’optimiseur de coûts applique les mêmes tarifs par token que ceux utilisés ci-dessus.

← Retour au blog