Anthropic Prompt Caching — 90% Cost Reduction su System Prompts Ripetuti

Cos'è: Il prompt caching è una funzionalità introdotta da Anthropic ad agosto 2024 sulla Claude API che permette di cachare porzioni di prompt — tipicamente system prompt e context grandi — tra chiamate successive, abbattendo costi e latenza quando lo stesso contesto viene riusato. Con una cache hit, il costo dei token cachati è il 10% rispetto al normale (90% di riduzione) e la latenza si riduce dell'85%. Il caching è opt-in via header cache_control, con TTL di default di 5 minuti. È diventato rapidamente best practice obbligatoria per qualunque applicazione production-grade basata su Claude.

Il problema che risolve

Molte applicazioni LLM riutilizzano lo stesso contesto a ogni chiamata: un system prompt lungo che definisce il comportamento dell'assistente, un set di documenti recuperati da RAG che resta stabile per più turni di conversazione, una codebase intera passata come contesto a un code assistant, le istruzioni e gli esempi few-shot di un prompt complesso. Senza caching, ogni chiamata API rielabora questi token da zero — paghi il costo input pieno ogni volta, e il tempo di prefill (la fase in cui il modello legge tutto il prompt prima di iniziare a generare) scala linearmente con la lunghezza del contesto.

Per dare ordini di grandezza: un'applicazione di document Q&A che mantiene 80.000 token di contesto stabile e 2.000 token di query/risposta variabile, fatta su Claude 3.5 Sonnet a $3 per milione di input token, paga ~$0.24 di solo prefill per ogni domanda. Cento domande sullo stesso documento costano $24, di cui $24 è essenzialmente sprecato a rileggere la stessa cosa cento volte. Il prompt caching cambia questa matematica: dopo la prima chiamata (che paga il prefill pieno più un piccolo overhead per scrivere in cache), tutte le successive in finestra TTL pagano i token cachati al 10% del prezzo — dollari $2.40 totali invece di $24, un risparmio del 90% su quella componente.

L'effetto sulla latenza è altrettanto significativo: il time-to-first-token (TTFT) — quanto aspetti prima che il modello inizi a scrivere — scende dell'85% per la parte cachata. Un'app che impiegava 8 secondi a iniziare a rispondere su un contesto lungo, ora inizia in poco più di un secondo. Per UX di chat in tempo reale o pipeline automatizzate ad alta frequenza, la differenza è qualitativa.

Come funziona tecnicamente

Il client API marca esplicitamente quali parti del prompt sono cachabili usando il parametro cache_control sul blocco di messaggio. Esempio in pseudo-codice:

messages = [
  {
    "role": "system",
    "content": [
      {
        "type": "text",
        "text": "<long system prompt + RAG context>",
        "cache_control": { "type": "ephemeral" }
      }
    ]
  },
  { "role": "user", "content": "<variable user query>" }
]

Anthropic calcola un hash crittografico del contenuto fino al breakpoint cache_control, lo memorizza nell'infrastruttura, e nelle chiamate successive — se l'hash coincide e siamo entro il TTL — recupera lo stato pre-computato del modello (i KV cache della attention) invece di rieseguire il prefill. La cache non vede mai il modello "pensare" la stessa cosa due volte: è uno snapshot del computational state, riutilizzato direttamente.

Il TTL di default è 5 minuti dall'ultimo accesso (refresh on read), ma Anthropic ha aggiunto successivamente un'opzione 1 ora per use case dove il contesto resta stabile su sessioni lunghe — con un costo di write più alto compensato dalla maggiore probabilità di hit. Si possono definire fino a 4 breakpoint cache nella stessa richiesta, utile per cachare separatamente system prompt e RAG context che cambiano con cadenze diverse.

Il pricing è asimmetrico per scoraggiare miscachare cose volatili: cache write costa il 125% del normale input (25% di overhead sulla prima chiamata che popola la cache), cache hit costa il 10% del normale. La regola pratica: cachare paga se prevedi almeno ~2 riusi del contesto cachato entro il TTL — sotto quella soglia il write overhead non si ammortizza.

Use case tipici

