Claude Opus 4.8 su Synthorai: cache e TTL a confronto con 4.7/4.6

claude-opus-4-8 è ora disponibile sul gateway Synthorai. Per chi usa già il prompt caching con la famiglia Opus, la notizia è rassicurante e poco sorprendente: il contratto di caching e TTL non è cambiato rispetto a 4.7 o 4.6. Stessi marker cache_control, stessi TTL di 5 minuti e 1 ora, stesso sconto sulle letture e stessi sovrapprezzi sulle scritture. Il codice di caching può essere riutilizzato senza modifiche.

È cambiato un solo aspetto, già a partire da 4.7 e non da 4.8, che incide sul budget dei token. Di seguito riportiamo le misure.

TL;DR

• Claude Opus 4.8 mantiene invariato il contratto di caching di 4.7/4.6: sconto misurato dell’89% sulle letture, sovrapprezzo di circa 1.25x sulle scritture con TTL di 5 minuti e di circa 2x con TTL di 1 ora.
• Lo stesso testo di sistema produce circa il 43% di input token in più su Opus 4.7/4.8 rispetto a 4.5/4.6 (11,394 contro 7,976 token).
• Il prezzo per token è identico per tutta la famiglia Opus: il rapporto di costo 1.43 tra 4.8 e 4.5 coincide con il rapporto di token pari a 1.429.
• Il TTFT delle letture da cache calda resta nella fascia 2.2-2.8s su Opus 4.5-4.8; le differenze dipendono dalla variabilità delle misure.

Tutti i valori seguenti sono stati misurati su https://synthorai.io/ (endpoint Anthropic nativo /v1/messages) il 2026-05-29, con un system prompt in inglese di circa 8K caratteri, max_tokens ridotto e una singola esecuzione sequenziale. Prima di citarli, ripetete le misure 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-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

Basta sostituire claude-opus-4-7 con claude-opus-4-8: il resto del flusso di caching non cambia. Il funzionamento di cache_control è spiegato nel tutorial sul caching; l’architettura e le ragioni alla base della cache sono descritte nella prima parte della serie.

Comportamento della cache: invariato rispetto a 4.7/4.6

Abbiamo eseguito la stessa sequenza di scrittura in cache, lettura dalla cache e chiamata senza cache sulle versioni recenti di Opus. La struttura degli sconti è identica in tutti i casi.

Tutte e quattro le versioni mantengono due valori costanti:

• Sconto sulla lettura ≈ 89%. Una lettura da cache calda costa circa l’11% del prezzo dell’input senza cache. Corrisponde alla tariffa documentata da Anthropic per le letture dalla cache, pari al 10%, e non è cambiata.
• Sovrapprezzo sulla scrittura ≈ 25%. La prima chiamata, a cache fredda, costa circa 1.25× rispetto alla chiamata senza cache perché deve popolarla. Basta una lettura successiva per raggiungere il pareggio.

I costi assoluti in dollari di 4.7 e 4.8 sono superiori a quelli di 4.5/4.6. Come vedremo tra poco, la differenza dipende dal numero di token, non dall’economia della cache: le percentuali restano invariate.

Comportamento dei TTL: invariato rispetto a 4.7/4.6

Opus 4.8 supporta gli stessi due TTL del resto della famiglia: 5 minuti con scadenza scorrevole come valore predefinito e una finestra opzionale di 1 ora. Abbiamo isolato il percorso dei TTL usando un prefisso univoco per ogni chiamata, così da evitare che una vecchia entry della cache alterasse il risultato, e misurato il sovrapprezzo 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 indica il bucket TTL esattamente come prima: cache_creation.ephemeral_5m_input_tokens oppure ephemeral_1h_input_tokens. La scrittura con TTL di 1 ora costa circa 2× rispetto alla chiamata senza cache, contro circa 1.25× per quella da 5 minuti. Le letture restano intorno all’11%, indipendentemente dal TTL. Il comportamento è identico a 4.7. Se con 4.7 usavate 5m per la chat in tempo reale e 1h per agenti con pause human-in-the-loop, mantenete le stesse scelte su 4.8.

Time to first token: invariato in tutta la famiglia

Abbiamo misurato il TTFT delle letture da cache calda con una chiamata in streaming, usando 5 campioni per modello dopo il warm-up del gateway e riportando la mediana. Con questo prompt da circa 8-11K token, il TTFT resta nella fascia ~2.2-2.8 s senza variazioni significative tra le versioni. Gli intervalli dei campioni si sovrappongono, quindi le differenze dipendono dalla variabilità delle misure e non dalla versione.

Due precisazioni:

• Questi dati non definiscono una classifica. Gli intervalli si sovrappongono ampiamente; il valore massimo di 4.8, pari a 4.38 s, è un outlier. Con prompt di queste dimensioni, il TTFT dipende soprattutto dalla variabilità della rete e delle code, non dalla versione del modello. Per tutti e quattro i modelli, considerate ~2.2-2.8 s come fascia di riferimento a cache calda.
• Il vantaggio della cache sul TTFT cresce con la lunghezza del prompt. Con circa 8-11K token, il prefill evitato da una cache hit è ridotto. I TTFT a cache fredda e calda sono quindi simili: entrambi si attestano intorno a ~2-3 s su un gateway già caldo. Oltre i 100K token, il divario aumenta sensibilmente perché domina il prefill: in quel caso una cache calda trasforma un’attesa di diversi secondi in un primo token rapido. Il funzionamento è descritto nella prima parte: funzionamento di KV Cache e TTL.

L’unica vera modifica: la tokenizzazione (da 4.7)

