Inflation de tokens : comment les passerelles te facturent 5 à 25× (+ un test de 20 lignes)

Toutes les API d’IA te facturent au token. Tu fais confiance à l’objet usage que renvoie la passerelle — prompt_tokens, completion_tokens — pour donner le vrai décompte. Or ce nombre est précisément la seule chose qu’un revendeur contrôle de bout en bout, et c’est l’endroit le plus facile pour te surfacturer en douce. Le nom poli de la manœuvre, c’est l’inflation de tokens : la passerelle rapporte plus de tokens que tu n’en as réellement envoyé ou reçu, et tu paies 5×, 10×, parfois 25× le coût honnête — que le modèle soit authentique ou non.

C’est exactement le travers contre lequel Brievio a été conçu, alors autant l’expliquer sans détour : comment fonctionne le rembourrage, un test de 20 lignes que tu peux lancer contre n’importe quelle passerelle (la nôtre comprise), et comment lire le résultat.

Ce qu’est vraiment l’inflation de tokens

Le décompte honnête, c’est celui que le fournisseur lui-même compterait pour tes messages — ton prompt système, ton contenu utilisateur, la réponse du modèle. Une passerelle digne de confiance le laisse passer tel quel. Une passerelle gonflée le rembourre. Même requête, facture très différente :

# Décompte honnête — le nombre correspond au texte que tu as envoyé, plus une
# infime surcharge de gabarit de chat (marqueurs de rôle, tokens de mise en forme) :
{"prompt_tokens": 24, "completion_tokens": 2, "total_tokens": 26}

# Gonflé — tu as envoyé ~20 tokens de texte mais on t'en facture 1 840 :
{"prompt_tokens": 1840, "completion_tokens": 2, "total_tokens": 1842}
#   ^ un prompt système d'environ 1 800 tokens que tu n'as jamais écrit a été
#     injecté dans la requête et te revient sur la facture. Sur une question d'un mot. À chaque appel.

L’astuce la plus courante, c’est le prompt système injecté en douce : le revendeur préfixe chaque appel de quelques centaines à quelques milliers de tokens de son propre texte — un préambule « de sécurité », un wrapper de routage, une fausse persona. Tu ne l’as jamais écrit, tu ne le vois pas, mais tu le paies à chaque requête. Aux tarifs d’entrée de Sonnet, un préfixe fantôme de 1 800 tokens représente environ $0.0055 de marge pure sur une question d’un mot. Multiplie par un million d’appels par mois.

Le test de 20 lignes

Tu n’as à croire personne sur parole — nous compris. Envoie un prompt dont tu connais la taille, puis compare ce que la passerelle t’a facturé avec ce que ton texte tokenise réellement sur ta propre machine :

# token_inflation_test.py
# Ta passerelle rapporte-t-elle des décomptes de tokens honnêtes ? Envoie un
# prompt dont tu connais la taille, puis compare les prompt_tokens rapportés par
# la passerelle au décompte d'un tokenizer local sur les messages EXACTS envoyés.
import tiktoken
from openai import OpenAI

client = OpenAI(api_key="sk-brievio-...", base_url="https://api.brievio.com/v1")

messages = [
    {"role": "system", "content": "You are a terse assistant."},
    {"role": "user", "content": "Reply with the single word: ok."},
]

# 1. Ce que la passerelle te facture :
resp = client.chat.completions.create(
    model="claude-sonnet-4-6", messages=messages, max_tokens=5,
)
reported = resp.usage.prompt_tokens

# 2. Ce que tes messages tokenisent réellement, en local :
enc = tiktoken.get_encoding("cl100k_base")   # une approximation — voir la note ci-dessous
local = sum(len(enc.encode(m["content"])) for m in messages)

print(f"gateway reported prompt_tokens: {reported}")
print(f"local token count of your text: {local}")
print(f"ratio: {reported / local:.1f}x")

# Normal    → ratio ~1.1-1.6x  (marqueurs de rôle + surcharge de gabarit de chat)
# Inflation → ratio 2x / 5x / 25x  (un prompt caché rembourre ton entrée)

