Cache di Claude Fable 5: stesso contratto, costo 2.9x rispetto a Opus 4.6

claude-fable-5 è ora disponibile sul gateway Synthorai. Per chi usa la cache con i modelli Claude, il contratto di caching e TTL resta invariato: stessi marker cache_control, stessi TTL di 5 minuti e 1 ora, stessi sovrapprezzi in scrittura e lo stesso forte sconto in lettura. Per migrare il codice di caching basta cambiare una stringa.

Il punto da considerare nel budget non è il funzionamento della cache, ma il costo. Il prezzo per token di Fable 5 è 2x quello di Opus e, sullo stesso testo inglese, produce ~45% di token in più rispetto a Opus 4.6 perché usa il tokenizer successivo alla versione 4.6, identico a quello di Opus 4.8. I due moltiplicatori si sommano. In questo articolo li misuriamo entrambi.

Prima della migrazione va verificato anche un vincolo non legato alla cache: Fable 5 non può essere eseguito con zero data retention. Su ogni cloud in cui è disponibile, la conservazione dei dati per 30 giorni è obbligatoria.

TL;DR

• Claude Fable 5 mantiene invariato il contratto di caching di Anthropic: stessi marker cache_control, TTL di 5 minuti e 1 ora, sovrapprezzi in scrittura di circa 1.25x/2x e letture a caldo misurate intorno al 6% del prezzo senza cache.
• Lo stesso testo produce 9,619 token su Fable 5 e Opus 4.8, contro 6,614 su Opus 4.6: il 45% in più.
• Il listino di Fable 5 è $10/M in input e $50/M in output, 2x rispetto alla fascia Opus.
• Di conseguenza, lo stesso prompt costa 2.9x rispetto a Opus 4.6 (1.45 token x 2.0 prezzo), secondo le misurazioni del 2026-06-10.

Tutti i valori riportati di seguito sono stati misurati il 2026-06-10 su https://synthorai.io/ usando l’endpoint Anthropic nativo /v1/messages, un system prompt inglese stabile di ~6.6–9.6K token, un valore ridotto di max_tokens e una singola esecuzione sequenziale. I costi provengono dal campo usage.cost del gateway. La parte riutilizzabile delle misurazioni sono i rapporti tra conteggi dei token, sovrapprezzi in scrittura, sconti in lettura e costi tra modelli; gli importi assoluti variano in base al prompt. Prima di citarli, ripetete il test con il vostro prompt.

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

Sostituendo claude-opus-4-6 → claude-fable-5, non serve modificare altro nel percorso di caching. Fable 5 è un modello Anthropic nativo con una context window da 1M token. Va però considerato un comportamento specifico: è un modello di reasoning ed emette thinking token per impostazione predefinita. Nei nostri test, persino un banale “reply OK” ha restituito output_tokens_details.thinking_tokens > 0, mentre Opus 4.6/4.8 ha restituito zero. Il budget per i token di output deve tenerne conto. Il funzionamento di cache_control è descritto nel tutorial sul caching; l’architettura e i motivi per cui esiste la cache sono trattati nella Parte 1 della serie.

Il dato principale: Fable 5 usa il nuovo tokenizer

Nella linea Opus, il conteggio dei token è aumentato con la generazione 4.7: lo stesso testo inglese che su 4.6 produceva ~6.6K token ne produce ~9.6K su 4.8. Fable 5 usa il nuovo tokenizer: a parità di testo restituisce esattamente lo stesso conteggio di Opus 4.8.

Lo stesso system prompt contiene ~45% di token in più su Fable 5 rispetto a Opus 4.6 (9,619 / 6,614 = 1.45). È il dato principale da considerare prima della migrazione, perché tutti i valori successivi, come costi, soglia minima di 1,024 token per l’idoneità alla cache e budget per chiamata, sono calcolati in token.

Si tratta di un’osservazione misurata: a parità di testo, Fable 5 e Opus 4.8 restituiscono lo stesso numero di token, circa il 45% in più rispetto a Opus 4.6. Il risultato è coerente con l’aggiornamento del tokenizer e del vocabolario introdotto con la generazione 4.7. Se migrate dalla 4.6 o da una versione precedente, ripetete le misurazioni; dalla 4.7/4.8, aspettatevi gli stessi conteggi.

Comportamento della cache: il contratto non cambia

