Claude Opus 4.8 sur Synthorai : mise en cache et TTL face à 4.7/4.6

claude-opus-4-8 est désormais disponible sur la passerelle Synthorai. Si vous utilisez déjà la mise en cache des prompts avec la gamme Opus, la nouvelle principale est rassurante et un peu ennuyeuse : rien dans le contrat de mise en cache ou de TTL n’a changé par rapport à 4.7 ou 4.6. Mêmes marqueurs cache_control, mêmes TTL de 5 minutes et 1 heure, même remise en lecture, mêmes surcoûts d’écriture. Votre code de mise en cache se reporte tel quel.

Il y a exactement une chose qui a changé — et ce changement remonte à 4.7, pas à 4.8 — qui affecte votre budget de tokens. Cet article la mesure pour que vous n’ayez pas à le faire.

Tous les chiffres ci-dessous ont été mesurés sur https://synthorai.io/ (/v1/messages natif Anthropic) le 2026-05-29 avec un prompt système anglais d’environ 8 K caractères, max_tokens petit, une seule exécution séquentielle. Reproduisez-les avec votre propre prompt avant de les citer.

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 → claude-opus-4-8 et rien d’autre dans votre chemin de mise en cache n’a besoin de bouger. Les mécanismes derrière cache_control sont couverts dans le tutoriel de mise en cache ; l’architecture expliquant pourquoi le cache existe se trouve dans la partie 1 de la série.

Comportement de la mise en cache : inchangé par rapport à 4.7/4.6

Nous avons exécuté la même séquence écriture du cache / lecture du cache / sans cache sur la gamme Opus récente. La structure de remise est identique de bout en bout.

Deux invariants se vérifient sur les quatre versions :

• Remise en lecture ≈ 89 %. Une lecture de cache chaud coûte environ 11 % du prix d’entrée sans cache. C’est le taux de lecture en cache de 10 % documenté par Anthropic, inchangé.
• Surcoût d’écriture ≈ 25 %. Le premier appel (à froid) coûte environ 1,25× le prix sans cache pour peupler le cache. Le seuil de rentabilité est atteint dès une seule réutilisation.

Les montants absolus en dollars pour 4.7 et 4.8 sont plus élevés que pour 4.5/4.6, mais comme nous le verrons dans un instant, c’est une histoire de comptage de tokens, pas d’économie du cache — les pourcentages sont stables.

Comportement du TTL : inchangé par rapport à 4.7/4.6

Opus 4.8 respecte les deux mêmes TTL que le reste de la gamme : un défaut glissant de 5 minutes et une fenêtre d’une heure activable. Nous avons isolé le chemin TTL avec un préfixe unique par appel (afin qu’aucune entrée de cache obsolète ne puisse contaminer le résultat) et mesuré le surcoût d’é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 usage rapporte la tranche TTL exactement comme avant — cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens. L’écriture d’une heure coûte environ 2× le prix sans cache (contre environ 1,25× pour l’écriture de 5 minutes), et les lectures restent à environ 11 % quel que soit le TTL. Identique à 4.7. Si vous avez choisi 5m pour le chat en direct et 1h pour les agents avec des pauses impliquant un humain dans la boucle sur 4.7, conservez ces choix sur 4.8.

Délai jusqu’au premier token : stable sur toute la gamme

Nous avons mesuré le TTFT en lecture chaude avec un appel en streaming (5 échantillons par modèle après un préchauffage de la passerelle, médiane rapportée). Sur ce prompt d’environ 8 à 11 K tokens, le TTFT se situe dans une plage d’environ 2,2 à 2,8 s sans tendance marquée par version — les plages d’échantillons se chevauchent, donc les différences relèvent du bruit et non d’un effet de version.

Deux réserves à énoncer clairement :

• N’y lisez pas un classement. Les plages se chevauchent fortement (l’échantillon élevé de 4.8 était une valeur aberrante à 4,38 s) ; à cette taille de prompt, le TTFT est dominé par le bruit du réseau et de la mise en file d’attente, pas par la version du modèle. Considérez environ 2,2 à 2,8 s comme la plage chaude pour les quatre.
• Le gain de TTFT du cache croît avec la longueur du prompt. À environ 8 à 11 K tokens, le préremplissage économisé par un cache hit est faible, donc les TTFT à froid et à chaud sont proches (tous deux ~2 à 3 s sur une passerelle préchauffée). L’écart se creuse fortement à plus de 100 K tokens, où le préremplissage domine — c’est là qu’un cache chaud transforme une attente de plusieurs secondes en un premier token rapide. Les mécanismes sont dans la partie 1 : comment fonctionnent le cache KV et le TTL.

Le seul vrai changement : la tokenisation (depuis 4.7)

Voici la chose à revérifier avant de migrer. Le même texte système rapporte environ 43 % de tokens d’entrée en plus sur 4.7/4.8 que sur 4.5/4.6.

Le nombre de tokens fait un bond à la génération 4.7 et se reporte sur 4.8. Le coût suit le nombre de tokens presque exactement : le ratio de coût (4.8 / 4.5) est de 1,43, et le ratio de tokens de 1,429. Autrement dit, le prix par token est le même sur toute la gamme — la facture plus élevée sur 4.7/4.8 vient entièrement du fait que le même texte compte pour davantage de tokens.

