Claude Opus 4.8 sur Synthorai : cache et TTL face aux versions 4.7/4.6

claude-opus-4-8 est maintenant disponible sur la gateway Synthorai. Si vous utilisez déjà le prompt caching avec la gamme Opus, la principale information est rassurante, quoique peu spectaculaire : le contrat de cache et de TTL reste identique à celui des versions 4.7 et 4.6. Mêmes marqueurs cache_control, mêmes TTL de 5 minutes et de 1 heure, même remise en lecture et mêmes surcoûts en écriture. Vous pouvez reprendre votre code de cache tel quel.

Un seul point a changé et affecte votre budget de tokens. Ce changement remonte à la version 4.7, pas à la 4.8. Nous l’avons mesuré ici.

TL;DR

• Claude Opus 4.8 conserve le contrat de cache des versions 4.7/4.6 : remise mesurée de 89% en lecture, surcoût d’environ 1.25x en écriture avec le TTL de 5 minutes et d’environ 2x avec celui de 1 heure.
• Le même texte système représente environ 43% de tokens d’entrée supplémentaires sur Opus 4.7/4.8 par rapport aux versions 4.5/4.6 (11,394 contre 7,976 tokens).
• Le prix par token est identique sur toute la gamme Opus : le ratio de coût entre les versions 4.8 et 4.5, soit 1.43, correspond au ratio de tokens de 1.429.
• Le TTFT d’une lecture sur cache chaud reste compris entre 2.2 et 2.8s sur Opus 4.5 à 4.8 ; les écarts relèvent de la variabilité normale.

Toutes les valeurs ci-dessous ont été mesurées sur https://synthorai.io/ avec l’API native Anthropic (/v1/messages), le 2026-05-29, à partir d’un prompt système en anglais d’environ 8K caractères, avec une faible valeur de max_tokens et une seule exécution séquentielle. Refaites les mesures avec votre propre prompt avant de citer ces chiffres.

Disponibilité

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-opus-4-8",            # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # cache_creation_input_tokens, cache_read_input_tokens, cost

Remplacez claude-opus-4-7 par claude-opus-4-8. Rien d’autre ne change dans le chemin de cache. Le fonctionnement de cache_control est détaillé dans le tutoriel sur le cache. L’architecture et le rôle du cache sont expliqués dans la première partie de la série.

Comportement du cache : identique aux versions 4.7/4.6

Nous avons exécuté la même séquence d’écriture dans le cache, de lecture depuis le cache et d’appel sans cache sur les versions récentes d’Opus. La structure des remises reste strictement identique.

Deux constantes se vérifient sur les quatre versions :

• Remise en lecture ≈ 89%. Une lecture depuis un cache chaud coûte environ 11% du prix d’entrée sans cache. Cela correspond au tarif documenté par Anthropic, soit 10% du prix normal pour une lecture depuis le cache. Il n’a pas changé.
• Surcoût en écriture ≈ 25%. Le premier appel, sur cache froid, coûte environ 1.25× le prix sans cache afin d’alimenter celui-ci. Un seul hit suffit pour atteindre le seuil de rentabilité.

Les montants absolus des versions 4.7 et 4.8 sont supérieurs à ceux des versions 4.5/4.6. Comme nous allons le voir, cet écart vient du nombre de tokens, pas de l’économie du cache : les pourcentages sont stables.

Comportement des TTL : identique aux versions 4.7/4.6

Opus 4.8 prend en charge les deux mêmes TTL que le reste de la gamme : 5 minutes par défaut, avec prolongation à chaque accès, ou une fenêtre de 1 heure à activer explicitement. Nous avons isolé le test des TTL en utilisant un préfixe unique pour chaque appel afin d’éviter qu’une ancienne entrée de cache ne fausse le résultat. Nous avons ensuite mesuré le surcoût en écriture pour chaque TTL :

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

