Costo di scrittura della prompt cache: quando conviene 1.25x?

La scrittura nella prompt cache si ripaga già con una sola rilettura entro il TTL: la scrittura costa 1.25x la tariffa di input, la lettura 0.1x. Con un solo hit, il costo totale delle due chiamate passa quindi da un sovrapprezzo del 25% a un risparmio del 32.5%. Eppure, in uno dei cinque scenari della nostra suite di agent, lo stesso sovrapprezzo ha prodotto una perdita misurata del 6%. La differenza sta in un solo numero: il rapporto tra letture e scritture del traffico. Questo articolo spiega come misurarlo prima che compaia in fattura. Tutti i dati riportati di seguito sono stati raccolti tramite il gateway Synthorai usando i contatori di fatturazione reali. I numeri sugli agent provengono da una suite di 150 episodi; i risultati su TTL e clustering da probe dedicati con salt.

TL;DR

• Le scritture esplicite in cache costano 1.25x (TTL di 5 minuti) o 2x (1 ora); i breakpoint di GPT-5.6 hanno confermato lo stesso schema 1.25x/0.1x. Basta una rilettura per raggiungere il break-even.
• Nella nostra suite di agent, l’effetto netto del sovrapprezzo variava da +6% (RAG, rapporto letture:scritture 0.2) a -83% (batch, 15.7).
• Gli hit nella cache di Claude rinnovano gratuitamente il TTL: con traffico regolare, la scrittura si paga una volta per ogni periodo di inattività, non a ogni finestra.
• Il caching implicito copre un ampio spettro: GPT-5.5 ha mantenuto 7 hit su 8 dopo una singola chiamata di priming; Gemini ha ottenuto 1-3 hit ogni 12 chiamate anche con clustering. In entrambi i casi non c’è sovrapprezzo.

Quanto costa davvero una scrittura nella cache?

Tra i provider che confrontiamo esistono tre modelli di prezzo, due dei quali fanno pagare la scrittura. Con il caching esplicito di Claude, la creazione della cache costa 1.25x la tariffa di input per il TTL predefinito di 5 minuti e 2x per il livello da 1 ora; le letture costano 0.1x. GPT-5.6 è passato ai breakpoint espliciti con gli stessi moltiplicatori, 1.25x in scrittura e 0.1x in lettura. Le due principali implementazioni esplicite del settore hanno quindi prezzi identici. Il terzo modello è il caching implicito (Gemini, Kimi e i modelli OpenAI precedenti a 5.6): nessun sovrapprezzo in scrittura, solo letture scontate quando il provider trova un hit.

Il calcolo del break-even per le scritture esplicite è semplice. Un prefisso di P token, senza cache, costa P alla tariffa normale. Se viene memorizzato in cache, la prima chiamata costa 1.25P; ogni rilettura entro il TTL costa 0.1P invece di P. Con una sola rilettura, il totale delle due chiamate è 1.35P, contro 2P senza cache: un risparmio del 32.5%. Ogni hit successivo riduce del 90% il costo del prefisso. Il rischio non è il sovrapprezzo in sé, ma scrivere blocchi che non saranno mai riletti. L’entità di questo rischio dipende dal workload.

Quando il sovrapprezzo di scrittura causa una perdita?

Quando il prefisso cambia più rapidamente di quanto venga ripetuto. Abbiamo misurato il rapporto tra token letti e scritti in cinque scenari con agent, usando gli stessi modelli e la stessa strategia di marcatura. Abbiamo poi calcolato l’effetto netto del caching con tariffe di 1.25x/0.1x:

Il dato sul RAG è quello da tenere a mente. I documenti recuperati cambiano a ogni query, quindi ogni chiamata riscriveva un prefisso che la successiva non poteva riutilizzare: cinque token scritti per ogni token riletto. Il sovrapprezzo di 1.25x si è così tradotto in una perdita netta. Non c’erano errori di configurazione: la struttura del workload non permette di ammortizzare la scrittura. La soluzione è usare più livelli, non rinunciare alla cache: marcate il system prompt e le definizioni dei tool, che restano stabili tra le query, e lasciate i documenti recuperati dopo l’ultimo breakpoint, senza marcarli. La stessa regola vale per tutti i dati volatili, come timestamp, nomi utente e contesto specifico della richiesta, oltre che per le impostazioni che invalidano silenziosamente il prefisso. Modificare output_config.effort tra un turno e l’altro rigenera il prompt e invalida la cache; l’effort deve quindi rimanere costante durante una sessione con caching. Il nostro studio su LangChain ha riscontrato lo stesso problema lato framework: alcuni builder rendono altrettanto semplice marcare tutto o marcare solo ciò che serve.

