Claude Opus 4.8 su Synthorai: caching e TTL rispetto a 4.7/4.6

claude-opus-4-8 è ora disponibile sul gateway Synthorai. Se usi già il prompt caching sulla linea Opus, la notizia è rassicurante e un po’ noiosa: il contratto di caching e TTL non cambia rispetto a 4.7 o 4.6. Stessi marker cache_control, stessi TTL da 5 minuti e 1 ora, stesso sconto in lettura, stessi premi in scrittura. Il tuo codice di caching si riusa così com’è.

C’è esattamente una cosa che è cambiata — ed è cambiata già in 4.7, non in 4.8 — e tocca il tuo budget di token. Questo post la misura per te.

TL;DR

• Claude Opus 4.8 mantiene invariato il contratto di caching di 4.7/4.6: uno sconto in lettura misurato dell’89%, un sovrapprezzo in scrittura di circa 1.25x sul TTL di 5 minuti e di circa 2x su quello di 1 ora.
• Lo stesso testo di sistema riporta circa il 43% di token di input in più su Opus 4.7/4.8 rispetto a 4.5/4.6 (11.394 vs 7.976 token).
• Il prezzo per token è identico lungo tutta la linea Opus: il rapporto di costo 4.8/4.5 di 1.43 corrisponde al rapporto di token di 1.429.
• Il TTFT in lettura a caldo si colloca in una fascia di 2.2-2.8s su tutta la gamma Opus 4.5-4.8; le differenze sono jitter.

Tutti i numeri qui sotto sono stati misurati su https://synthorai.io/ (endpoint Anthropic-native /v1/messages) il 2026-05-29 con un system prompt in inglese di ~8K caratteri, max_tokens piccolo, una singola esecuzione sequenziale. Riproducili 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-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

Cambia claude-opus-4-7 → claude-opus-4-8 e nient’altro nel percorso di caching deve muoversi. La meccanica dietro cache_control è spiegata nel tutorial sul caching; l’architettura del perché la cache esiste è nella Parte 1 della serie.

Comportamento del caching: invariato rispetto a 4.7/4.6

Abbiamo eseguito la stessa sequenza cache write / cache read / no-cache sulla linea Opus recente. La struttura degli sconti è identica dall’inizio alla fine.

Due invarianti valgono per tutte e quattro le versioni:

• Sconto in lettura ≈ 89%. Una lettura da cache calda costa ~11% del prezzo di input senza cache. È il 10% di cached-read documentato da Anthropic, invariato.
• Premio in scrittura ≈ 25%. La prima chiamata (a freddo) costa ~1,25× il prezzo senza cache per popolare la cache. Il break-even è a un solo hit.

I valori assoluti in dollari per 4.7 e 4.8 sono più alti di 4.5/4.6, ma come vedremo tra poco è una questione di conteggio dei token, non di economia della cache — le percentuali restano piatte.

Comportamento del TTL: identico a 4.7/4.6

Opus 4.8 gestisce gli stessi due TTL del resto della linea: uno sliding di default a 5 minuti e una finestra opzionale di 1 ora. Abbiamo isolato il percorso del TTL usando un prefisso univoco per ogni chiamata (così nessuna voce di cache scaduta poteva contaminare il risultato) e misurato il premium di scrittura per ciascun TTL:

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

L’oggetto usage riporta il bucket del TTL esattamente come prima: cache_creation.ephemeral_5m_input_tokens oppure ephemeral_1h_input_tokens. La scrittura a 1 ora costa ~2× rispetto al no-cache (contro ~1.25× della scrittura a 5 minuti), mentre le letture restano a ~11% indipendentemente dal TTL. Identico a 4.7. Se su 4.7 avevi scelto 5m per la chat live e 1h per gli agenti con pause human-in-the-loop, mantieni le stesse scelte su 4.8.

Time-to-first-token: costante su tutta la linea

Abbiamo misurato il TTFT su warm-read con una chiamata in streaming (5 campioni per modello dopo un warm-up del gateway, riportata la mediana). Su questo prompt di ~8–11K token, il TTFT si colloca in una fascia di ~2.2–2.8 s senza alcun trend significativo tra le versioni: gli intervalli dei campioni si sovrappongono, quindi le differenze sono jitter, non un effetto della versione.

Due precisazioni da mettere in chiaro:

• Non ricavarne una classifica. Gli intervalli si sovrappongono molto (il campione alto di 4.8 era un outlier a 4.38 s); con questa dimensione di prompt il TTFT è dominato dal jitter di rete e di coda, non dalla versione del modello. Considera ~2.2–2.8 s come la fascia warm per tutti e quattro.
• Il vantaggio del cache sul TTFT cresce con la lunghezza del prompt. A ~8–11K token il prefill risparmiato da un cache hit è piccolo, quindi il TTFT a freddo e a caldo sono vicini (entrambi ~2–3 s su un gateway già scaldato). Il divario si allarga parecchio a 100K+ token, dove il prefill domina: è lì che una cache calda trasforma un’attesa di diversi secondi in un primo token rapido. I dettagli sono in Parte 1: Come funzionano KV Cache e TTL.

