🎁 Novità Registrati gratis, 10 chiamate le offriamo noi. Fino a $1, senza carta.
Caching di Claude Fable 5: stesso contratto, ma la spesa è 2,9x rispetto a Opus 4.6

Caching di Claude Fable 5: stesso contratto, ma la spesa è 2,9x rispetto a Opus 4.6

Indice
  1. Disponibilità
  2. Il punto chiave: Fable 5 usa il nuovo tokenizer
  3. Comportamento della cache: il contratto non cambia
  4. Comportamento del TTL: entrambe le finestre rispettate
  5. Il fattore costi: prezzo 2x per 1,45x di token
  6. Checklist di migrazione (Opus → Fable 5)
  7. In sintesi
  8. FAQ

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/messages in formato Anthropic-native) il 2026-06-10, con un system prompt inglese stabile di ~6,6–9,6K token, max_tokens basso, in una singola esecuzione sequenziale. Le cifre di costo sono lette dal campo usage.cost del 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-6claude-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.

ModelloToken di input (testo identico)Generazione tokenizer
claude-opus-4-66,614pre-4.7
claude-opus-4-89,619post-4.7
claude-fable-59,619post-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).

ModelloScrittura cache 5mScrittura cache 1hWarm read
claude-opus-4-61.25x2.00x~9% del no-cache
claude-opus-4-81.25x2.00x~6% del no-cache
claude-fable-51.24x1.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.

ModelloInput ($/M)Output ($/M)Lettura cache ($/M)
claude-opus-4-6 / 4-85250.5
claude-fable-510501

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):

ConfrontoRapporto tokenRapporto prezzoRapporto costo a parità di prompt (misurato)
Fable 5 vs Opus 4.81.00x2.0x2.0x
Fable 5 vs Opus 4.61.45x2.0x2.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.

← Torna al blog