Résultats de mesure du coût de tokenisation de Claude 4.7

• Claude 4.7 génère en moyenne 1,3 à 1,45 fois plus de tokens que la version précédente, ce qui entraîne une hausse de 20 à 30 % du coût par session à tarification identique
• L’augmentation du nombre de tokens est particulièrement marquée sur les contenus en anglais et le code, tandis que les contenus CJK (chinois, japonais, coréen) changent très peu
• Grâce à une tokenisation plus fine, la conformité aux instructions (Instruction Following) s’améliore d’environ 5 points, en particulier avec une baisse des erreurs de format
• Le nombre de tokens des préfixes mis en cache et de l’historique de conversation augmente, ce qui accroît à la fois le coût du cache et la vitesse de consommation des rate limits
• Au final, Claude 4.7 est évalué comme une architecture qui accepte un surcoût en tokens en échange d’une meilleure précision et d’une exécution plus fine des instructions

---

Résultats de mesure du tokenizer de Claude 4.7

• Claude Opus 4.7 d’Anthropic est annoncé comme utilisant 1,0 à 1,35 fois plus de tokens que la version précédente 4.6, mais les mesures réelles montrent plutôt 1,45 à 1,47 fois
• À prix et quota identiques, cette hausse du nombre de tokens entraîne une consommation plus rapide de la fenêtre max, un coût plus élevé des préfixes en cache et une arrivée plus précoce aux rate limits
• L’expérience se compose de deux volets : la mesure des coûts et la mesure de la conformité aux instructions

Méthode de mesure des coûts

• Utilisation du endpoint POST /v1/messages/count_tokens de l’API Anthropic pour envoyer le même contenu aux modèles 4.6 et 4.7 et comparer uniquement la différence de tokenizer
• Deux jeux d’échantillons ont été utilisés
  • 7 échantillons réels envoyés par des utilisateurs réels de Claude Code
  • 12 échantillons artificiels comprenant de l’anglais, du code, des données structurées, du CJK, des emojis, des symboles mathématiques, etc.

• Résultats sur les contenus réels de Claude Code

  • Moyenne pondérée de 1,325x sur 7 échantillons réels (8 254 → 10 937 tokens)
  • Principaux exemples
  • Fichier CLAUDE.md : 1,445x
  • Prompt utilisateur : 1,373x
  • Article de blog : 1,368x
  • Diff de code : 1,212x

• Résultats par type de contenu (12 échantillons artificiels)

  • Moyenne pour les contenus anglais et code : 1,345x
  • Moyenne pour les contenus CJK (chinois, japonais, coréen) : 1,01x
  • Exemples détaillés
  • Documentation technique : 1,47x
  • Script Shell : 1,39x
  • Code TypeScript : 1,36x
  • Prose anglaise : 1,20x
  • JSON : 1,13x
  • Prose japonaise et chinoise : 1,01x

Évolution du tokenizer

• Les contenus CJK, emoji et symboles ne changent presque pas, autour de 1,005 à 1,07x
  • Le vocabulaire non latin semble avoir été peu modifié
• Les contenus en anglais et le code augmentent de 1,20 à 1,47x, avec un impact plus fort sur le code que sur la prose
  • Les chaînes répétées du code (mots-clés, imports, identifiants, etc.) sont davantage fragmentées et découpées en plus de tokens
• Le ratio caractères par token en anglais baisse de 4,33→3,60, et en TypeScript de 3,66→2,69
  • Le même texte est représenté en unités plus petites

Pourquoi davantage de tokens sont utilisés

• Anthropic met en avant, sur la 4.7, une « tendance à suivre les instructions plus littéralement »
• Des unités de tokens plus petites renforcent l’attention au niveau du mot (attention) et contribuent à améliorer l’exécution précise des instructions, les tâches au niveau caractère et la précision des appels d’outils
• Des partenaires comme Notion, Warp et Factory rapportent une baisse des erreurs d’exécution d’outils
• Cependant, au-delà de la tokenisation, les poids du modèle et le post-training ont aussi changé, rendant impossible l’isolement de la cause

Test de conformité aux instructions

• Utilisation du benchmark IFEval (2023, Google) : test de 20 échantillons parmi 541 prompts du type « répondre en exactement N mots » ou « écrire sans virgule »
• Résultats
  • Mode strict, au niveau des prompts : 4.6 → 85 %, 4.7 → 90 % (+5 points)
  • Mode strict, au niveau des instructions : 86 % → 90 % (+4 points)
  • Aucune différence en mode souple
• L’amélioration provient surtout de la baisse des erreurs liées au formatage
• Une différence nette n’a été observée que sur un seul prompt (change_case:english_capital)
• La taille d’échantillon étant faible (+5 points reste statistiquement incertain), le résultat est jugé comme une amélioration modeste mais cohérente