L’unico cambiamento reale: la tokenizzazione (da 4.7)

Ecco cosa devi ricontrollare prima di migrare. Lo stesso testo di sistema conta circa il 43% di input token in più su 4.7/4.8 rispetto a 4.5/4.6.

Il conteggio dei token cresce con la generazione 4.7 e resta tale su 4.8. Il costo segue il conteggio dei token quasi alla lettera: il rapporto di costo (4.8 / 4.5) è 1,43, quello dei token è 1,429. Il prezzo per token è quindi identico su tutta la linea: la bolletta più alta su 4.7/4.8 dipende interamente dal fatto che lo stesso testo vale più token.

Due conseguenze pratiche:

1. Ricalcola il budget sul costo assoluto, non sullo sconto. Lo sconto della cache non cambia (~89% in lettura), ma lo stesso prompt in inglese costa circa il 43% in più in termini assoluti su 4.7/4.8 rispetto a 4.6. Se hai dimensionato il budget per chiamata sui conteggi token di 4.6, sarà sbagliato.
2. 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 su 4.6 stava appena sotto la soglia potrebbe superarla su 4.7/4.8 (più token), e un prompt dimensionato in token per il vecchio tokenizer va rimisurato. Leggi sempre cache_creation_input_tokens / cache_read_input_tokens dalla risposta reale invece di stimarli con un tokenizer locale che potrebbe non corrispondere.

Stiamo descrivendo un’osservazione misurata — testo identico, circa il 43% di input token riportati in più su 4.7/4.8 — coerente con un aggiornamento del tokenizer/vocabolario alla generazione 4.7. La conclusione non dipende dalla causa: rimisura i conteggi dei token quando migri, perché i calcoli della cache si basano sui token.

Checklist di migrazione (4.6/4.7 → 4.8)

• ✅ Il codice di caching resta invariato. Marcatori cache_control, numero di breakpoint (fino a 4), ttl: "1h", nomi dei campi di usage: tutto identico.
• ✅ Le scelte di TTL restano invariate. 5m per carichi live/di sessione, 1h per carichi a raffiche o agent con pause.
• ✅ L’economia dello sconto resta invariata. ~89% in lettura, ~1,25× in scrittura (5m), ~2× in scrittura (1h).
• ⚠️ Rimisura i conteggi dei token. Se arrivi da 4.5/4.6, aspettati oltre il 40% di input token in più per lo stesso testo (è successo con 4.7). Se arrivi da 4.7, aspettati parità.
• ⚠️ Rivalida le dashboard dei costi. Fidati di usage.cost e dei campi *_input_tokens della risposta reale, non di una stima in cache della generazione precedente.

In sintesi

Per un team di engineering che già usa la cache su Opus, claude-opus-4-8 è l’upgrade facile: tutta la superficie di caching e TTL è stabile, quindi non c’è nulla da reimparare né codice da riscrivere. Metti in conto lo spostamento del tokenizer se salti da 4.6 o precedenti, verifica i tuoi numeri sull’oggetto usage reale, e vai in produzione.

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 Opus 4.8? No. La sintassi dei marker, il limite di breakpoint e le opzioni di TTL sono identiche a 4.7/4.6. Cambia il campo model e basta.

Lo sconto sulle cache read è cambiato con la 4.8? No. Una read a caldo costa circa l’11% del prezzo di input senza cache (~89% di sconto) dalla 4.5 alla 4.8, in linea con la tariffa documentata da Anthropic.

È cambiato il sovrapprezzo per il TTL di 1 ora? No. La write a 1 ora costa circa 2× il prezzo di input senza cache; la write a 5 minuti circa 1,25×. Le read restano intorno all’11% a prescindere dal TTL. Come nella 4.7.

Perché lo stesso prompt costa di più sulla 4.8 rispetto alla 4.6? Il prezzo per token è lo stesso: il prompt conta semplicemente più token. Lo stesso testo nelle nostre misurazioni riportava ~8,0K token su 4.5/4.6 e ~11,4K su 4.7/4.8 (un aumento del ~43%), cosa che indica con buona probabilità un cambio di tokenizer nella generazione 4.7. Lo sconto sulla cache non è cambiato.

La 4.8 è un rimpiazzo diretto della 4.7? Sul fronte caching/TTL sì: conteggio dei token ed economics erano già al livello della 4.7, quindi la migrazione dalla 4.7 avviene senza differenze. Non pubblichiamo benchmark di capacità che non abbiamo eseguito; per le affermazioni su qualità e reasoning, consulta la model card di Anthropic.

Verifica: tutte le cifre su caching, TTL, conteggio token, costi e TTFT sono state misurate su https://synthorai.io/ il 2026-05-29 usando l’SDK ufficiale anthropic, in single tenant. Le cifre di costo/token derivano da una singola esecuzione sequenziale; il TTFT è la mediana di 5 campioni per modello dopo il warm-up del gateway. I rapporti di sconto/sovrapprezzo sono stati verificati con la documentazione Prompt Caching di Anthropic. I tuoi numeri varieranno in base a prompt, regione e carico.

← Torna al blog