Claude Opus 4.7 d'Anthropic consomme plus de tokens que annoncé

Le nouveau tokenizer de Claude Opus 4.7 peut renchérir sensiblement l'usage du modèle : lors de tests réels, la consommation s'est rapprochée de 45–47 %, et non des 0–35 % cités par Anthropic dans son guide de migration. Pour les équipes qui manipulent des prompts longs, de vastes instructions système et des préfixes en cache, l'écart n'a rien de cosmétique. Il frappe directement les quotas, la vitesse et le coût de chaque session.

L'analyse part d'un décalage entre la promesse et la pratique. La documentation d'Anthropic indique que le nouveau tokenizer utilise environ 1.0 à 1.35 fois plus de tokens que celui d'Opus 4.6. L'auteur a choisi de vérifier cela non sur des exemples abstraits, mais sur des contenus proches de la charge de travail réelle des développeurs.

Dans la première mesure, il a passé de la documentation technique dans le tokenizer et obtenu une hausse allant jusqu'à 1.47x. Dans la seconde, il a pris un vrai fichier CLAUDE.md, c'est-à-dire un gros contexte d'instructions, et observé un résultat quasi identique : 1.45x. L'écart avec la borne haute du guide est trop grand pour être attribué au bruit de mesure habituel.

Le problème n'est pas la hausse de tokens en soi : un tokenizer plus lourd peut parfois apporter des gains de qualité, de stabilité ou de prise en charge de textes complexes. Le souci, c'est qu'Anthropic n'a modifié ni les prix ni les quotas. Si le même texte occupe désormais plus de tokens, l'utilisateur atteint plus vite les limites de contexte, se heurte plus tôt au rate limit et dépense davantage de budget à chaque itération.

C'est particulièrement pénible dans les scénarios avec un long prompt système, un ensemble de règles, des exemples de réponses, des extraits de documentation et un préfixe en cache renvoyé en boucle. Sur le papier, le forfait est le même, mais sa capacité utile est en réalité plus faible.

C'est pourquoi l'auteur ne s'est pas contenté de compter : il a cherché à comprendre ce que le modèle offre en échange. D'après la description de l'expérience, il a vérifié les avantages annoncés du nouveau tokenizer et son comportement sur des tâches pratiques. La conclusion clé : aucune compensation miraculeuse n'est apparue.

Du moins dans les scénarios testés, la hausse de consommation était très nette, alors que le gain ne paraissait ni aussi évident ni aussi systématique. Autrement dit, du point de vue de celui qui paie les tokens ou vit dans les quotas d'un abonnement, l'échange ne tourne pas à l'avantage de l'utilisateur. Cela ne signifie pas forcément qu'Opus 4.

7 soit un moins bon modèle, mais que son économie est devenue moins confortable.

C'est un signal important pour le marché. On parle rarement du tokenizer en dehors d'un cercle restreint d'ingénieurs, alors qu'il détermine la quantité de texte réel qui tient dans la fenêtre de contexte et le coût de chaque opération via l'API. Un écart de 5–10 % reste souvent tolérable et peut se noyer dans la variabilité normale des requêtes. Mais un bond d'environ 45 % n'est plus un détail technique : il pèse sur l'architecture des agents, la longueur des instructions système, la stratégie de cache et même l'économie unitaire d'un produit. Si une équipe a un pipeline où le même gros préfixe intervient dans des centaines d'appels, les tokens superflus dévorent très vite l'argent et le débit.

La conclusion pratique est simple : il faut évaluer le passage à Claude Opus 4.7 sur ses propres corpus de texte, et non d'après la formulation marketing du guide de migration. Il convient de tester séparément les prompts système, les fichiers d'instructions, la documentation, les modèles de tâches d'agents et tout ce qui entre souvent dans le contexte. Si les mesures montrent une hausse proche de 1.45x, l'équipe devra peut-être resserrer ses prompts, sortir une partie de la logique du contexte, revoir son cache, voire repousser la migration jusqu'à ce que le bénéfice soit plus clair.

La principale leçon : on ne peut pas juger la qualité d'un modèle uniquement sur des démos et des benchmarks. Parfois, ce qui décide n'est pas l'intelligence de la réponse, mais le prix de chaque token superflu.