Calcul du coût par session dans Claude Code

• Hypothèse d’une session de 80 allers-retours
  • Préfixe statique : 6K tokens (CLAUDE.md 2K + définitions d’outils 4K)
  • Historique de conversation : +2K par tour, jusqu’à 160K au 80e tour
  • Entrée/sortie : 500 / 1 500 tokens par tour
  • Taux de hit du cache : 95 %

• Coût d’une session sur la base de 4.6

  • | Élément | Calcul | Coût |
  • | --- | --- | --- |
  • | Première écriture cache | 8K × $6.25/MTok | $0.05 |
  • | Lecture cache (79 fois) | 79 × 86K × $0.50/MTok | $3.40 |
  • | Nouvelle entrée | 79 × 500 × $5/MTok | $0.20 |
  • | Sortie | 80 × 1,500 × $25/MTok | $3.00 |
  • | Total | | environ $6.65 |

• Coût d’une session sur la base de 4.7

  • CLAUDE.md : 1,445x → 2K → 2,9K
  • Définitions d’outils : 1,12x → 4K → 4,5K
  • Historique de conversation : 1,325x → 160K → 212K
  • Entrée utilisateur : 1,325x → 500 → 660
  • Préfixe moyen en cache : environ 115K tokens
  • | Élément | Calcul | Coût |
  • | --- | --- | --- |
  • | Première écriture cache | 10K × $6.25/MTok | $0.06 |
  • | Lecture cache (79 fois) | 79 × 115K × $0.50/MTok | $4.54 |
  • | Nouvelle entrée | 79 × 660 × $5/MTok | $0.26 |
  • | Sortie | 80 × 1,500–1,950 × $25/MTok | $3.00–$3.90 |
  • | Total | | environ $7.86–$8.76 |
  • Hausse de 20 à 30 % du coût par session, sans changement du prix unitaire du token
  • Pour les utilisateurs du forfait Max, la fin de session arrive plus vite dans une même fenêtre temporelle

Impact sur le prompt cache

1. Séparation du cache par modèle : le passage à 4.7 invalide le cache existant de 4.6
   • La première session démarre donc sans cache appliqué, avec un coût de préfixe plus élevé
2. Le volume même du cache augmente de 1,3 à 1,45x, à la lecture comme à l’écriture
3. Le nombre de tokens diffère même pour un même log de conversation, ce qui crée une rupture dans la facturation et les métriques de monitoring par rapport au passé

Contre-arguments et interprétation

• « La plupart des entrées sont des lectures de cache, donc l’impact est minime »

  • Si le taux de hit du cache est élevé, l’impact sur le coût est faible, mais en cas d’expiration du TTL, d’invalidation du cache ou de changement de modèle, la hausse s’applique au coût total

• « 1,35x n’est pas un plafond mais une plage »

  • Les mesures réelles se concentrent près de la borne haute (1,325x), et certains fichiers la dépassent
  • Il est plus prudent de planifier l’usage réel en se basant sur la borne haute

Conclusion

• Sur les tâches centrées sur l’anglais et le code, la consommation de tokens augmente de 1,3 à 1,45x
• La conformité aux instructions s’améliore d’environ +5 points, de manière modeste mais concrète
• Le coût par session augmente de 20 à 30 %, à prix du token inchangé
• Au final, le modèle est évalué comme une structure où l’on paie un coût supplémentaire pour obtenir une précision plus élevée et une exécution plus fine des instructions

[kaydash]

Ce n’est pas Claude 4.7, mais Opus 4.7.

[GN⁺]

Avis de Hacker News

• En partant du principe que la courbe performance/coût des LLM suit une forme logarithmique, il n’est pas clair si Opus 4.5+ représente un nouveau point sur cette courbe, ou s’il se situe simplement dans une zone où le coût explose pour obtenir de meilleures performances
  Le fait qu’Anthropic augmente rapidement ses prix peut être un signal d’une forte hausse des coûts d’exploitation
  J’ai l’impression que l’usage consistant à afficher l’axe des x en échelle logarithmique du coût dans les graphiques d’évaluation des modèles masque cette réalité

  • Voir l’analyse du coût horaire des agents IA de Toby Ord. Son concept de frontière performance/coût mérite plus d’attention
  • Je pense qu’on est arrivé au moment où les développeurs doivent dimensionner correctement (right-sizing) la taille du modèle et le niveau d’effort selon la tâche
    L’époque où l’on utilisait systématiquement le meilleur modèle est terminée. Il faut des options permettant de choisir entre plusieurs points selon le travail
    Pour les tâches complexes, utiliser un modèle plus gros et brûler 5 heures de tokens d’un coup peut être acceptable
    Cela dit, beaucoup de gens n’aimeront pas cette complexité de choix, et je m’attends à voir davantage d’expérimentations autour du smart routing
  • Anthropic se prépare à une IPO et subit une forte pression pour augmenter le revenu par utilisateur. Au final, l’entreprise s’oriente vers une tarification qui reflète les coûts réels d’exploitation des modèles
  • Si les modèles sont implémentés directement dans le silicium, les coûts baisseront et la vitesse augmentera. Des initiatives comme Taalas valent le détour
  • Si les clients sont prêts à accepter un coût plus élevé, je pense qu’on pourrait aussi proposer des modèles bien plus puissants
    Par exemple, de la même manière qu’il existe une clientèle pour des options ultra-premium chez Apple, un marché des LLM ultra-haute performance est possible