L’objet d’usage indique la catégorie de TTL exactement comme avant : cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens. L’écriture avec un TTL de 1 heure coûte environ 2× le prix sans cache, contre environ 1.25× pour celle avec un TTL de 5 minutes. Les lectures restent à environ 11%, quel que soit le TTL. Le comportement est identique à celui de la version 4.7. Si vous utilisiez 5m pour le chat en temps réel et 1h pour des agents soumis à des pauses de validation humaine sur la version 4.7, conservez ces choix sur la 4.8.

Temps jusqu’au premier token : stable sur toute la gamme

Nous avons mesuré le TTFT d’une lecture depuis un cache chaud avec un appel en streaming. Pour chaque modèle, nous avons effectué 5 mesures après préchauffage de la gateway et retenu la médiane. Avec ce prompt d’environ 8–11K tokens, le TTFT reste compris entre 2.2 et 2.8 s, sans tendance significative selon la version. Les plages se recoupent : les différences viennent de la variabilité des mesures, pas de la version.

Deux limites doivent être précisées :

• Ces chiffres ne permettent pas d’établir un classement. Les plages se recoupent largement. La valeur haute de la version 4.8, à 4.38 s, est aberrante. Pour un prompt de cette taille, le TTFT dépend principalement de la variabilité du réseau et des files d’attente, pas de la version du modèle. Retenez une plage d’environ 2.2 à 2.8 s sur cache chaud pour les quatre versions.
• Le gain de TTFT apporté par le cache augmente avec la longueur du prompt. Pour environ 8–11K tokens, le gain de prefill associé à un hit de cache reste faible. Les TTFT à froid et à chaud sont donc proches, autour de 2–3 s sur une gateway déjà préchauffée. L’écart devient beaucoup plus marqué au-delà de 100K tokens, lorsque le prefill domine. Un cache chaud permet alors de passer d’une attente de plusieurs secondes à un premier token rapide. Le fonctionnement est détaillé dans la première partie : fonctionnement du KV Cache et des TTL.

Le seul vrai changement : la tokenisation depuis la version 4.7

Voici le point à vérifier avant toute migration. Le même texte système représente environ 43% de tokens d’entrée supplémentaires sur les versions 4.7/4.8 par rapport aux versions 4.5/4.6.

Le nombre de tokens augmente à partir de la génération 4.7 et reste au même niveau sur la 4.8. Le coût suit presque exactement cette hausse : le ratio de coût entre les versions 4.8 et 4.5 est de 1.43, contre un ratio de tokens de 1.429. Le prix par token est donc identique sur toute la gamme. La facture plus élevée des versions 4.7/4.8 vient uniquement du fait que le même texte est comptabilisé avec davantage de tokens.

Deux conséquences pratiques :

1. Refaites votre budget à partir du coût absolu, pas de la remise. La remise liée au cache ne change pas, avec environ 89% en lecture. En revanche, le même prompt en anglais coûte environ 43% de plus en valeur absolue sur les versions 4.7/4.8 que sur la 4.6. Un budget par appel établi à partir du nombre de tokens de la version 4.6 sera incorrect.
2. Vérifiez à nouveau le seuil minimal de 1,024 tokens pour l’éligibilité au cache. Anthropic ne met en cache que les préfixes dont la taille atteint ce minimum. Un prompt juste en dessous du seuil sur la version 4.6 peut le dépasser sur les versions 4.7/4.8, qui comptabilisent davantage de tokens. Tout prompt dimensionné en tokens avec l’ancien tokenizer doit être mesuré à nouveau. Utilisez toujours les valeurs cache_creation_input_tokens / cache_read_input_tokens de la réponse réelle plutôt qu’une estimation issue d’un tokenizer local qui pourrait ne pas correspondre.

Nous décrivons ici une observation mesurée : un texte identique produit environ 43% de tokens d’entrée supplémentaires sur les versions 4.7/4.8. L’explication la plus probable est une mise à jour du tokenizer ou du vocabulaire à partir de la génération 4.7. La cause exacte ne change pas la conclusion : mesurez à nouveau le nombre de tokens lors de la migration, car le calcul du cache repose sur les tokens.

Checklist de migration (4.6/4.7 → 4.8)