Quanto spesso si paga di nuovo la scrittura?

Una volta per ogni periodo di inattività, non una volta per finestra TTL, perché gli hit rinnovano gratuitamente il timer. Lo abbiamo verificato con un prefisso di 4,981 token dotato di salt su Claude Opus 4.8:

La chiamata 4 arriva ben oltre il TTL iniziale di 5 minuti e trova comunque il contenuto in cache, perché le chiamate 2 e 3 hanno rinnovato gratuitamente la finestra. Solo i 7 minuti di inattività hanno imposto una nuova scrittura. La conseguenza pratica è che, per qualsiasi route con un tempo tra le richieste inferiore al TTL, il sovrapprezzo di scrittura si paga una sola volta e il livello da 5 minuti si comporta come una cache senza scadenza. Il livello da 1 ora, con scrittura a 2x e fatturazione verificata nel bucket dedicato ephemeral_1h_input_tokens tramite il gateway, serve per gli altri pattern di traffico. Pagare 2x una volta invece di 1.25x più volte conviene non appena evita una singola riscrittura. È quindi adatto alle route con periodi di inattività compresi tra cinque minuti e un’ora. Dopo più di un’ora senza traffico, nessuno dei due livelli conserva la cache tra un’esecuzione e l’altra. Per un job pianificato, il budget va calcolato su ciò che accade all’interno di una singola esecuzione: un cron che invia una sola richiesta non trae alcun vantaggio dalla scrittura; un cron che genera molte richieste con lo stesso prefisso equivale a un batch e sfrutta la cache allo stesso modo.

Si può migliorare il caching implicito modellando il traffico?

Dipende interamente dal provider, perché il comportamento best-effort varia molto. Nel caso migliore, il caching automatico di GPT-5.5 si è comportato come un meccanismo affidabile: dopo una chiamata di priming, l’entry era leggibile due secondi più tardi. Il primo probe ha prodotto un hit con entrambi i salt provati. In un burst successivo, sette probe su otto hanno letto dalla cache 4,864 token di un prompt da 5,170 token, senza alcun sovrapprezzo. È un risparmio reale e non richiede altro che inviare due volte lo stesso prefisso. All’estremo opposto c’è Gemini 3.6 Flash: nella stessa suite di agent in cui il caching esplicito copriva il 77-78% dei token di input di Claude, la cache implicita di Gemini ne copriva il 4%, nonostante i workload avessero prefissi effettivamente ripetuti.

Abbiamo provato a migliorare il caso peggiore modellando il traffico: raggruppare le chiamate con lo stesso prefisso affinché la cache del provider restasse calda. Dodici chiamate consecutive su Gemini 3.6 Flash hanno prodotto un solo hit, alla chiamata 10; la chiamata 11 è stata di nuovo un miss. Otto chiamate distanziate di 3 minuti non hanno prodotto alcun hit. Per escludere un risultato casuale, abbiamo ripetuto il test con clustering su un secondo percorso di richiesta indipendente e su Gemini 3.5 Flash: rispettivamente tre hit e un hit su dodici. Gli hit non sono mai rimasti consecutivi a lungo, e l’unico blocco memorizzato in cache è stato restituito con gli stessi 4,073 token su entrambi i percorsi. Il meccanismo è coerente; la probabilità no.

Una parte dei miss dipende dalla latenza di ingestione, la cui durata varia tra provider. L’entry di GPT-5.5 era leggibile due secondi dopo il priming, mentre Gemini impiega decine di secondi a costruirla. I burst avviati subito dopo la prima chiamata arrivano quindi prima che la cache sia pronta: in nessuno dei nostri test Gemini si è verificato un hit prima della quarta chiamata. Eseguire una chiamata di priming e attendere 45 secondi prima del burst ha portato gli hit a 3 su 8, il risultato migliore ottenuto modellando il traffico. Con un’attesa di 90 secondi, invece, gli hit sono stati zero su 8: al ritorno, l’entry era già scomparsa. Alcuni giorni prima, un test di warm-up più lungo sullo stesso modello aveva mantenuto gli hit, quindi il tasso varia anche nel tempo e in base al carico. Tra latenza di costruzione, durata ridotta e variabilità, il clustering nel caso peggiore aiuta solo perché tre hit sono comunque meglio di uno. (Nota sui test: per verificare le cache implicite, usate chiamate distanziate e una variante con priming e attesa. Misurate inoltre la latenza di costruzione con una sequenza di probe dopo il priming. I probe consecutivi misurano la frequenza delle richieste, non la cache.)