• Beaucoup de gens se focalisent sur le coût des modèles d’IA, mais en réalité le temps passé par les humains à piloter et relire les agents de code IA coûte bien plus cher
  200 $/mois, c’est cher pour un loisir, mais négligeable à l’échelle d’une entreprise
  Ce qui compte, c’est à quel point le modèle fait bien le travail, et à ces niveaux de prix, l’enjeu principal est l’efficacité par rapport au temps

  • Notre équipe a lancé trois produits cette année avec Claude. En particulier, un projet estimé à 9 personnes sur 6 mois a été bouclé par 2 personnes en 2 mois
    J’estime la valeur économique d’un abonnement Claude entre 10 000 et 40 000 euros.
    Même avec un prix multiplié par 100, je paierais. En revanche, à 20 000 euros/mois, j’examinerais des alternatives, mais pour l’instant le gain de productivité est écrasant
  • 200 $ ne représentent quasiment rien pour une entreprise, mais c’est difficile à justifier pour un hobby individuel
  • Mon instance Openclaw a généré 200 $ de facturation par jour avec l’usage d’Opus. Le vrai problème, c’est davantage l’optimisation du routing. À 1 $/heure c’était bien, mais à 15 $/heure, ça perd en compétitivité

• Je pense que l’amélioration de la qualité des modèles finira par atteindre une zone de rendements décroissants
  Comme entre un écran 8K et 16K, la plupart des utilisateurs ne verront pas la différence
  S’il y a une hausse de coût de 20 à 30 %, il faut une hausse de valeur visible équivalente

  • C’est pour cela que la majorité de la recherche se concentre sur le code. La difficulté continue d’augmenter et la valeur économique reste élevée
    À l’inverse, les requêtes conversationnelles générales sont déjà dans une situation de saturation, où il devient difficile de différencier les modèles
  • Même si cela semble précis à 99 %, lorsque l’on prend 100 000 décisions par jour, de petites erreurs s’accumulent et finissent par provoquer de gros problèmes
  • Si un modèle 4K exécutable en local apparaît, les grands labos de recherche auront des difficultés. Cela dit, Google pourra probablement tenir grâce à ses revenus publicitaires
  • Cela dépend du type de tâche. Par exemple, en conception de médicaments, la différence entre 95 % et 100 % d’achèvement crée une différence de valeur de plusieurs dizaines de fois
  • Pour la recherche web ou le résumé, on a déjà atteint une limite, mais la complexité du code peut s’étendre à l’infini

• Le multiplicateur de modèle de GitHub Copilot est passé de 3 à 7,5
  Cela ressemble à une tentative de Microsoft de réduire ses pertes
  Voir la documentation officielle

  • Nous avons donc recommandé dans notre organisation de « ne jamais activer Opus 4.7 ». Les 4.6 (3x) et 4.5 (3x) vont bien, mais la 4.7 (7,5x) n’a absolument aucun rapport qualité-prix
  • Récemment, Opus 4.6 montre une baisse de qualité du raisonnement. Il se précipite vers la conclusion et saute des étapes logiques. Sans percée majeure, j’ai l’impression qu’une forte dégradation de qualité (en**)** va arriver

• Le titre de l’article prête à confusion. Le nombre de tokens a augmenté, mais le coût par tâche peut être différent
  On suppose qu’Opus 4.7 n’utilise pas le même chemin de raisonnement qu’Opus 4.6
  Il faut attendre les résultats de l’Intelligence Index d’Artificial Analysis

  • Dans nos benchmarks internes, Opus 4.7 était 50 % moins cher avec un score de performance de 80 % (contre 60 %)
  • Le titre de l’article a été modifié de façon plus neutre en « Claude Opus 4.7 costs 20–30% more per session »
  • D’après une expérience comparative sur 28 tâches, la 4.7 a un coût similaire à l’ancienne 4.6 et environ 20 % plus élevé que la nouvelle 4.6
  • D’après mes données personnelles, la 4.7 a un coût plus élevé que la 4.6, et le gain de performance restait flou
  • Même dans le graphique officiel de l’annonce, on peut vérifier la base de l’affirmation « strictly better »

