Caching di Claude Fable 5: stesso contratto, ma la spesa è 2,9x rispetto a Opus 4.6
Indice
claude-fable-5 è ora disponibile sul gateway Synthorai. Se fai caching sulla linea Claude, la buona notizia è che il contratto di caching e TTL resta invariato: stessi marker cache_control, stessi TTL da 5 minuti e 1 ora, stessi sovrapprezzi in scrittura, stesso sconto in lettura profonda. Per migrare il tuo codice di caching basta cambiare una stringa.
Quello che devi mettere a budget non è la meccanica della cache, ma la spesa. Fable 5 costa il doppio per token rispetto a Opus, e tokenizza lo stesso testo inglese in ~45% di token in più rispetto a Opus 4.6 (usa il tokenizer post-4.6, identico a quello di Opus 4.8). I due moltiplicatori si sommano. In questo post li misuriamo tutti, così non devi farlo tu.
TL;DR
- Claude Fable 5 mantiene invariato il contratto di caching di Anthropic: stessi marcatori
cache_control, TTL di 5 minuti e 1 ora, premi di scrittura di circa 1.25x/2x, e una lettura a caldo misurata a circa il 6% del prezzo senza cache. - Un testo identico viene tokenizzato in 9,619 token su Fable 5 e Opus 4.8 contro 6,614 su Opus 4.6: 45% in più.
- Fable 5 è listato a $10/M in input e $50/M in output, 2x il livello Opus.
- Lo stesso prompt costa quindi 2.9x rispetto a Opus 4.6 (1.45 token x 2.0 prezzo), misurato il 2026-06-10.
Tutti i numeri qui sotto sono stati misurati contro
https://synthorai.io/(/v1/messagesin formato Anthropic-native) il 2026-06-10, con un system prompt inglese stabile di ~6,6–9,6K token,max_tokensbasso, in una singola esecuzione sequenziale. Le cifre di costo sono lette dal campousage.costdel gateway; i rapporti (conteggi di token, sovrapprezzo in scrittura, sconto in lettura, costo tra modelli) sono la parte trasferibile: i dollari in valore assoluto variano in base al tuo prompt. Riproduci il test sul tuo prompt prima di citarli.
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
Sostituisci claude-opus-4-6 → claude-fable-5 e non devi toccare nulla nel percorso di caching. Fable 5 è un modello Anthropic-native con una finestra di contesto da 1M di token. Una nota sul comportamento: è un modello di reasoning e emette thinking token di default: anche un banale “reply OK” ha restituito output_tokens_details.thinking_tokens > 0 nelle nostre prove, mentre Opus 4.6/4.8 restituivano zero. Metti a budget gli output token di conseguenza. La meccanica dietro cache_control è trattata nel tutorial sul caching; l’architettura del perché la cache esiste è nella Parte 1 della serie.
Il punto chiave: Fable 5 usa il nuovo tokenizer
Il conteggio dei token per la linea Opus è salito con la generazione 4.7: lo stesso testo inglese che su 4.6 contava ~6,6K token, su 4.8 ne conta ~9,6K. Fable 5 sta dalla parte del nuovo tokenizer: lo stesso testo riporta esattamente lo stesso conteggio di token di Opus 4.8.
| Modello | Token di input (testo identico) | Generazione tokenizer |
|---|---|---|
claude-opus-4-6 | 6,614 | pre-4.7 |
claude-opus-4-8 | 9,619 | post-4.7 |
claude-fable-5 | 9,619 | post-4.7 (identico a 4.8) |
Lo stesso system prompt vale ~45% di token in più su Fable 5 rispetto a Opus 4.6 (9,619 / 6,614 = 1.45). È il numero più importante da avere chiaro prima di migrare, perché ogni cifra a valle — costo, la soglia minima di 1.024 token per l’idoneità alla cache, il budget per chiamata — è calcolata in token.
Questa è un’osservazione misurata: testo identico, stesso conteggio di token su Fable 5 e Opus 4.8, ~45% in più rispetto a Opus 4.6. Il dato è coerente con l’aggiornamento del tokenizer/vocabolario arrivato con la generazione 4.7. Se arrivi da 4.6 o precedenti, rimisura; se arrivi da 4.7/4.8, aspettati parità.
Comportamento della cache: il contratto non cambia
Abbiamo eseguito la stessa sequenza no-cache / cold-write / warm-read su ciascun modello. La struttura dello sconto è identica dall’inizio alla fine: Fable 5 rispetta cache_control e riporta gli stessi campi di usage (cache_creation_input_tokens, cache_read_input_tokens e i bucket ephemeral_5m / ephemeral_1h).
| Modello | Scrittura cache 5m | Scrittura cache 1h | Warm read |
|---|---|---|---|
claude-opus-4-6 | 1.25x | 2.00x | ~9% del no-cache |
claude-opus-4-8 | 1.25x | 2.00x | ~6% del no-cache |
claude-fable-5 | 1.24x | 1.99x | ~6% del no-cache |
Due invarianti valgono per tutti e tre:
- Sovrapprezzo di scrittura ≈ 1.25x (5m), ≈ 2x (1h). La prima chiamata (cold) costa ~1,25x il prezzo no-cache per popolare una entry da 5 minuti, o ~2x per una entry da 1 ora. Il break-even è un solo hit.
- Sconto in lettura ≈ 90%+. Un warm read dalla cache su Fable 5 è costato ~6% della chiamata no-cache, cioè uno sconto del ~94%, in linea con (e leggermente migliore di) i ~90% di risparmio sui cached-read documentati da Anthropic. Le letture restano fortemente scontate a prescindere dal TTL.
Le percentuali sono costanti su tutta la linea. Come per il passaggio da Opus 4.7 a 4.8, il conto assoluto più alto su Fable 5 dipende da prezzo e token, non dall’economia della cache — lo vediamo dopo.
Comportamento del TTL: entrambe le finestre rispettate
Fable 5 supporta gli stessi due TTL del resto della linea: un default sliding da 5 minuti e una finestra da 1 ora attivabile su richiesta. Abbiamo isolato ogni TTL con un prefisso unico per chiamata (così nessuna entry vecchia poteva contaminare il risultato) e confermato che l’oggetto usage riporta il bucket corretto — cache_creation.ephemeral_5m_input_tokens o ephemeral_1h_input_tokens.
# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}
La scrittura con TTL da 1 ora costa ~2x il no-cache (contro ~1,25x della scrittura da 5 minuti), e le letture restano al forte sconto indipendentemente dal TTL — identico a Opus 4.6/4.8. Se su Opus avevi scelto 5m per le chat live e 1h per gli agenti con pause human-in-the-loop, mantieni le stesse scelte su Fable 5.
Il fattore costi: prezzo 2x per 1,45x di token
È qui che Fable 5 fa davvero la differenza. Due fattori spingono la bolletta verso l’alto, e si moltiplicano tra loro.
1. Il prezzo di listino è il doppio del tier Opus.
| Modello | Input ($/M) | Output ($/M) | Lettura cache ($/M) |
|---|---|---|---|
claude-opus-4-6 / 4-8 | 5 | 25 | 0.5 |
claude-fable-5 | 10 | 50 | 1 |
2. Lo stesso testo produce circa il 45% di token in più rispetto al 4.6 (il cambio di tokenizer visto sopra).
Moltiplica i due fattori e lo stesso prompt in inglese costa sensibilmente di più. Confrontando lo stesso system prompt identico su ciascun modello (campo usage.cost del gateway, singola esecuzione):
| Confronto | Rapporto token | Rapporto prezzo | Rapporto costo a parità di prompt (misurato) |
|---|---|---|---|
| Fable 5 vs Opus 4.8 | 1.00x | 2.0x | 2.0x |
| Fable 5 vs Opus 4.6 | 1.45x | 2.0x | 2.9x |
Rispetto a Opus 4.8 (stesso tokenizer), Fable 5 è un netto 2x — puro sovrapprezzo di listino. Rispetto a Opus 4.6, il cambio di tokenizer si somma al cambio di prezzo e porta a circa 2,9x il costo per lo stesso prompt. Lo sconto della cache resta lo stesso, ma la base assoluta su cui si applica è circa 2,9x più grande rispetto al 4.6. Se hai dimensionato un budget per chiamata basandoti sul 4.6, rifallo.
Una conseguenza pratica: ricontrolla la soglia di 1.024 token per l’idoneità alla cache. Anthropic mette in cache solo i prefissi che raggiungono una dimensione minima. Un prompt che sul 4.6 restava appena sotto la soglia (in token del vecchio tokenizer) può superarla su Fable 5 (~45% di token in più), e viceversa per le stime di dimensione costruite sul vecchio conteggio. Leggi sempre cache_creation_input_tokens / cache_read_input_tokens dalla risposta reale, invece di stimare da un tokenizer locale che potrebbe non corrispondere.
Checklist di migrazione (Opus → Fable 5)
- ✅ Il codice di caching si porta dietro identico. Marker
cache_control, numero di breakpoint (fino a 4),ttl: "1h", nomi dei campi usage: tutto uguale. - ✅ Le scelte di TTL restano valide. 5m per carichi live/sessione, 1h per carichi a raffica o agent con pause.
- ✅ L’economia dello sconto resta invariata. ~90%+ in lettura, ~1,25x in scrittura (5m), ~2x in scrittura (1h).
- ⚠️ Rifai il budget sul costo assoluto. Fable 5 è circa 2x Opus per token, e circa 2,9x il costo a parità di prompt rispetto a Opus 4.6. La percentuale di sconto non cambia; la base su cui si applica sì.
- ⚠️ Rimisura i conteggi dei token se arrivi dal 4.6 o precedenti (aspettati circa il 45% in più per lo stesso testo). Dal 4.7/4.8 aspettati parità.
- ⚠️ Considera i token di thinking di default. Fable 5 emette reasoning token per impostazione predefinita, e vengono fatturati alla tariffa di output ($50/M). Limita o disabilita il thinking se non ti serve.
In sintesi
Per un team che già usa il caching su Claude, claude-fable-5 è un’integrazione semplice: tutta la superficie di caching e TTL è stabile, quindi non c’è nulla da reimparare né codice da riscrivere. Non è invece un cambio di budget semplice rispetto a Opus 4.6: tra il prezzo per token doppio e il ~45% di inflazione del tokenizer, lo stesso prompt costa circa 2,9x. Verifica i tuoi numeri sull’oggetto usage reale, decidi se ti servono i token di thinking di default e dimensiona i breakpoint della cache sui nuovi conteggi di token.
Per il manuale completo sul caching — struttura dei prompt, debug del tasso di hit, pattern che tengono conto del TTL — consulta la serie sul prompt-caching a partire da Come funzionano KV Cache e TTL e il tutorial pratico in Python.
FAQ
Devo modificare il mio codice cache_control per usare Fable 5?
No. La sintassi dei marker, il limite di breakpoint e le opzioni di TTL sono identiche alla linea Opus. Cambia il campo model e lascia tutto il resto invariato nel percorso di caching.
Lo sconto sulla lettura da cache è cambiato su Fable 5? No. Una lettura calda costa una piccola frazione a una cifra rispetto al prezzo dell’input senza cache (~90%+ di sconto): abbiamo misurato ~94% su Fable 5, in linea con l’economia delle letture da cache documentata da Anthropic.
Fable 5 supporta il TTL di 1 ora?
Sì. {"type": "ephemeral", "ttl": "1h"} funziona esattamente come su Opus. La scrittura a 1 ora costa ~2x rispetto al no-cache; quella a 5 minuti ~1.25x. Le letture restano fortemente scontate in entrambi i casi.
Perché lo stesso prompt costa molto di più su Fable 5 rispetto a Opus 4.6? Due moltiplicatori che si sommano: Fable 5 ha un listino di 2x sul prezzo per token, e lo stesso testo inglese conta ~45% di token in più (usa il tokenizer post-4.6). Insieme fanno ~2.9x di costo per un prompt identico. Lo sconto sulla cache resta invariato.
Fable 5 è un sostituto drop-in di Opus 4.8? Sul fronte caching/TTL e sul conteggio dei token, sì: i conteggi dei token sono identici, quindi l’unica differenza è il prezzo 2x e i thinking token di default di Fable 5. Non pubblichiamo benchmark di capacità che non abbiamo eseguito; per le affermazioni su qualità e reasoning, vedi la model card di Anthropic.
Verifica: tutte le cifre su conteggio token, costo, premio di scrittura e sconto di lettura sono state misurate su https://synthorai.io/ il 2026-06-10 con l’SDK ufficiale anthropic, singolo tenant, singola esecuzione sequenziale. Il costo è letto dal campo usage.cost del gateway; i rapporti cross-model e premio/sconto sono calcolati da quei costi misurati e sono indipendenti da qualsiasi promozione a livello di account. I rapporti sconto/premio sono stati verificati incrociando i dati con la documentazione Prompt Caching di Anthropic. La latenza di lettura calda (TTFT) nella nostra esecuzione era dominata dal jitter di rete e viene omessa perché inaffidabile. I tuoi numeri varieranno in base a prompt, regione e carico.