La regola corretta va quindi applicata per provider, non per meccanismo: misurate se la cache implicita del vostro provider si comporta come quella di GPT-5.5, da inizializzare e poi considerare affidabile, oppure come quella di Gemini, dove ogni hit va trattato come uno sconto occasionale. Kimi K3 si colloca a metà: nessun sovrapprezzo, una soglia minima ridotta e il 57-62% dell’input servito dalla cache senza configurazione. Un dato indica chiaramente quale approccio prevale: OpenAI aveva la migliore cache implicita tra quelle misurate, ma con GPT-5.6 è comunque passata ai breakpoint espliciti, sostituendo uno sconto non controllabile con marcatori gestiti dal cliente.

Quali workload ammortizzano il sovrapprezzo?

La decisione dipende dal rapporto tra letture e scritture e dai periodi di inattività. Entrambi sono ricavabili dai record di utilizzo prima di adottare la cache:

Dai contatori emergono due regole conclusive. Primo: valutate il caching confrontando cache_read e cache_creation nei vostri dati di utilizzo, non in base alla frequenza percepita degli hit. Lo scenario RAG sembrava adatto alla cache, ma ha registrato 0.2. Secondo: quando il rapporto è favorevole, il sovrapprezzo diventa trascurabile. Con un rapporto letture:scritture di 3.5, il dato complessivo della suite, la spesa per il prefisso scende del 64%, includendo tutte le scritture pagate.

FAQ

La prompt cache conviene per il RAG?

Non per i documenti recuperati. Nelle nostre misurazioni, il RAG ha scritto cinque token per ogni token riletto, trasformando il sovrapprezzo di 1.25x in una perdita netta del 6%. Memorizzate in cache i livelli stabili, cioè system prompt e definizioni dei tool, e mantenete il contenuto recuperato dopo l’ultimo breakpoint. La guida completa al caching descrive in dettaglio la suddivisione del prompt in livelli.

Devo usare il TTL della cache da 5 minuti o quello da 1 ora?

Dipende dai periodi di inattività, non dalla durata della sessione. Gli hit rinnovano gratuitamente il TTL di 5 minuti, quindi una route con intervalli tra le richieste inferiori a 5 minuti non riscrive mai la cache e il livello economico si comporta come se non scadesse. Pagate la scrittura a 2x del livello da 1 ora solo quando gli intervalli sono compresi tra cinque minuti e un’ora: conviene non appena evita una riscrittura a 1.25x. Per intervalli superiori a un’ora, calcolate il budget come se la cache non esistesse.

Il caching implicito prevede un costo di scrittura?

No, e per sua natura non potrebbe prevederlo: un sovrapprezzo di scrittura ha senso solo quando il chiamante sceglie esplicitamente di usare la cache. I sovrapprezzi esistono quindi solo nelle implementazioni esplicite: i moltiplicatori 1.25x/2x di Anthropic, i breakpoint di GPT-5.6 e il costo di storage delle API esplicite per contenuti memorizzati, come la tariffa per token-ora di Gemini. Tutte le implementazioni implicite che abbiamo misurato (Gemini, Kimi e OpenAI prima di 5.6), così come i principali listini pubblicati (DeepSeek, Qwen e Grok), applicano solo uno sconto sulle letture. A cambiare è l’affidabilità: la cache implicita di GPT-5.5 ha mantenuto 7 hit su 8 probe dopo il priming, mentre quella di Gemini ha servito il 4% dell’input nella nostra suite di agent e il clustering ha inciso appena. Nessun sovrapprezzo su uno sconto affidabile è la soluzione migliore; nessun sovrapprezzo su uno sconto casuale vale meno di un piccolo sovrapprezzo per un meccanismo controllabile.

Misurazioni eseguite dal 2026-07-25 al 2026-07-29 tramite il gateway Synthorai: rapporti letture:scritture degli scenari ricavati da 150 episodi con agent sul ramo Claude e dettaglio della cache per chiamata (quote Gemini e Kimi ottenute dalle rispettive esecuzioni della suite); probe sul rinnovo del TTL e sul bucket da 1 ora eseguiti su claude-opus-4-8 (prefissi da 4,981 e 3,742 token con salt); probe sulla cache implicita eseguiti su gemini-3.6-flash e gemini-3.5-flash (prefissi da ~6,800 token con salt; varianti con clustering, chiamate distanziate e priming con attesa) e su gpt-5.5 (prompt da 5,170 token con salt, burst dopo il priming). Percentuali dell’effetto netto calcolate dai rapporti misurati usando moltiplicatori di 1.25x in scrittura e 0.1x in lettura. Tariffe e comportamento della cache possono cambiare; verificate i vostri record di utilizzo.

← Torna al blog