Deux conséquences pratiques :

1. Rebudgétez sur le coût absolu, pas sur la remise. Votre remise de cache est inchangée (~89 % en lecture), mais le même prompt anglais coûte environ 43 % plus cher en termes absolus sur 4.7/4.8 qu’il ne le faisait sur 4.6. Si vous aviez dimensionné un budget par appel sur la base du comptage de tokens de 4.6, il sera faussé.
2. Revérifiez le seuil d’éligibilité au cache de 1 024 tokens. Anthropic ne met en cache que les préfixes d’une taille égale ou supérieure à un minimum. Un prompt qui se situait juste en dessous du seuil sur 4.6 peut le franchir sur 4.7/4.8 (plus de tokens), et un prompt dimensionné en tokens pour l’ancien tokenizer doit être remesuré. Lisez toujours cache_creation_input_tokens / cache_read_input_tokens depuis la réponse en direct plutôt que d’estimer à partir d’un tokenizer local qui peut ne pas correspondre.

Nous décrivons une observation mesurée — texte identique, environ 43 % de tokens d’entrée rapportés en plus sur 4.7/4.8 — ce qui est le plus cohérent avec une mise à jour du tokenizer/vocabulaire à la génération 4.7. La conclusion ne dépend pas de la cause profonde : remesurez les comptages de tokens lors de votre migration, car le calcul du cache repose sur les tokens.

Liste de contrôle de migration (4.6/4.7 → 4.8)

• ✅ Le code de mise en cache se reporte mot pour mot. Marqueurs cache_control, nombre de points de rupture (jusqu’à 4), ttl: "1h", noms des champs usage — tous identiques.
• ✅ Les choix de TTL se reportent. 5 min pour les charges en direct/session, 1 h pour les charges en rafale/agent avec pauses.
• ✅ L’économie de la remise se reporte. ~89 % en lecture, ~1,25× en écriture (5 min), ~2× en écriture (1 h).
• ⚠️ Remesurez les comptages de tokens. Si vous venez de 4.5/4.6, attendez-vous à environ 40 % de tokens d’entrée en plus pour le même texte (cela s’est produit à 4.7). Si vous venez de 4.7, attendez-vous à la parité.
• ⚠️ Revalidez les tableaux de bord de coût. Fiez-vous à usage.cost et aux champs *_input_tokens de la réponse en direct, pas à une estimation en cache de l’ancienne génération.

En résumé

Pour une équipe d’ingénierie qui met déjà en cache contre Opus, claude-opus-4-8 est le type de mise à niveau facile : toute la surface de mise en cache et de TTL est stable, il n’y a donc rien à réapprendre et aucun code à réécrire. Prévoyez l’évolution du tokenizer si vous sautez depuis 4.6 ou antérieur, confirmez vos chiffres avec l’objet usage en direct, et déployez.

Pour le manuel complet de mise en cache — structure du prompt, débogage du taux de hit, schémas tenant compte du TTL — consultez la série en quatre parties commençant par Comment fonctionnent le cache KV et le TTL et le tutoriel Python fonctionnel.

FAQ

Dois-je modifier mon code cache_control pour utiliser Opus 4.8 ? Non. La syntaxe des marqueurs, la limite de points de rupture et les options de TTL sont identiques à 4.7/4.6. Changez le champ model et rien d’autre.

La remise en lecture du cache a-t-elle changé sur 4.8 ? Non. Une lecture chaude représente environ 11 % du prix d’entrée sans cache (~89 % de remise) de 4.5 à 4.8, conformément au taux documenté par Anthropic.

Le surcoût du TTL d’une heure a-t-il changé ? Non. L’écriture d’une heure coûte environ 2× le prix d’entrée sans cache ; l’écriture de 5 minutes coûte environ 1,25×. Les lectures sont à environ 11 % quel que soit le TTL. Identique à 4.7.

Pourquoi le même prompt est-il plus cher sur 4.8 que sur 4.6 ? Le prix par token est le même — le prompt compte simplement comme davantage de tokens. Un texte identique a rapporté environ 8,0 K tokens sur 4.5/4.6 et environ 11,4 K sur 4.7/4.8 dans nos mesures (une augmentation d’environ 43 %), ce qui est le plus cohérent avec un changement de tokenizer à la génération 4.7. La remise de cache est inchangée.

4.8 est-il un remplacement direct de 4.7 ? Sur la surface mise en cache/TTL, oui — les comptages de tokens et l’économie étaient déjà au niveau de 4.7, donc la migration depuis 4.7 relève de la parité. Nous ne publions pas de benchmarks de capacités que nous n’avons pas exécutés ; pour les affirmations sur la qualité et le raisonnement, consultez la fiche modèle d’Anthropic.

Vérification : tous les chiffres de mise en cache, TTL, comptage de tokens, coût et TTFT ont été mesurés sur https://synthorai.io/ le 2026-05-29 à l’aide du SDK officiel anthropic, en mono-locataire. Les chiffres coût/token proviennent d’une seule exécution séquentielle ; le TTFT est une médiane sur 5 échantillons par modèle après préchauffage de la passerelle. Les ratios de remise/surcoût ont été recoupés avec la documentation Anthropic sur la mise en cache des prompts. Vos chiffres varieront selon le prompt, la région et la charge.

← Retour au blog