Le tokenizer Claude compte 30% de tokens en plus : ce que ça fait vraiment à ta facture

Depuis Claude Opus 4.7, Anthropic utilise un nouveau tokenizer qui découpe le même texte en environ 30% de tokens en plus. Le prix affiché au million de tokens n'a pas bougé. Ta facture, elle, monte. C'est une hausse de prix réelle qui ne ressemble pas à une hausse de prix, parce qu'elle ne passe pas par le tarif mais par l'unité de mesure.

Dit autrement : un million de tokens ne représente plus la même quantité de texte qu'avant. Le compteur tourne plus vite pour le même travail.

Anthropic ne le cache pas, c'est écrit noir sur blanc dans la doc. Mais personne ne t'envoie de mail quand une note de bas de page transforme ton budget mensuel. Voilà ce que ça change concrètement.

Le chiffre officiel : environ 30%, avec une fourchette de 0 à 35%

La doc pricing d'Anthropic est explicite : les modèles récents "utilisent un tokenizer plus récent qui contribue à leurs performances améliorées. Ce tokenizer produit environ 30% de tokens en plus pour le même texte. L'augmentation exacte dépend du contenu et de la forme de la charge de travail."

Le guide de migration donne la fourchette complète : le nouveau tokenizer "peut utiliser environ 1x à 1,35x plus de tokens", soit jusqu'à 35% de plus selon le contenu.

Traduit en volume de texte, ça donne l'ordre de grandeur le plus parlant : un million de tokens représente environ 555 000 mots avec le nouveau tokenizer contre 750 000 avec l'ancien. Même contexte de 1M, presque 200 000 mots en moins qui rentrent dedans.

La contrepartie annoncée est réelle : ce tokenizer participe aux meilleures performances des modèles. Le problème n'est pas qu'il existe, c'est qu'il est facturé sans que le tarif bouge.

Quels modèles sont concernés, lesquels sont épargnés

La ligne de fracture est nette : elle passe à Opus 4.7. Tout ce qui est sorti après utilise le nouveau tokenizer, tout ce qui est antérieur garde l'ancien.

Modèle	Tokenizer	Prix affiché (input / output)	Surcoût effectif estimé
Claude Opus 5	Nouveau	5 $ / 25 $ par MTok	+12 à +27% mesuré (OpenRouter)
Claude Opus 4.8	Nouveau	5 $ / 25 $ par MTok	+12 à +27% mesuré (OpenRouter)
Claude Opus 4.7	Nouveau	5 $ / 25 $ par MTok	+12 à +27% mesuré (OpenRouter)
Claude Opus 4.6	Ancien	5 $ / 25 $ par MTok	Référence, 0%
Claude Sonnet 5	Nouveau	2 $ / 10 $ jusqu'au 31 août 2026, puis 3 $ / 15 $	Neutre jusqu'au 31 août, puis +0 à 35%
Claude Sonnet 4.6	Ancien	3 $ / 15 $ par MTok	Référence, 0%
Claude Fable 5	Nouveau	10 $ / 50 $ par MTok	Prix x2 et tokens x1,3 vs Opus 4.6, soit environ 2,6x par unité de texte
Claude Mythos 5	Nouveau	10 $ / 50 $ par MTok	Idem Fable 5
Claude Haiku 4.5	Ancien	1 $ / 5 $ par MTok	Référence, 0%

Le cas Sonnet 5 mérite un arrêt. Anthropic l'a lancé à un tarif d'introduction de 2 $ / 10 $ valable jusqu'au 31 août 2026, avant de passer à 3 $ / 15 $. Ce tarif d'intro absorbe l'inflation du tokenizer et rend la migration à peu près neutre. Le 1er septembre, le prix rejoint celui de Sonnet 4.6 (3 $ / 15 $), mais avec un tokenizer qui produit environ 30% de tokens en plus que sur Sonnet 4.6. Même sticker, même modèle de facturation, facture plus lourde. La hausse est datée, elle est dans le calendrier.

Ce que ça donne en euros sur une facture réelle

Prenons une charge de travail concrète qui tourne sur Opus 4.6 : 200 millions de tokens en entrée et 20 millions en sortie par mois. Aux tarifs Opus de 5 $ / 25 $ par million, ça fait 1 000 $ d'input plus 500 $ d'output, soit 1 500 $.

Tu migres vers Opus 4.8. Même code, mêmes prompts, même trafic, même tarif affiché. À un ratio de 1,30, les mêmes textes deviennent 260M de tokens en entrée et 26M en sortie : 1 300 $ plus 650 $, soit 1 950 $. Tu paies 450 $ de plus par mois pour exactement le même travail, sans qu'aucune ligne de prix n'ait changé.

Sauf que la réalité est plus nuancée que ce calcul brut, et c'est la partie intéressante.

OpenRouter a analysé plus d'un million de requêtes de production en isolant une "cohorte de switchers" : les utilisateurs dont le modèle principal était Opus 4.6 avant la sortie de 4.7, et qui sont passés à 4.7 ensuite. Comparaison avant/après sur la même base d'utilisateurs, méthodologie propre.

Résultat en tokens natifs : le tokenizer 4.7 produit 32 à 34% de tokens en plus que 4.6 sur les prompts de production (10K tokens et plus), et jusqu'à 42 à 45% de plus sur les petits prompts.

Résultat en coût réel, une fois le cache pris en compte :

Moins de 2K tokens : -1,6% (ça coûte moins cher)
2K à 10K : +27,2%
10K à 25K : +25,2%
25K à 50K : +21,3%
50K à 128K : +11,9%
128K et plus : +15,3%

