Le nouveau tokenizer de Claude Opus 4.7 peut-il rendre vos prompts plus chers ?

Claude Opus 4.7 en donne un exemple très concret. Dans sa documentation, Anthropic indique que son nouveau tokenizer peut utiliser environ 1x à 1,35x autant de tokens lors du traitement de texte que les modèles précédents, soit jusqu’à environ 35 % de plus, avec une variation selon le contenu. La même documentation précise aussi que /v1/messages/count_tokens renverra un nombre de tokens différent pour Claude Opus 4.7 et Claude Opus 4.6.

La réponse courte : oui, mais pas forcément de 35 %

Le bon résumé est le suivant : un nouveau tokenizer peut augmenter le nombre de tokens d’entrée pour un prompt identique. Si le prix par token d’entrée reste le même, la partie « input » de la facture peut donc augmenter.

Mais il ne faut pas transformer le chiffre de 35 % en règle universelle. Anthropic parle d’une fourchette d’environ 1x à 1,35x et précise que l’écart varie selon le contenu. Autrement dit, certains prompts peuvent presque ne pas bouger, d’autres augmenter davantage, mais on ne peut pas conclure que tous les prompts seront automatiquement 35 % plus chers.

Il faut aussi distinguer le coût des tokens d’entrée de la facture totale. La page de prix de Claude sépare les Base Input Tokens, les Cache Writes, les Cache Hits et les Output Tokens. OpenAI et Gemini publient également leurs propres pages de tarification API. Donc une hausse du nombre de tokens d’entrée peut peser sur le coût, mais le total dépend aussi des tokens générés en sortie, du cache, du modèle choisi et de la forme exacte de chaque requête.

Pourquoi le même texte peut-il changer de nombre de tokens ?

Un token n’est pas un mot, ni un caractère. C’est une unité interne utilisée par le modèle. Selon le tokenizer, une même phrase, un bout de code, un JSON ou un texte multilingue peuvent être découpés différemment.

OpenAI montre, dans son guide tiktoken, qu’il faut utiliser l’encoding adapté pour calculer combien de tokens un texte produira. De son côté, la documentation Gemini précise que les entrées et sorties de l’API Gemini sont tokenisées, y compris le texte et les images.

C’est pourquoi les estimations au nombre de mots ou de caractères ne suffisent pas pour prévoir précisément un coût API. Le plus fiable reste de demander au modèle cible — ou à l’outil officiel du fournisseur — son décompte réel. Dans le cas de Claude, le fait que count_tokens puisse renvoyer des nombres différents entre Opus 4.7 et Opus 4.6 illustre exactement ce point.

Comment lire correctement le « jusqu’à 35 % » ?

Estimer l’impact sur le coût

Pour une première approximation, si l’on ne regarde que les tokens d’entrée et que le prix par token d’entrée ne change pas, on peut raisonner ainsi :

surcoût input ≈ (tokens d’entrée avec le nouveau tokenizer − tokens d’entrée avec l’ancien tokenizer) × prix par token d’entrée

Cette formule ne couvre que la partie input. Une facture réelle peut aussi inclure les tokens de sortie, les écritures de cache, les lectures de cache ou d’autres lignes tarifaires selon le fournisseur et le produit utilisé. La documentation de prix de Claude distingue ces postes, et OpenAI comme Gemini disposent aussi de pages de tarification séparées.

La bonne méthode avant de migrer

1. Tester le payload complet, pas seulement le message utilisateur

En production, ce que vous envoyez au modèle ne se limite souvent pas à la question visible de l’utilisateur. Il peut y avoir un message système, un long contexte, des résultats d’outils, des fichiers, des images ou d’autres données. La documentation Gemini précise que les entrées et sorties sont tokenisées, et le guide OpenAI montre aussi le comptage d’entrées combinant texte et image.

2. Utiliser le compteur officiel du modèle cible

OpenAI fournit une documentation responses.input_tokens.count et un guide tiktoken ; Gemini documente count_tokens ; Anthropic indique que /v1/messages/count_tokens renverra un nombre différent pour Claude Opus 4.7 par rapport à Claude Opus 4.6.

3. Échantillonner plusieurs types de contenus

Ne testez pas seulement un petit prompt idéal. Comme Anthropic précise que l’augmentation varie selon le contenu, il vaut mieux comparer les cas qui pèsent vraiment dans votre usage : requêtes à fort trafic, longs contextes, prompts coûteux, payloads fréquents ou formats structurés utilisés en production.

4. Appliquer ensuite la grille tarifaire officielle

Une fois le delta de tokens mesuré, appliquez les prix officiels du modèle concerné. Puis réintégrez les autres composantes : sortie générée, cache, éventuelles options ou autres champs tarifaires. Les pages de prix d’Anthropic, d’OpenAI et de Gemini servent de référence pour ce calcul.

5. Décider s’il faut optimiser

Si l’écart est faible, une simple mise à jour du budget et des alertes de monitoring peut suffire. Si, au contraire, vos payloads à gros volume deviennent nettement plus coûteux, il peut être utile de raccourcir certains prompts, compresser le contexte, revoir la stratégie de cache ou recalculer le coût unitaire par requête.

Le point clé n’est pas de paniquer devant le chiffre de 35 %, mais de mesurer l’effet sur vos propres requêtes avec les compteurs officiels et les prix officiels.

À retenir

Le nouveau tokenizer de Claude Opus 4.7 peut effectivement faire utiliser plus de tokens pour un même texte. Anthropic indique une fourchette d’environ 1x à 1,35x par rapport aux modèles précédents, soit jusqu’à environ 35 % de plus, avec un impact qui dépend du contenu.

La vraie question n’est donc pas seulement « y a-t-il 35 % de tokens en plus ? », mais plutôt : combien de tokens d’entrée vos payloads réels gagnent-ils avec le nouveau modèle, la sortie générée change-t-elle, comment le cache est-il facturé, et quelle grille tarifaire s’applique exactement ? Avant une migration, le réflexe le plus fiable reste de lancer les compteurs officiels, puis de convertir les résultats avec les tarifs officiels.