Claude Fable 5 : Cache, Tokenizer & Coût vs Opus 4.6

claude-fable-5 est désormais disponible sur la passerelle Synthorai. Si vous utilisez le cache avec la ligne Claude, la bonne nouvelle est que le contrat de caching et de TTL est reconduit à l’identique : mêmes marqueurs cache_control, mêmes TTL de 5 minutes et 1 heure, mêmes majorations à l’écriture, même remise importante à la lecture. Votre code de caching migre en changeant une seule chaîne de caractères.

Ce qu’il faut anticiper, ce n’est pas la mécanique du cache — c’est la facture. Fable 5 est affiché à 2x le prix au token d’Opus, et il tokenise le même texte anglais en ~45 % de tokens de plus qu’Opus 4.6 (il utilise le tokenizer post-4.6, identique à celui d’Opus 4.8). Ces deux multiplicateurs s’accumulent. Cet article mesure tout cela pour vous.

Tous les chiffres ci-dessous ont été mesurés sur https://synthorai.io/ (Anthropic natif /v1/messages) le 2026-06-10 avec un system prompt anglais stable de ~6 600–9 600 tokens, max_tokens faible, exécution séquentielle unique. Les montants sont lus depuis le champ usage.cost de la passerelle ; les ratios (nombres de tokens, majoration à l’écriture, remise à la lecture, coût inter-modèles) constituent la partie portable — les valeurs absolues en dollars s’adaptent à votre prompt. Reproduisez ces mesures sur 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-fable-5",             # 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)   # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost

Remplacez claude-opus-4-6 → claude-fable-5 et rien dans votre chemin de caching n’a besoin de changer. Fable 5 est un modèle Anthropic natif avec une fenêtre de contexte de 1 million de tokens. Une note comportementale : c’est un modèle de raisonnement qui émet des tokens de réflexion par défaut — même un simple « reply OK » retournait output_tokens_details.thinking_tokens > 0 dans nos tests, là où Opus 4.6/4.8 retournait zéro. Prévoyez votre budget de tokens de sortie en conséquence. La mécanique derrière cache_control est couverte dans le tutoriel de caching ; l’architecture expliquant pourquoi le cache existe se trouve dans la Partie 1 de la série.

Le point clé : Fable 5 utilise le nouveau tokenizer

Le nombre de tokens pour la ligne Opus a augmenté à la génération 4.7 : le même texte anglais qui comptait ~6 600 tokens sur 4.6 en compte ~9 600 sur 4.8. Fable 5 se situe du côté nouveau — un texte identique rapporte exactement le même nombre de tokens qu’Opus 4.8.

Le même system prompt représente ~45 % de tokens de plus sur Fable 5 que sur Opus 4.6 (9 619 / 6 614 = 1,45). C’est le chiffre le plus important à intégrer avant de migrer, car chaque valeur dérivée — coût, le seuil d’éligibilité au cache de 1 024 tokens, votre budget par appel — est calculée en tokens.

Nous décrivons une observation mesurée — texte identique, nombre de tokens identique sur Fable 5 et Opus 4.8, ~45 % au-dessus d’Opus 4.6 — la plus cohérente avec la mise à jour du tokenizer/vocabulaire introduite à la génération 4.7. Si vous venez de la version 4.6 ou antérieure, remessurez ; si vous venez de la 4.7/4.8, attendez-vous à une parité.

Comportement du cache : le contrat est inchangé

Nous avons exécuté la même séquence sans cache / écriture à froid / lecture à chaud sur chaque modèle. La structure de remise est identique de bout en bout — Fable 5 respecte cache_control et rapporte les mêmes champs d’utilisation (cache_creation_input_tokens, cache_read_input_tokens, ainsi que les buckets ephemeral_5m / ephemeral_1h).

Deux invariants se vérifient sur les trois modèles :

• Majoration à l’écriture ≈ 1,25x (5m), ≈ 2x (1h). Le premier appel (à froid) coûte ~1,25x le prix sans cache pour alimenter une entrée de 5 minutes, ou ~2x pour une entrée d’1 heure. Le seuil de rentabilité est atteint dès un seul hit.
• Remise à la lecture ≈ 90 %+. Une lecture de cache à chaud sur Fable 5 a coûté ~6 % de l’appel sans cache — soit une remise de ~94 %, en ligne avec (légèrement meilleure que) les ~90 % documentés par Anthropic pour les lectures en cache. Les lectures restent fortement remisées quel que soit le TTL.

Les pourcentages sont stables sur toute la ligne. Comme pour le passage Opus 4.7 → 4.8, la facture absolue plus élevée sur Fable 5 est une question de prix et de tokens, pas d’économie de cache — ce qui est traité ci-après.

Comportement du TTL : les deux fenêtres sont respectées

