Anthropic et Claude Opus 4.7 : la consommation réelle de tokens dépasse les chiffres annoncés

Le nouveau tokeniseur de Claude Opus 4.7 peut augmenter significativement le coût d'utilisation du modèle : dans les tests réels, la consommation s'est avérée être plus proche de 45–47%, plutôt que les 0–35% affirmés dans le guide de migration d'Anthropic. Pour les équipes travaillant avec des prompts longs, des instructions système étendues et des préfixes cachéables, ce n'est pas une différence cosmétique mais un coup direct aux quotas, à la vitesse et au coût de chaque session.

La raison de cette analyse était le décalage entre les promesses et la pratique. Dans la documentation d'Anthropic, il est indiqué que le nouveau tokeniseur utilise environ 1,0–1,35 fois plus de tokens par rapport à la version pour Opus 4.6.

L'auteur a décidé de vérifier cela non pas sur des exemples abstraits, mais sur des matériaux qui ressemblent réellement à la charge de travail réelle des développeurs. Dans la première mesure, il a exécuté une documentation technique à travers le tokeniseur et a obtenu une croissance jusqu'à 1,47x. Dans la deuxième, il a pris un vrai fichier CLAUDE.

md—un grand contexte instructionnel—et a vu presque le même résultat : 1,45x. L'écart par rapport à la limite supérieure du guide est trop important pour être considéré comme du bruit de mesure normal. Le problème n'est pas le fait de la croissance des tokens elle-même : parfois un tokeniseur plus lourd offre réellement des avantages en qualité, en stabilité ou en support des textes complexes.

La question est qu'Anthropic ne change pas les prix et les quotas en réponse. Si le même texte occupe maintenant plus de tokens, alors l'utilisateur atteint les limites de contexte plus rapidement, rencontre des limites de débit plus tôt et dépense plus de budget par itération. C'est particulièrement douloureux pour les scénarios avec des prompts système longs, des ensembles de règles, des réponses d'exemple, des morceaux de documentation et des préfixes cachéables qui sont envoyés encore et encore.

Sur le papier, le tarif est le même, mais la capacité réellement utile est inférieure. C'est pourquoi l'auteur est allé plus loin que de simplement compter et a essayé de comprendre exactement ce que le modèle obtient en échange. Sur la base de la description de l'expérience, les avantages affirmés du nouveau tokeniseur et son comportement sur les tâches pratiques ont été testés.

La conclusion clé est qu'aucune compensation miraculeuse ne s'est produite : au moins dans les scénarios testés, l'augmentation de la consommation a été très notable, et l'avantage ne semblait pas aussi évident et systématique. En d'autres termes, du point de vue de quelqu'un qui paie pour les tokens ou qui vit dans les limites de quotas d'abonnement, l'échange semble défavorable à l'utilisateur. Cela ne signifie pas nécessairement qu'Opus 4.

7 est pire en tant que modèle, mais cela signifie que son économie est devenue moins confortable. Pour le marché, c'est un signal important. Le tokeniseur est rarement discuté en dehors d'un cercle restreint d'ingénieurs, bien que ce soit précisément ce qui détermine la quantité de texte réel qui rentre dans la fenêtre de contexte et combien coûte chaque opération au-delà de l'API.

Une différence de 5–10% est souvent tolérable et peut se perdre dans le contexte de la variabilité normale des requêtes. Mais un bond d'environ 45% n'est plus une bagatelle technique mais un facteur qui affecte l'architecture des agents, la longueur des instructions système, la stratégie de caching et même l'économie unitaire d'un produit. Si une équipe a un pipeline où le même grand préfixe participe à des centaines d'appels, les tokens supplémentaires commencent à dévorer l'argent et le débit très rapidement.

La conclusion pratique est simple : la migration vers Claude Opus 4.7 doit être évaluée non par la formulation marketing dans le guide de migration, mais par vos propres corpus de texte réels. Il vaut la peine d'exécuter 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 atterrit souvent en contexte.

Si les mesures montrent une croissance proche de 1,45x, l'équipe devra peut-être raccourcir les prompts, déplacer une partie de la logique hors du contexte, reconsidérer le caching, ou même repousser la migration jusqu'à ce que des avantages plus clairs émergent. La leçon principale ici est que la qualité du modèle ne peut pas être évaluée uniquement par des démos et des benchmarks : parfois ce qui compte vraiment n'est pas l'intelligence de la réponse, mais le coût de chaque token supplémentaire.