L'écart entre 32-45% de tokens en plus et 12-27% de coût en plus a un nom : le prompt caching. Sur les prompts de 128K et plus, 93% des tokens supplémentaires atterrissent dans le cache, et un hit de cache est facturé 10% du prix input standard. Les tokens en trop existent bien, mais ils sont facturés à 10 centimes sur l'euro. Si tu ne caches pas, tu prends les 30% en pleine face.

Le surcoût dépend massivement de ce que tu envoies

La moyenne à 30% cache des écarts énormes selon le type de contenu. Un test sur du contenu Claude Code réel donne un ratio moyen pondéré de 1,325x, avec cette dispersion :

Fichier CLAUDE.md : 1,445x
Prompt utilisateur : 1,373x
Article de blog en Markdown : 1,368x
Log de commits git : 1,344x
Sortie terminal : 1,291x
Stack trace Python : 1,250x
Diff de code : 1,212x

Sur du contenu synthétique, la fourchette s'élargit encore : 1,47x pour de la documentation technique, 1,20x pour de la prose anglaise, et seulement 1,01 à 1,13x pour du JSON, du CSV ou du chinois. Simon Willison mesure de son côté 1,42x sur de l'anglais, 1,33x sur de l'espagnol, 1,27x sur du Python et 1,01x sur du mandarin.

Autrement dit : si ton workload est du JSON structuré, tu ne verras presque rien. Si c'est de la doc technique, du Markdown et des gros fichiers de contexte, tu es dans le haut de la fourchette. Le pire profil possible, c'est précisément celui d'un agent de code avec un gros CLAUDE.md.

The Register, qui a couvert le sujet le 14 juillet 2026, ajoute la comparaison inter-vendeurs. Sur un fichier TypeScript de 2 888 caractères, le nouveau tokenizer Claude émet 1,73x plus de tokens que celui de GPT-5.x et 1,32x plus que l'ancien tokenizer Claude. Le même article note que sur du Rust, le ratio face à GPT-5.x monte à 1,58x, 1,52x en JavaScript et 1,50x en Python. Comparer les prix affichés entre Anthropic et OpenAI n'a donc plus beaucoup de sens : ce n'est pas la même unité.

Comment mesurer chez toi

Ne fais confiance à aucun pourcentage de cet article, y compris ceux d'Anthropic. Ton workload a son propre ratio, et l'écart entre 1,01x et 1,47x est trop large pour se contenter d'une moyenne. La bonne nouvelle : la mesure est gratuite.

L'endpoint /v1/messages/count_tokens renvoie le nombre de tokens sous le tokenizer du modèle que tu passes en paramètre. Il est gratuit, avec une limite de 2 000 à 8 000 requêtes par minute selon ton palier. La méthode officielle recommandée par Anthropic : compter la même requête deux fois, une fois avec ton modèle actuel, une fois avec le nouveau, puis comparer les deux input_tokens.

import anthropic

client = anthropic.Anthropic()

# Charge un échantillon représentatif de TON workload réel
with open("prompt_reel.txt") as f:
    prompt = f.read()

def count(model: str) -> int:
    resp = client.messages.count_tokens(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    return resp.input_tokens

ancien = count("claude-sonnet-4-6")   # ancien tokenizer
nouveau = count("claude-opus-4-8")    # nouveau tokenizer

print(f"Ancien   : {ancien} tokens")
print(f"Nouveau  : {nouveau} tokens")
print(f"Ratio    : {nouveau / ancien:.3f}x")
print(f"Surcoût  : {(nouveau / ancien - 1) * 100:.1f}%")

En une ligne de curl, si tu veux juste un ordre de grandeur :

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "content-type: application/json" \
  --header "anthropic-version: 2023-06-01" \
  --data '{
    "model": "claude-opus-4-8",
    "messages": [{"role": "user", "content": "Ton prompt ici"}]
  }'

Trois précautions qui comptent :

Mesure sur du contenu réel, pas sur un "Hello world". Le ratio dépend du contenu. Prends dix prompts sortis de tes logs de production, pas un exemple inventé.

Pondère par ton mix réel. Si 80% de ton volume est du JSON à 1,05x et 20% du Markdown à 1,37x, ton ratio effectif est autour de 1,11x, pas 1,30x.

Revois tes max_tokens. Le guide de migration est clair : il faut augmenter la marge sur max_tokens, y compris sur les déclencheurs de compaction, parce que la même réponse en texte occupe désormais plus de tokens. Et tout code qui estime les tokens côté client avec un ratio caractères/tokens fixe est à retester : il est faux depuis Opus 4.7.

Ce qu'il faut retenir

Le tarif affiché n'est plus un indicateur de coût fiable. Entre Opus 4.6 et Opus 4.8, le prix est identique (5 $ / 25 $) et la facture monte quand même de 12 à 27% selon la taille de tes prompts. Entre Anthropic et OpenAI, comparer les prix au million revient à comparer un prix au kilo et un prix à la livre.

Les trois actions concrètes, dans l'ordre :

Mesure ton ratio réel avec count_tokens sur tes vrais prompts. C'est gratuit et ça prend dix minutes.
Active le prompt caching si ce n'est pas déjà fait. C'est ce qui fait la différence entre +32% et +12% sur les gros contextes.
Si tu es sur Sonnet 5, note le 31 août 2026 dans ton agenda. Le tarif d'intro qui absorbe le tokenizer s'arrête ce jour-là, et ta facture prend mécaniquement 50% sur le prix affiché, avant même de compter le tokenizer.

Le reste, c'est de l'arbitrage. Les modèles à ancien tokenizer (Sonnet 4.6, Opus 4.6, Haiku 4.5) restent disponibles et facturent au même tarif avec moins de tokens. Sur les workloads où tu n'as pas besoin du gain de performance, ils sont devenus, mécaniquement, moins chers que les nouveaux.