Fable 5 prend en charge les deux mêmes TTL que le reste de la ligne : un défaut glissant de 5 minutes et une fenêtre optionnelle d’1 heure. Nous avons isolé chaque TTL avec un préfixe unique par appel (pour qu’aucune entrée périmée ne puisse contaminer le résultat) et confirmé que l’objet d’utilisation rapporte le bon bucket — cache_creation.ephemeral_5m_input_tokens ou ephemeral_1h_input_tokens.

# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}

L’écriture sur 1 heure coûte ~2x sans cache (contre ~1,25x pour l’écriture sur 5 minutes), et les lectures restent fortement remisées quel que soit le TTL — identique à Opus 4.6/4.8. Si vous aviez choisi 5m pour le chat en direct et 1h pour les agents avec des pauses humaines sur Opus, conservez ces choix sur Fable 5.

La question du coût : 2x le prix x 1,45x les tokens

C’est là que Fable 5 diffère réellement. Deux facteurs font monter la facture, et ils se multiplient.

1. Le prix catalogue est 2x le niveau Opus.

2. Le même texte représente ~45 % de tokens de plus que sur 4.6 (le changement de tokenizer évoqué ci-dessus).

En les multipliant, le même prompt anglais coûte sensiblement plus cher. Mesuré sur le même system prompt identique pour chaque modèle (champ usage.cost de la passerelle, même exécution unique) :

Ainsi, face à Opus 4.8 (même tokenizer), Fable 5 représente un 2x net — pure prime de prix. Face à Opus 4.6, le changement de tokenizer vient s’ajouter au changement de prix pour atteindre environ 2,9x le coût pour le même prompt. Votre remise de cache est inchangée, mais la base absolue à laquelle elle s’applique est ~2,9x plus grande qu’elle ne l’était sur 4.6. Si vous avez dimensionné un budget par appel sur la base de 4.6, recalculez-le.

Une conséquence pratique : revérifiez le seuil d’éligibilité au cache de 1 024 tokens. Anthropic ne met en cache que les préfixes atteignant ou dépassant une taille minimale. Un prompt qui se trouvait juste en dessous du seuil sur 4.6 (en tokens de l’ancien tokenizer) peut le dépasser sur Fable 5 (~45 % de tokens en plus) — et inversement pour les estimations de taille construites sur l’ancien comptage. 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.

Liste de contrôle pour la migration (Opus → Fable 5)

• ✅ Le code de caching est repris tel quel. Les marqueurs cache_control, le nombre de points d’arrêt (jusqu’à 4), ttl: "1h", les noms des champs d’utilisation — tout est identique.
• ✅ Les choix de TTL sont reconduits. 5m pour les charges de travail en direct/session, 1h pour les agents avec pauses.
• ✅ L’économie de remise est reconduite. ~90 %+ à la lecture, ~1,25x à l’écriture (5m), ~2x à l’écriture (1h).
• ⚠️ Recalculez le coût absolu. Fable 5 est ~2x Opus par token, et ~2,9x le coût du même prompt vs Opus 4.6. Le pourcentage de remise est inchangé ; la base à laquelle il s’applique ne l’est pas.
• ⚠️ Remessurez les nombres de tokens si vous venez de la version 4.6 ou antérieure (attendez ~45 % de plus pour le même texte). Depuis la 4.7/4.8, attendez-vous à une parité.
• ⚠️ Tenez compte des tokens de réflexion par défaut. Fable 5 émet des tokens de raisonnement par défaut — ils sont facturés au tarif de sortie (50 $/M). Limitez ou désactivez le raisonnement si vous n’en avez pas besoin.

En résumé

Pour une équipe qui utilise déjà le cache avec Claude, claude-fable-5 est une intégration facile : toute la surface de caching et de TTL est stable, il n’y a donc rien à réapprendre et aucun code à réécrire. Ce n’est pas un remplacement budgétaire simple depuis Opus 4.6 — entre le prix au token 2x plus élevé et l’inflation de ~45 % due au tokenizer, le même prompt coûte ~2,9x plus cher. Vérifiez vos chiffres sur l’objet usage en direct, décidez si vous avez besoin des tokens de réflexion par défaut, et dimensionnez les points d’arrêt du cache en fonction des nouveaux nombres de tokens.

Pour le guide complet de caching — structure des prompts, débogage du taux de hit, patterns 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 opérationnel.

FAQ

Dois-je modifier mon code cache_control pour utiliser Fable 5 ? Non. La syntaxe des marqueurs, la limite de points d’arrêt et les options de TTL sont identiques à la ligne Opus. Changez le champ model et rien d’autre dans le chemin de caching.

La remise à la lecture du cache a-t-elle changé sur Fable 5 ? Non. Une lecture à chaud représente une petite fraction à un chiffre du prix d’entrée sans cache (~90 %+ de remise) — nous avons mesuré ~94 % sur Fable 5, cohérent avec les économies de lecture en cache documentées par Anthropic.

Fable 5 prend-il en charge le TTL d’1 heure ? Oui. `{“type”: “ephemeral”, “ttl

← Retour au blog