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