Comment le lire : une petite surcharge fixe est normale — les formats de chat ajoutent une poignée de tokens pour les marqueurs de rôle et les délimiteurs de messages, donc un ratio autour de 1.1–1.6× sur un prompt minuscule est sain et se rapproche de 1.0× à mesure que ton prompt grandit. Un ratio de 2×, 5×, 25× n’est pas une erreur d’arrondi — c’est du rembourrage.

Une mise en garde honnête : le cl100k_base de tiktoken est le tokenizer d’OpenAI, et Claude ou Gemini tokenisent un peu différemment (typiquement à 10–20 % près). Traite donc le décompte local comme une approximation, pas comme un audit au token près. Il n’expliquera jamais un écart de 2×, et encore moins de 25× — pour un chiffre exact, utilise le tokenizer du fournisseur lui-même ou son endpoint count-tokens. Ce test est fait pour repérer l’inflation, pas pour chipoter sur un token de plus ou de moins.

Vérifie aussi la sortie et le cache

L’entrée est la cible habituelle, mais le même rembourrage peut se cacher dans les tokens de sortie et dans le cache. Deux autres vérifications rapides :

# La sortie et le cache peuvent aussi être rembourrés. Deux autres vérifs de 30 secondes :
#
# (a) Sortie : demande exactement un token et plafonne-le.
resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Reply with only: ok"}],
    max_tokens=2,
)
print(resp.usage.completion_tokens)   # honnête : ~1-2.  Rembourré : 50, 200, ...
#
# (b) Cache : envoie deux fois le même long préfixe en ~5 min. Le second appel
#     devrait facturer l'essentiel de l'entrée au tarif réduit de lecture de cache.
#     Si le champ "cached" est toujours 0, tu paies plein tarif sur les hits de cache.
print(resp.usage.prompt_tokens_details.cached_tokens)

Si tu demandes un token et qu’on t’en facture cinquante, ou si tes cached_tokens restent bloqués à zéro sur un appel répété à l’identique, le compteur est faussé.

D’où vient l’inflation

• Prompts système injectés. Un préambule wrapper ajouté à chaque requête — de loin la source la plus fréquente. Gros, invisible, facturé.
• Modèles « proxy à gabarit » ré-emballés. Ton prompt est fourré dans un grand gabarit fixe avant d’atteindre le modèle. Les tokens du gabarit sont de vrais tokens — pour le modèle comme pour ta facture — mais ils ne sont pas les tiens.
• Chiffres d’usage fabriqués. La version la plus grossière : l’objet usage ne correspond tout simplement pas à la réalité. Le test ci-dessus le démasque immédiatement.
• Rembourrage de sortie fantôme. Les completion_tokens rapportés dépassent le nombre de mots réellement renvoyés.

Rien de tout cela ne requiert un faux modèle. Une passerelle peut servir le vrai Claude et fausser quand même le compteur — l’authenticité du modèle et l’honnêteté de la facture sont deux promesses distinctes, et tu devrais vérifier les deux.

La référence honnête

Brievio laisse passer les décomptes de tokens du fournisseur sans les modifier, n’injecte rien dans tes requêtes, et journalise les vrais tokens d’entrée et de sortie ainsi que le coût exact à chaque appel, visibles dans ton tableau de bord d’usage. Lance le test ci-dessus contre Brievio et tu devrais voir reported ≈ local + petite surcharge — la façon dont cela devrait se lire partout. Notre page de tarifs affiche chaque modèle face à son tarif de référence officiel, pour que la remise soit auditable, et la documentation d’usage précise exactement quels champs nous renvoyons.

Si une passerelle est 80 % en dessous du tarif catalogue, la première question n’est pas « le modèle est-il authentique » — c’est « que dit le compteur ». Lance les 20 lignes. Cela coûte moins d’un centime, et c’est la due diligence la moins chère que tu feras jamais sur un fournisseur.