Opus 4.7 d'Anthropic consomme plus de tokens : une inflation cachée à prix constants

Anthropic a lancé Claude Opus 4.7, et les premiers tests via l'API ont révélé une surprise : un même texte peut occuper nettement plus de tokens dans le nouveau modèle que dans Opus 4.6. Les prix restant formellement inchangés, cela se traduit par une hausse discrète mais réelle des coûts.

En quoi consiste le problème

Le tokenizer est le composant qui découpe le texte en fragments avant de le transmettre au modèle. C'est le nombre de ces fragments qui détermine le coût d'une requête et la place occupée dans la fenêtre de contexte. Quand Anthropic modifie le tokenizer d'une version à l'autre, un même prompt se met à « peser » différemment. Avec Opus 4.7, ce poids a augmenté.

Si une requête typique occupait auparavant 1 000 tokens, elle peut désormais en occuper entre 1 300 et 1 500. Le prix par million de tokens n'a pas changé, mais vous consommez en réalité plus de tokens pour le même travail.

«

Cela donne une inflation cachée : les prix et les limites sont annoncés comme avant, mais en pratique les coûts peuvent augmenter » — extrait de l'étude de l'équipe Kodik.

Kodik, qui développe un éditeur de code compatible avec plusieurs modèles d'IA, a vérifié seule le comportement du tokenizer via l'API. Anthropic n'a pas publié de données comparatives officielles ; les développeurs ont donc mené les tests eux-mêmes et partagé leurs conclusions.

Quels contenus sont les plus touchés

La hausse de tokens n'est pas uniforme selon les types de texte. D'après les données disponibles, le tableau est le suivant :

• Code : hausse sensible, surtout dans les langages riches en caractères spéciaux : opérateurs, parenthèses, indentation
• Chaînes techniques (JSON, XML, YAML, SQL) : les variations dépendent de la structure ; les constructions imbriquées peuvent croître davantage
• Prompts système : touchés comme les requêtes utilisateur ; c'est particulièrement sensible pour les produits dotés de longues instructions système
• Texte ordinaire : croissance modérée, moins visible sur les requêtes courtes
• Contenu mixte (texte + code + JSON) : comportement imprévisible, mieux vaut tester selon le scénario concerné

Il faut tenir compte de l'échelle : si un prompt grossit de 20 % et que vous traitez un million de requêtes par jour, la facture réelle change très sensiblement.

Pourquoi c'est un problème systémique

Opus 4.7 n'est pas une exception. Le tokenizer peut changer dans n'importe quel modèle de n'importe quel fournisseur, et cela ne figure pas toujours explicitement dans les notes de version. Pour les équipes qui bâtissent des produits sur une API, cela crée plusieurs risques.

Mauvaises surprises budgétaires. Les limites calculées à partir de données historiques peuvent être dépassées de façon inattendue après un changement de modèle, même si les requêtes n'ont pas changé.

Dépassement de la fenêtre de contexte. Un système qui tenait auparavant dans 128k tokens peut, après la mise à jour, se mettre à tronquer le contexte ou à renvoyer une erreur.

Tests A/B faussés. Lorsqu'on compare la qualité de deux versions d'un modèle sur les mêmes données, un tokenizer différent signifie que les modèles reçoivent une entrée techniquement différente, ce qui influe sur l'interprétation des résultats.

Régression cachée dans les pipelines RAG. Si vous assemblez des chunks selon une limite de tokens, un changement de tokenizer peut casser la logique de découpage sans la moindre erreur dans les logs.

Ce que cela signifie

Les développeurs qui utilisent déjà Opus en production ou prévoient de passer à la 4.7 devraient faire passer leurs vrais prompts dans l'API de tokenisation des deux versions avant de basculer. Cela prendra quelques heures, mais permet d'évaluer honnêtement la hausse des coûts et d'ajuster le budget ou l'architecture.

Le cas d'Opus 4.7 est un bon rappel : lors d'une mise à niveau de modèle, vérifiez non seulement la qualité des réponses, mais aussi l'efficacité de la tokenisation.