Prima della migrazione va verificato un aspetto: lo stesso testo di sistema produce circa il 43% di input token in più su 4.7/4.8 rispetto a 4.5/4.6.

Il numero di token aumenta dalla generazione 4.7 e resta allo stesso livello in 4.8. Il costo segue quasi esattamente il numero di token: il rapporto di costo tra 4.8 e 4.5 è 1.43, mentre quello tra i token è 1.429. Il prezzo per token è quindi uguale per tutta la famiglia: il costo maggiore di 4.7/4.8 deriva interamente dal fatto che lo stesso testo viene conteggiato con più token.

Le conseguenze pratiche sono due:

1. Ricalcolate il budget sul costo assoluto, non sullo sconto. Lo sconto della cache non cambia: circa l’89% sulle letture. Su 4.7/4.8, però, lo stesso prompt in inglese costa in termini assoluti circa il 43% in più rispetto a 4.6. Un budget per chiamata calcolato sui token di 4.6 risulterà errato.
2. Verificate di nuovo la soglia minima di 1,024 token per l’uso della cache. Anthropic memorizza in cache solo i prefissi che raggiungono una dimensione minima. Un prompt appena sotto la soglia su 4.6 potrebbe superarla su 4.7/4.8, dato il maggior numero di token. Anche i prompt dimensionati in token usando il vecchio tokenizer devono essere misurati di nuovo. Leggete sempre cache_creation_input_tokens / cache_read_input_tokens dalla risposta effettiva, anziché affidarvi alla stima di un tokenizer locale che potrebbe non corrispondere.

Descriviamo un dato misurato: a parità di testo, 4.7/4.8 riportano circa il 43% di input token in più. L’ipotesi più coerente è un aggiornamento del tokenizer o del vocabolario introdotto con la generazione 4.7. La causa non cambia la conclusione: dopo la migrazione bisogna misurare nuovamente i token, perché i calcoli della cache si basano sul loro numero.

Checklist per la migrazione (4.6/4.7 → 4.8)

• ✅ Il codice di caching si riutilizza senza modifiche. Marker cache_control, numero di breakpoint (fino a 4), ttl: "1h" e nomi dei campi usage sono tutti identici.
• ✅ Le scelte dei TTL restano valide. 5m per workload live o basati su sessioni, 1h per workload intermittenti o agenti con pause.
• ✅ L’economia degli sconti non cambia. ~89% sulle letture, ~1.25× sulle scritture (5m), ~2× sulle scritture (1h).
• ⚠️ Misurate di nuovo il numero di token. Se migrate da 4.5/4.6, aspettatevi oltre il ~40% di input token in più per lo stesso testo; la variazione è stata introdotta con 4.7. Da 4.7, i valori dovrebbero restare invariati.
• ⚠️ Convalidate di nuovo le dashboard dei costi. Fate riferimento a usage.cost e ai campi *_input_tokens della risposta effettiva, non a una stima memorizzata dalla generazione precedente.

In sintesi

Per un team che usa già la cache con Opus, claude-opus-4-8 è un upgrade semplice: tutta l’interfaccia di caching e TTL resta stabile, quindi non c’è nulla di nuovo da imparare né codice da riscrivere. Se migrate da 4.6 o versioni precedenti, aggiornate il budget per tenere conto della variazione del tokenizer, verificate i dati sull’oggetto usage effettivo e procedete con il rilascio.

La serie sul prompt caching descrive l’intero processo, dalla struttura dei prompt al debug della hit rate e ai pattern sensibili ai TTL. Si parte da Funzionamento di KV Cache e TTL e prosegue con il tutorial Python completo e funzionante.

Domande frequenti

Devo modificare il codice cache_control per usare Opus 4.8? No. La sintassi dei marker, il limite dei breakpoint e le opzioni TTL sono identici a 4.7/4.6. È sufficiente cambiare il campo model.

Lo sconto sulle letture dalla cache è cambiato in 4.8? No. Da 4.5 a 4.8, una lettura da cache calda costa circa l’11% del prezzo dell’input senza cache, cioè circa l’89% in meno. Il valore corrisponde alla tariffa documentata da Anthropic.

Il sovrapprezzo per il TTL di 1 ora è cambiato? No. La scrittura con TTL di 1 ora costa circa 2× il prezzo dell’input senza cache; quella da 5 minuti costa circa 1.25×. Le letture costano circa l’11%, indipendentemente dal TTL. È lo stesso comportamento di 4.7.

Perché lo stesso prompt costa di più su 4.8 rispetto a 4.6? Il prezzo per token è uguale; è il prompt a essere conteggiato con più token. Nelle nostre misure, lo stesso testo produceva circa 8.0K token su 4.5/4.6 e circa 11.4K su 4.7/4.8, con un aumento di circa il 43%. L’ipotesi più coerente è una modifica del tokenizer introdotta con la generazione 4.7. Lo sconto della cache non è cambiato.

4.8 può sostituire direttamente 4.7? Per caching e TTL, sì. Numero di token ed economia erano già passati ai valori attuali con 4.7, quindi la migrazione da 4.7 mantiene gli stessi parametri. Non pubblichiamo benchmark sulle capacità che non abbiamo eseguito; per le valutazioni sulla qualità e sul reasoning, consultate la model card di Anthropic.

Verifica: tutti i valori relativi a caching, TTL, numero di token, costi e TTFT sono stati misurati su https://synthorai.io/ il 2026-05-29 usando l’SDK ufficiale anthropic e un singolo tenant. I dati su costi e 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 e sovrapprezzo sono stati verificati rispetto alla documentazione di Anthropic sul prompt caching. I risultati variano in base a prompt, area geografica e carico.

← Torna al blog