Su ogni modello abbiamo eseguito la stessa sequenza: chiamata senza cache, scrittura a freddo e lettura a caldo. La struttura degli sconti resta identica dall’inizio alla fine. Fable 5 rispetta cache_control e restituisce gli stessi campi di utilizzo (cache_creation_input_tokens, cache_read_input_tokens e i bucket ephemeral_5m / ephemeral_1h).

Due caratteristiche restano invariate su tutti e tre i modelli:

• Sovrapprezzo in scrittura ≈ 1.25x (5m), ≈ 2x (1h). La prima chiamata, a cache fredda, costa ~1.25x rispetto a una chiamata senza cache per creare una voce da 5 minuti, oppure ~2x per una voce da 1 ora. Basta una lettura per raggiungere il break-even.
• Sconto in lettura ≈ 90%+. Su Fable 5, una lettura dalla cache a caldo è costata ~6% rispetto a una chiamata senza cache, pari a uno sconto di ~94%. Il risultato è in linea con l’economia delle letture dalla cache documentata da Anthropic, pari a circa il 90%, e risulta leggermente migliore. Le letture mantengono questo forte sconto con entrambi i TTL.

Le percentuali restano stabili sull’intera linea. Come nel passaggio da Opus 4.7 a 4.8, il maggiore costo assoluto di Fable 5 dipende dal prezzo e dal conteggio dei token, non dall’economia della cache. Vediamo ora i numeri.

Comportamento dei TTL: entrambe le finestre sono rispettate

Fable 5 supporta gli stessi due TTL degli altri modelli della linea: 5 minuti con scadenza mobile per impostazione predefinita e una finestra opzionale di 1 ora. Abbiamo isolato ciascun TTL con un prefisso univoco per chiamata, evitando che una voce precedente alterasse il risultato, e verificato che l’oggetto di utilizzo restituisse il bucket corretto: cache_creation.ephemeral_5m_input_tokens oppure 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 di 1 ora costa ~2x rispetto a una chiamata senza cache, contro ~1.25x per la scrittura con TTL di 5 minuti. Le letture mantengono lo stesso forte sconto indipendentemente dal TTL, esattamente come su Opus 4.6/4.8. Se su Opus usavate 5m per chat e sessioni live e 1h per agent con pause human-in-the-loop, mantenete le stesse scelte su Fable 5.

I costi: prezzo 2x x token 1.45x

È sui costi che Fable 5 cambia davvero. La fattura aumenta per due motivi, e i relativi fattori si moltiplicano.

1. Il prezzo di listino è 2x rispetto alla fascia Opus.

2. Lo stesso testo produce ~45% di token in più rispetto alla 4.6 a causa del cambio di tokenizer descritto sopra.

Moltiplicando i due fattori, lo stesso prompt inglese costa sensibilmente di più. Abbiamo usato lo stesso system prompt su ogni modello e confrontato il campo usage.cost del gateway in una singola esecuzione:

Rispetto a Opus 4.8, che usa lo stesso tokenizer, Fable 5 costa esattamente 2x: la differenza dipende solo dal prezzo. Rispetto a Opus 4.6, il cambio di tokenizer amplifica l’aumento di prezzo e porta il costo dello stesso prompt a circa 2.9x. Lo sconto della cache non cambia, ma la base assoluta su cui si applica è ~2.9x più alta rispetto alla 4.6. Se il budget per chiamata era stato dimensionato sulla 4.6, va ricalcolato.

C’è anche una conseguenza pratica: ricontrollate la soglia minima di 1,024 token per l’idoneità alla cache. Anthropic memorizza nella cache solo prefissi che raggiungono una dimensione minima. Un prompt appena sotto la soglia sulla 4.6, calcolata con il vecchio tokenizer, potrebbe superarla su Fable 5 grazie al ~45% di token in più. Lo stesso problema vale in senso opposto per le stime dimensionali basate sul vecchio conteggio. Leggete sempre cache_creation_input_tokens / cache_read_input_tokens dalla risposta effettiva, anziché affidarvi alle stime di un tokenizer locale che potrebbe non corrispondere.

Checklist di migrazione (Opus → Fable 5)