RAG con context grandi. Una pipeline RAG retrieva tipicamente 5-20 chunk di documenti rilevanti per ogni query — diciamo 30-80k token di contesto. Se l'utente fa una conversazione multi-turn sullo stesso set di chunk, ogni turno successivo riusa quel contesto. Cachare i chunk in coda alla system prompt riduce il costo della conversazione a una frazione del normale. Pattern: prima retrieval + chiamata API con cache write, turni successivi con cache hit fino a quando l'utente cambia query in modo che invalida i chunk.

Code assistants su intere codebase. Cursor, Continue, Cline e simili passano spesso decine o centinaia di file come contesto per dare al modello visione completa del progetto. La codebase cambia raramente nel corso di una sessione di lavoro — al massimo qualche file editato — quindi cachare la base e variare solo i diff è perfetto per questo pattern. Cline e altri client open source hanno integrato prompt caching come default per Claude proprio per questa ragione economica.

Document Q&A e analisi legale/medica. Caricare un contratto di 100 pagine, un paper scientifico lungo, una cartella clinica voluminosa, e poi fare molte domande successive su quel singolo documento. Lo use case classico dove un singolo write cache + N hit cache rende l'app economicamente sensata. Senza caching, lo stesso pattern sarebbe prohibitivamente costoso per uso di massa.

Few-shot prompting strutturato. Quando si usa un prompt con molti esempi few-shot (decine di esempi input/output che insegnano un task specifico al modello), il blocco di esempi è stabile tra le chiamate ma può occupare migliaia di token. Cachare il blocco esempi e variare solo l'input concreto è un caso libro di testo per il prompt caching.

Confronto con OpenAI e Gemini

OpenAI ha risposto ad ottobre 2024 con il proprio automatic prompt caching, con due differenze filosofiche rispetto ad Anthropic. Prima differenza: è opt-out implicito, non opt-in — OpenAI cacha automaticamente prompt sopra una certa lunghezza minima, senza che lo sviluppatore debba inserire breakpoint. Seconda differenza: lo sconto è del 50% sui token cachati, non 90% — più conservativo. La scelta di OpenAI privilegia la zero-friction adoption (qualunque app sopra una certa soglia di prompt length beneficia gratis) a costo di un risparmio meno aggressivo.

Google ha invece context caching su Gemini, con un modello ancora diverso: caching esplicito ma con TTL configurabile su un range ampio (default 1 ora, fino a settimane) e prezzo per storage time-based — paghi per la durata che tieni in cache, non solo per write. Adatto a use case dove un contesto enorme (Gemini supporta fino a 2 milioni di token) viene riusato molte volte su giorni o settimane: librerie tecniche aziendali, knowledge base statiche, manuali medici di riferimento.

Per architetti di sistemi AI in produzione il quadro è chiaro: ogni provider ha la sua filosofia, e la scelta del modello deve includere considerazioni di caching nel calcolo del TCO. Una stessa applicazione può avere costi anche 5-10x diversi tra provider a parità di qualità output solo per come usa il caching disponibile.

Implementazione pratica: regole di progettazione

Tre regole pragmatiche per usare il prompt caching efficacemente.

1. Cachare il prefisso comune, variare il suffisso. La cache funziona prefix-based: deve esserci un match esatto byte-per-byte dall'inizio del prompt fino al breakpoint. Se metti contenuto variabile in mezzo al prompt, rompi la cache per tutto quello che segue. Strategia: prefisso lungo e stabile (system + RAG + esempi few-shot) → breakpoint cache → suffisso corto e variabile (query utente, ultimo turno conversazione).

2. Monitorare il cache hit ratio. Le risposte API includono campi cache_creation_input_tokens e cache_read_input_tokens — dovresti loggarli e tenere sotto controllo il rapporto. Un'applicazione ben progettata in regime dovrebbe avere cache hit ratio sopra l'80%; sotto il 50% qualcosa è rotto nel design del prompt o nella gestione della sessione.

3. Allineare TTL con pattern di traffico reale. Il TTL 5-minuti è ottimo per chat e sessioni interattive di breve durata. Per workload batch o pipeline che eseguono ogni N minuti, scegliere il TTL 1-ora può migliorare drasticamente il hit ratio. Misurare prima, scegliere dopo — la scelta sbagliata di TTL è la causa più comune di costi di cache write che non si ammortizzano.

---