• Hier encore, utiliser Opus était bluffant, mais aujourd’hui il se trompe sans cesse même sur des tâches simples
  J’ai dû signaler le même problème une troisième fois, les sessions se coupent souvent et la compaction se déclenche de manière excessive
  J’ai finalement décidé de revenir à Sonnet

  • Ce n’est pas un bug, c’est une politique de réduction de la charge de calcul. Cela va empirer à l’avenir
  • Un LLM n’est pas une personnalité. Comme on échantillonne dans une distribution de probabilités, la probabilité d’obtenir une mauvaise session finit forcément par atteindre 100 %. Il faut réinitialiser le contexte et réessayer
  • Moi aussi, récemment, avec Opus 4.7, j’ai souvent vu des résultats catastrophiques. Voir le modèle reconnaître lui-même ses erreurs et retenter était assez amer

• Ces derniers temps, je me demande souvent : « A-t-on vraiment besoin de modèles plus puissants ? »
  Le secteur est obsédé par la course à la performance et néglige l’efficacité ainsi que la durabilité
  À l’avenir, je pense qu’il sera important d’optimiser des modèles de 0,5B à 1B paramètres pour des tâches spécifiques

  • Si je pouvais faire tourner Sonnet 4.6 en local, cela me satisferait largement
    Comme l’explique l’article CPUs Aren’t Dead, le modèle Gemma 4 E2B de Google tourne même sur téléphone et surpasse GPT-3.5-turbo
    Selon l’Intelligence Index d’Artificial Analysis, les derniers modèles 2B offrent des performances comparables à celles des modèles 175B d’il y a 3 ou 4 ans
    Gemma 4 E4B dépasse parfois GPT-4o
    À ce rythme, on pourra bientôt faire tourner des modèles de tout premier niveau sur un ordinateur portable
  • Beaucoup espéraient que Sonnet 4.6 aurait des performances du niveau d’Opus 4.5, mais la réalité n’a pas été à la hauteur
  • L’efficacité ne rapporte pas d’argent. Pour les grandes entreprises du LLM, il est plus rentable de maintenir des coûts d’inférence élevés
    La promotion du type « ce nouveau modèle est dingue » n’est au fond que du marketing FOMO
  • Tout le monde n’a pas besoin d’une calculatrice avancée. L’important est de choisir l’outil adapté au niveau nécessaire
  • Mais on ne peut pas se satisfaire d’un « modèle paresseux et imprécis ». Le labo qui résoudra ce problème prendra un avantage décisif

• À Kolkata, en Inde, des vendeurs de snacks n’ont pas pu augmenter leurs prix malgré la hausse du coût des matières premières, et ont donc réagi en réduisant la taille des produits
  C’est ainsi que fonctionne l’adaptation psychologique des gens

  • On voit la même chose partout dans le monde. Les emballages de snacks restent identiques mais le contenu diminue. Même les tubes de Pringles deviennent plus fins et plus courts
  • Ce phénomène est appelé shrinkflation

• Anthropic a introduit un nouveau mode xhigh dans la 4.7
  Le mode max consomme beaucoup de tokens et peut entraîner un raisonnement excessif, c’est pourquoi xhigh est recommandé dans la plupart des cas
  Voir la documentation officielle

  • Ajouter un niveau xhigh et repousser max plus loin donne vraiment une impression de « ça monte jusqu’à 11 »

• Sur du vrai code, Opus 4.7 a montré environ 30 % de tokens en plus
  La vraie question est : « Quelle nouvelle capacité la 4.7 apporte-t-elle par rapport à la 4.6 ? »
  Il est encore trop tôt pour juger, et si la valeur est là, on peut accepter la hausse des coûts

  • Un point intéressant pendant la discussion, c’est que beaucoup de gens courent après les nouveaux modèles alors que Sonnet 4.6 suffit déjà à être très efficace
    En réduisant le périmètre des tâches, la revue et la gestion deviennent plus simples, et on peut corriger rapidement avec de petits diff
    Si la consommation de tokens de Copilot est multipliée par 7, cela risque au contraire de casser le workflow
  • Dernièrement, les plaintes sur une baisse de performance de la 4.6 se multiplient
  • Je ne sais pas combien de temps la 4.6 sera maintenue. En entreprise, elle durera peut-être un peu plus longtemps, mais pour les abonnés individuels, le choix risque de disparaître bientôt