• ✅ Il codice di caching resta identico. Marker cache_control, numero di breakpoint (fino a 4), ttl: "1h" e nomi dei campi di utilizzo non cambiano.
• ✅ Le scelte dei TTL restano valide. 5m per carichi live o basati su sessioni, 1h per carichi intermittenti o agent con pause.
• ✅ L’economia degli sconti non cambia. ~90%+ in lettura, ~1.25x in scrittura (5m), ~2x in scrittura (1h).
• ⚠️ Ricalcolate il budget sui costi assoluti. Fable 5 costa ~2x rispetto a Opus per token e ~2.9x per lo stesso prompt rispetto a Opus 4.6. La percentuale di sconto non cambia, ma cambia la base su cui viene applicata.
• ⚠️ Misurate di nuovo il conteggio dei token se migrate dalla 4.6 o da una versione precedente: aspettatevi ~45% in più per lo stesso testo. Dalla 4.7/4.8, aspettatevi gli stessi conteggi.
• ⚠️ Tenete conto dei thinking token predefiniti. Fable 5 emette reasoning token per impostazione predefinita e li fattura alla tariffa di output ($50/M). Se non servono, limitate o disabilitate il thinking.

In sintesi

Per un team che usa già la cache con Claude, integrare claude-fable-5 è semplice: l’intera interfaccia di caching e TTL resta stabile, quindi non serve imparare nuovi meccanismi né riscrivere il codice. Dal punto di vista del budget, però, non sostituisce Opus 4.6 allo stesso costo. Tra il prezzo per token 2x e l’aumento di ~45% dovuto al tokenizer, lo stesso prompt costa ~2.9x. Verificate i dati nell’oggetto usage restituito dal servizio, decidete se vi servono i thinking token predefiniti e dimensionate i breakpoint della cache in base ai nuovi conteggi.

Per una guida completa al caching, con struttura dei prompt, debug dell’hit rate e pattern che tengono conto dei TTL, consultate la guida completa al prompt caching, l’articolo introduttivo della serie Come funzionano KV Cache e TTL e il tutorial Python completo e funzionante.

FAQ

Devo modificare il codice cache_control per usare Fable 5? No. La sintassi dei marker, il limite dei breakpoint e le opzioni TTL sono identici a quelli della linea Opus. Basta cambiare il campo model; il resto del percorso di caching non cambia.

Lo sconto sulle letture dalla cache è cambiato con Fable 5? No. Una lettura a caldo costa una piccola percentuale a una cifra rispetto al prezzo di input senza cache, con uno sconto di ~90%+. Su Fable 5 abbiamo misurato ~94%, un dato coerente con l’economia delle letture dalla cache documentata da Anthropic.

Fable 5 supporta il TTL di 1 ora? Sì. {"type": "ephemeral", "ttl": "1h"} funziona esattamente come su Opus. La scrittura con TTL di 1 ora costa ~2x rispetto a una chiamata senza cache, mentre quella da 5 minuti costa ~1.25x. Le letture mantengono un forte sconto in entrambi i casi.

Perché lo stesso prompt costa molto di più su Fable 5 rispetto a Opus 4.6? Per due moltiplicatori combinati: il prezzo per token di Fable 5 è 2x e lo stesso testo inglese produce ~45% di token in più perché usa il tokenizer successivo alla 4.6. Insieme portano il costo dello stesso prompt a ~2.9x. Lo sconto della cache non cambia.

Fable 5 può sostituire direttamente Opus 4.8? Per caching, TTL e conteggio dei token, sì: i conteggi sono identici. Le sole differenze sono il prezzo 2x e i thinking token predefiniti di Fable 5. Non pubblichiamo benchmark sulle capacità che non abbiamo eseguito; per le valutazioni su qualità e reasoning, consultate la model card di Anthropic.

Verifica: tutti i dati relativi a conteggio dei token, costi, sovrapprezzi in scrittura e sconti in lettura sono stati misurati il 2026-06-10 su https://synthorai.io/ usando l’SDK ufficiale anthropic, un singolo tenant e una singola esecuzione sequenziale. Il costo proviene dal campo usage.cost del gateway; i rapporti tra modelli e quelli relativi a sovrapprezzi e sconti sono calcolati sui costi misurati e non dipendono da eventuali promozioni applicate all’account. I rapporti di sconto e sovrapprezzo sono stati verificati con la documentazione di Anthropic sul Prompt Caching. Nelle nostre esecuzioni, la latenza delle letture a caldo (TTFT) è stata dominata dal jitter di rete e quindi omessa perché inaffidabile. I risultati varieranno in base a prompt, regione e carico.

← Torna al blog