• ✅ Le code de cache reste strictement identique. Marqueurs cache_control, nombre de points de rupture jusqu’à 4, ttl: "1h" et noms des champs d’usage : rien ne change.
• ✅ Les choix de TTL restent valables. 5m pour les charges de travail interactives ou liées à une session, 1h pour les agents ou les usages irréguliers comportant des pauses.
• ✅ L’économie de la remise reste la même. Environ 89% en lecture, environ 1.25× en écriture avec 5m et environ 2× avec 1h.
• ⚠️ Mesurez à nouveau le nombre de tokens. Si vous migrez depuis la version 4.5/4.6, prévoyez plus de 40% de tokens d’entrée supplémentaires pour le même texte. Ce changement est apparu avec la version 4.7. Si vous migrez depuis la 4.7, attendez-vous au même niveau.
• ⚠️ Validez à nouveau les tableaux de bord de coûts. Fiez-vous à usage.cost et aux champs *_input_tokens de la réponse réelle, pas à une estimation mise en cache depuis l’ancienne génération.

Conclusion

Pour une équipe qui utilise déjà le cache avec Opus, la migration vers claude-opus-4-8 est simple : toute l’interface liée au cache et aux TTL reste stable. Il n’y a rien de nouveau à apprendre ni aucun code à réécrire. Si vous partez de la version 4.6 ou d’une version antérieure, ajustez votre budget pour tenir compte du changement de tokenizer. Vérifiez ensuite vos chiffres dans l’objet usage réel, puis déployez.

Pour une présentation complète du cache, notamment la structure des prompts, le diagnostic du taux de hit et les patterns adaptés aux TTL, consultez la série sur le prompt caching en commençant par le fonctionnement du KV Cache et des TTL, ainsi que le tutoriel Python complet.

FAQ

Dois-je modifier mon code cache_control pour utiliser Opus 4.8 ? Non. La syntaxe des marqueurs, le nombre maximal de points de rupture et les options de TTL sont identiques à ceux des versions 4.7/4.6. Modifiez uniquement le champ model.

La remise sur les lectures depuis le cache a-t-elle changé avec la version 4.8 ? Non. De la version 4.5 à la 4.8, une lecture sur cache chaud coûte environ 11% du prix d’entrée sans cache, soit une remise d’environ 89%. Cela correspond au tarif documenté par Anthropic.

Le surcoût du TTL de 1 heure a-t-il changé ? Non. Une écriture avec un TTL de 1 heure coûte environ 2× le prix d’entrée sans cache. Avec un TTL de 5 minutes, elle coûte environ 1.25×. Les lectures restent à environ 11%, quel que soit le TTL. C’est le même comportement que sur la version 4.7.

Pourquoi le même prompt coûte-t-il plus cher sur la version 4.8 que sur la 4.6 ? Le prix par token est identique, mais le prompt représente davantage de tokens. Lors de nos mesures, un même texte comptait environ 8.0K tokens sur les versions 4.5/4.6, contre environ 11.4K sur les versions 4.7/4.8, soit une hausse d’environ 43%. L’explication la plus probable est un changement de tokenizer apparu avec la génération 4.7. La remise liée au cache reste inchangée.

La version 4.8 peut-elle remplacer directement la 4.7 ? Oui pour le cache et les TTL. Le nombre de tokens et le modèle économique étaient déjà au niveau de la version 4.7. La migration depuis celle-ci se fait donc à l’identique. Nous ne publions pas de benchmarks de capacités que nous n’avons pas exécutés. Pour les affirmations relatives à la qualité et au raisonnement, consultez la fiche du modèle publiée par Anthropic.

Vérification : toutes les valeurs relatives au cache, aux TTL, au nombre de tokens, aux coûts et au TTFT ont été mesurées sur https://synthorai.io/ le 2026-05-29 avec le SDK officiel anthropic, sur un seul tenant. Les coûts et nombres de tokens proviennent d’une seule exécution séquentielle. Le TTFT correspond à la médiane de 5 mesures par modèle après préchauffage de la gateway. Les ratios de remise et de surcoût ont été vérifiés à partir de la documentation d’Anthropic sur le Prompt Caching. Vos résultats varieront selon le prompt, la région et la charge.

← Retour au blog