Prompt Caching per LLM in Produzione 2026: Anthropic, OpenAI e Semantic Caching

Aggiornato: 6 luglio 2026

Il prompt caching è una funzionalità server-side offerta da Anthropic, OpenAI e Google che memorizza le porzioni statiche di un prompt (system message, few-shot examples, documenti di contesto) per riutilizzarle nelle chiamate successive: nel 2026 abbatte del 50–90% il costo dei token in input ripetuti e riduce la latenza p99 anche dell'85% sui prompt lunghi. In produzione lo uso ogni giorno per contenere la bolletta di Claude e GPT su carichi RAG e agenti multi-step. In questa guida ti mostro come funziona su ciascun provider, quando aggiungere un layer di semantic caching, e la dashboard operativa che avrei voluto avere il primo giorno.

• Anthropic offre prompt caching esplicito con cache_control: sconto del 90% sui token cached, TTL di 5 minuti (default) o 1 ora (beta a costo maggiorato di scrittura).
• OpenAI attiva il caching automaticamente per prompt ≥1024 token su gpt-4o, gpt-4.1 e o-series: sconto del 50–75% sui token cached, TTL circa 5–10 minuti (fino a un'ora nei periodi di basso carico).
• Google Gemini usa context caching esplicito con TTL configurabile e paga il caching per ora di storage: adatto a corpus statici molto grandi (>32K token).
• Il semantic caching (GPTCache, Redis Vector, LangChain) intercetta query semanticamente equivalenti prima della chiamata LLM: complementare al prompt caching, non sostitutivo.
• La metrica chiave da monitorare è la cache hit ratio sui token in input, non il numero di richieste: una hit ratio del 70% sui token può ridurre la bolletta del 45% anche con hit ratio del 40% sulle richieste.
• La struttura del prompt determina l'efficacia della cache: parti statiche in cima, parti dinamiche in fondo, sempre.

Cos'è il prompt caching e perché conta in produzione

Il prompt caching è una tecnica lato provider che memorizza il KV-cache (chiavi e valori dell'attention) del prefisso di un prompt dopo la prima chiamata, così le chiamate successive con lo stesso prefisso non devono ri-processarlo. In pratica: paghi il full price la prima volta, poi il 10–50% del prezzo standard sui token che il modello "riconosce" identici, e la latenza cala perché il modello parte da uno stato interno già calcolato invece di consumare tutto il contesto da capo.

Ha senso in tre scenari tipici delle mie giornate operative: agenti che riusano lo stesso system prompt con 8K token di regole, pipeline RAG dove i documenti recuperati vengono richiamati più volte in una sessione, e workflow multi-step dove ogni step aggiunge poco al prompt precedente. Il primo trimestre in cui ho attivato il caching su Claude nel nostro backend agenti, la fattura è scesa del 41% senza toccare una riga di logica di business, solo riordinando i prompt. Onestamente, quel tipo di risultato "gratuito" non capita spesso.

Quello che invece non fa: non salva output, non deduplica semanticamente, non funziona su prompt che cambiano ogni volta. Se il tuo system prompt è di 200 token e il resto varia, il caching non ti serve. Devi guardare al semantic caching o al response caching. Per approfondire l'osservabilità che ti dice se il caching sta funzionando davvero, vedi la nostra guida all'osservabilità LLM con LangSmith e Langfuse.

Anthropic prompt caching: cache_control esplicito

Anthropic è stata la prima a rendere il caching un'API di prima classe. Nel 2026, con Claude 4.7 Opus e Claude 4.5 Sonnet, il caching è generalmente disponibile e si controlla marcando esplicitamente i breakpoint con cache_control: {type: "ephemeral"}. Puoi impostare fino a 4 breakpoint per richiesta, e il modello memorizza tutto ciò che sta prima di ogni breakpoint.

Le regole economiche: scrivere in cache costa il 125% del prezzo input standard (25% in più); leggere costa il 10% (sconto del 90%). Il TTL di default è 5 minuti; con l'header beta extended-cache-ttl-2025-04-11 puoi arrivare a 1 ora pagando il 200% sulla scrittura. La cache richiede un minimo di 1024 token (Sonnet/Opus) o 2048 (Haiku).

Ecco come strutturare una chiamata efficace con l'SDK Python. Le parti statiche (system prompt più documenti) vanno prima del breakpoint, la query utente va dopo:

from anthropic import Anthropic

client = Anthropic()

SYSTEM_PROMPT = open("system_rules.md").read()  # ~6000 token statici
KNOWLEDGE_BASE = open("kb_index.txt").read()    # ~15000 token statici

def query_agent(user_message: str) -> str:
    response = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=1024,
        system=[
            {
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},
            },
            {
                "type": "text",
                "text": KNOWLEDGE_BASE,
                "cache_control": {"type": "ephemeral"},
            },
        ],
        messages=[{"role": "user", "content": user_message}],
    )
    usage = response.usage
    print(
        f"cache_creation_input_tokens={usage.cache_creation_input_tokens} "
        f"cache_read_input_tokens={usage.cache_read_input_tokens} "
        f"input_tokens={usage.input_tokens}"
    )
    return response.content[0].text

I due campi che devi loggare in produzione sono cache_creation_input_tokens e cache_read_input_tokens. Il primo è quanto hai pagato in più per scrivere in cache; il secondo è quanto hai risparmiato leggendo. Se il rapporto read / creation è sotto 3× la cache non ti sta rendendo, probabilmente stai invalidandola troppo spesso. La documentazione ufficiale Anthropic sul prompt caching tiene traccia di tutti i modelli supportati.

OpenAI prompt caching: automatico e trasparente

OpenAI ha lanciato il prompt caching a fine 2024 e nel 2026 è attivo di default su gpt-4o, gpt-4.1, o3-mini e la o-series. Nessuna configurazione: il servizio identifica automaticamente i prefissi ripetuti nei prompt lunghi almeno 1024 token e applica lo sconto del 50% sui token cached (75% sulla nuova generazione di modelli reasoning). Non esiste un costo aggiuntivo di scrittura, e il TTL è tipicamente 5–10 minuti, esteso fino a un'ora nei periodi di basso traffico sul cluster.

La comodità è enorme, ma paga un prezzo in trasparenza: non decidi tu dove piazzare i breakpoint. La cache è granulare a blocchi di 128 token dal primo token in poi, quindi la stessa regola d'oro vale: tutto ciò che è statico va all'inizio. Se metti l'ID utente in cima e il documento in fondo, hai buttato via il caching.

La response include usage.prompt_tokens_details.cached_tokens, ed è tutto ciò che ti serve per calcolare l'efficacia:

from openai import OpenAI

client = OpenAI()

SYSTEM_PROMPT = open("system_rules.md").read()
KNOWLEDGE_BASE = open("kb_index.txt").read()

def query(user_message: str, user_id: str) -> dict:
    response = client.chat.completions.create(
        model="gpt-4.1",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "system", "content": KNOWLEDGE_BASE},
            # dinamico in fondo, dopo tutti i blocchi statici
            {"role": "user", "content": f"[user={user_id}] {user_message}"},
        ],
    )
    usage = response.usage
    cached = usage.prompt_tokens_details.cached_tokens
    total = usage.prompt_tokens
    hit_ratio = cached / total if total else 0
    return {
        "text": response.choices[0].message.content,
        "cached_tokens": cached,
        "total_input_tokens": total,
        "cache_hit_ratio": hit_ratio,
    }

Nella mia esperienza il caching automatico di OpenAI è più "forgiving" di quello Anthropic (perdona meglio piccole variazioni di whitespace nei prompt), ma è anche meno prevedibile: due chiamate identiche a distanza di 15 minuti possono avere hit ratio molto diversi a seconda del carico del cluster. Per applicazioni con SLA stretti di latenza, devi misurare il p50/p95/p99 con cache calda e fredda separatamente. Le due distribuzioni sono mondi diversi. Vedi la guida ufficiale al prompt caching di OpenAI per i dettagli aggiornati sui modelli supportati.

Google Gemini context caching

Google Gemini adotta un modello ibrido: il context caching è esplicito come Anthropic ma con TTL configurabili in secondi/ore/giorni e un costo di storage separato per il tempo in cui la cache resta viva. Nel 2026 è supportato su Gemini 2.0 Pro e Flash con un minimo di 32.768 token, quindi ha senso solo per corpus davvero grandi (documenti tecnici, video-transcript, codice).

Il pricing è a due componenti: (1) input token cached scontati del 75%, (2) storage al secondo per la durata del TTL. Se hai un contesto da 500K token che riusi in 200 richieste all'ora, il caching è cassaforte; se lo usi due volte al giorno, il costo storage lo mangia. La formula pratica: TTL ottimale ≈ tempo mediano tra due chiamate successive con stesso contesto.

from google import genai
from google.genai import types

client = genai.Client()

cache = client.caches.create(
    model="gemini-2.0-pro",
    config=types.CreateCachedContentConfig(
        contents=[open("kb_full.txt").read()],  # >32K token richiesti
        system_instruction="Sei un assistente tecnico...",
        ttl="1800s",  # 30 minuti
    ),
)

response = client.models.generate_content(
    model="gemini-2.0-pro",
    contents="Riassumi la sezione 4.2 in tre punti.",
    config=types.GenerateContentConfig(cached_content=cache.name),
)
print(response.usage_metadata.cached_content_token_count)

Il grande vantaggio di Gemini è il context caching su input multimodali (video, audio, PDF): se stai processando ore di video con la stessa base di conoscenza, nessun altro provider si avvicina in termini di prezzo per token cached. Riferimento: documentazione Google Gemini context caching.

Confronto: Anthropic vs OpenAI vs Google

La scelta del provider su base caching dipende da tre variabili: quanto è statico il tuo prompt, quanto è grande, e quanto stretto è il tuo SLA di latenza. Ho riassunto qui le dimensioni operative che confronto ad ogni RFP interna.

Dimensione	Anthropic (Claude)	OpenAI (GPT-4.1 / o-series)	Google (Gemini 2.0)
Modalità di caching	Esplicito (cache_control)	Automatico	Esplicito (CachedContent)
Sconto sui token cached	90%	50–75%	75%
Costo di scrittura extra	+25% (default) / +100% (1h)	Nessuno	Nessuno + storage $/sec
TTL	5 min / 1 ora (beta)	~5–60 min (opaco)	Configurabile (sec–giorni)
Token minimi	1024 (Sonnet/Opus)	1024	32.768
Breakpoint massimi	4 per richiesta	Automatico (128-token blocks)	Uno per cache
Miglior use-case	Agenti con system prompt lungo	RAG e chatbot ad alto volume	Corpus enormi e multimodali
Prevedibilità	Alta (controllo esplicito)	Media (dipende dal cluster)	Alta (paghi per TTL)

Nel nostro stack usiamo Anthropic per gli agenti (system prompt di 12K token, caching esplicito), OpenAI per chat customer-facing ad alto volume (dove il caching automatico funziona benissimo su prompt ripetuti), e Gemini quando dobbiamo processare gigabyte di documentazione tecnica come contesto. Se sei in fase di scelta modello, la nostra guida al function calling con LLM nel 2026 confronta le stesse tre famiglie sotto un altro angolo.

Semantic caching con GPTCache e Redis

Il prompt caching lato provider funziona solo se il prefisso è byte-identico. "Qual è il fatturato Q3?" e "Fatturato terzo trimestre" sono due prompt distinti per Claude e GPT, e paghi entrambi. Il semantic caching risolve questo problema lato client: embeddi la query, cerchi in un vector store se esiste una risposta salvata per una query semanticamente simile (soglia coseno tipica 0.95), e la restituisci senza chiamare l'LLM.

Le tre librerie che vale la pena conoscere nel 2026:

• GPTCache: la più matura, supporta diversi vector store (FAISS, Milvus, Chroma) e LLM provider. Facile da integrare come drop-in decorator.
• Redis Semantic Cache: RedisSearch più RedisVector permette di gestire semantic cache e session state nella stessa istanza. La mia scelta di default per chi ha già Redis in stack.
• LangChain RedisSemanticCache / SQLiteVectorCache: astrazione integrata con LangChain, comoda per prototipare.

Esempio con Redis Semantic Cache in produzione:

from redisvl.extensions.llmcache import SemanticCache
from openai import OpenAI

llm = OpenAI()
cache = SemanticCache(
    name="agent_cache",
    redis_url="redis://cache-node-1:6379",
    distance_threshold=0.05,  # ~0.95 coseno di similarita
    ttl=3600,
)

def answer(question: str) -> str:
    if hit := cache.check(prompt=question):
        return hit[0]["response"]  # semantic hit, nessuna chiamata LLM

    resp = llm.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": question}],
    ).choices[0].message.content

    cache.store(prompt=question, response=resp)
    return resp

Semantic caching e prompt caching non si escludono: nel nostro stack agenti li mettiamo in cascata. Prima il semantic cache (per intercettare query duplicate a livello utente), poi il prompt cache lato provider (per abbattere il costo delle chiamate che passano la semantic). Se costruisci una pipeline RAG di produzione, il semantic caching sui query di retrieval spesso rende più del prompt caching sui documenti recuperati.

Come calcolare il ROI del prompt caching

Prima di attivare il caching in produzione voglio sempre sapere: quanto costerà l'overhead di scrittura, in quanti hit si ammortizza, e quanto risparmierò a regime. La formula che uso nei miei runbook:

# Anthropic (default TTL 5 min)
# scrittura: 1.25x del prezzo standard
# lettura: 0.10x del prezzo standard

def anthropic_savings_ratio(reads_per_write: float) -> float:
    # baseline: paghi 1x per ogni chiamata (nessun caching)
    baseline = reads_per_write + 1
    # con caching: 1.25 scrittura + N letture a 0.10
    with_cache = 1.25 + reads_per_write * 0.10
    return 1 - (with_cache / baseline)

# esempi pratici:
# 2 letture / 1 scrittura  -> 51.7% risparmio
# 5 letture / 1 scrittura  -> 70.8% risparmio
# 10 letture / 1 scrittura -> 79.5% risparmio
# 20 letture / 1 scrittura -> 84.5% risparmio

La metrica che devi tenere in dashboard non è "quanto ho risparmiato" ma reads per write. È il moltiplicatore che ti dice se la struttura dei tuoi prompt è compatibile con il caching. Sotto 3 letture per scrittura, o stai invalidando la cache troppo spesso o hai troppi utenti "coda lunga" con prompt unici, quindi devi ristrutturare, non buttare via il caching.

Per OpenAI il calcolo è più semplice (nessun costo di scrittura, sconto 50% sui token cached): risparmi = cached_tokens / total_input_tokens × 0.5. Con hit ratio del 70% sui token, risparmi il 35% sulla componente input. Nel nostro chatbot customer support, l'attivazione del caching automatico ha portato il costo per conversazione da $0.18 a $0.09 in una settimana.

La dashboard di monitoraggio che vorresti aver costruito

Il consiglio più operativo che posso darti: costruisci le metriche cache prima di attivare il caching, non dopo. La prima volta che l'ho abilitato in produzione senza dashboard mi sono trovata a fissare la fattura del mese cercando di capire perché era scesa "solo" del 20% invece del 60% atteso, impossibile da diagnosticare senza serie temporali.

Queste sono le 6 metriche che tengo su Grafana e che segnalano immediatamente quando qualcosa si è rotto:

1. Cache hit ratio (token): cached_tokens / total_input_tokens per provider, media mobile 5 min. Target: >60% steady state.
2. Cache hit ratio (richieste): percentuale di richieste con almeno un token cached. Utile per capire se la cache "prende" o no.
3. Reads per write (Anthropic): cache_read_input_tokens / cache_creation_input_tokens aggregato per finestra oraria. Sotto 3× è un red flag.
4. Latency p99 by cache state: p99 diviso in "cold" (0 token cached) vs "warm" (>50% cached). Le due curve devono divergere; se convergono la cache non sta aiutando la latenza.
5. Cache invalidation rate: prompt hash unici / totale chiamate. Se sale improvvisamente, qualcuno ha iniettato un valore dinamico all'inizio del prompt.
6. Costo mensile per feature: taggato con la feature che ha originato la chiamata. Quando il caching smette di funzionare per una feature, lo vedi subito.

Se non hai ancora un backend di osservabilità in place, LangSmith e Langfuse espongono già la maggior parte di queste metriche in dashboard pronte. Dettagli nella nostra guida all'osservabilità LLM 2026. Alternativa self-hosted: OpenTelemetry GenAI semantic conventions più Prometheus.

Errori comuni e trappole in produzione

Ho collezionato una lista di modi in cui il caching smette di funzionare senza avvertire, e spesso li scopri solo confrontando la fattura di due mesi consecutivi:

• Timestamp iniettato all'inizio del prompt: "Sono le 14:32 del 6 luglio 2026, rispondi..." significa invalidazione garantita ad ogni chiamata. Sposta il timestamp in fondo o rimuovilo se non serve al reasoning.
• Model version change: passare da claude-opus-4-6 a claude-opus-4-7 resetta tutta la cache. Prepara un caching bootstrap warmup post-deploy.
• System prompt costruito dinamicamente: template Jinja che rende A/B test tag all'inizio, così ogni variante ha la sua cache. Meglio: variante in fondo al prompt.
• Ordine dei tool schema: se ordini i tool alfabeticamente e poi cambi un nome, l'ordine cambia e la cache si invalida. Ordina per una chiave stabile.
• Whitespace inconsistenti: un carriage-return diverso in un documento incluso e la cache non hitta. Normalizza in ingresso.
• TTL più corto della finestra di riuso: se le tue chiamate arrivano ogni 8 minuti e il TTL Anthropic default è 5, ricrei la cache ogni volta e paghi solo il costo scrittura. Passa al TTL 1 ora o alza la frequenza.
• Contesto conversation-appended in cima: se accodi il turno più recente sopra invece che sotto, ogni turno invalida tutti i precedenti. Il turno più recente sta sempre in fondo.

La regola d'oro che ripeto ogni volta che passiamo in code review un cambio di prompt: immagina il prompt come una torre di Lego. Le mattoncelle in basso non si toccano mai. Le mattoncelle in cima cambiano ogni chiamata. Se cambi una mattoncella in basso, tutta la torre crolla.

Domande frequenti

Quanto dura la cache dei prompt su Anthropic e OpenAI?

Anthropic ha TTL di 5 minuti di default, estendibile a 1 ora tramite l'header beta extended-cache-ttl-2025-04-11 pagando il 200% sulla scrittura. OpenAI ha TTL opaco (tipicamente 5–10 minuti, fino a un'ora nei periodi di basso carico) e non è configurabile. Google Gemini permette TTL arbitrario da secondi a giorni, ma paghi lo storage per la durata.

Il prompt caching riduce anche la latenza o solo il costo?

Entrambi. Anthropic riporta riduzioni fino all'85% della latenza time-to-first-token sui prompt lunghi, perché il modello non deve ri-processare il prefisso. OpenAI riporta miglioramenti simili sui modelli o-series. La riduzione è più marcata su prompt >10K token; sotto 2K il vantaggio latenza è trascurabile, ma il costo scende comunque.

Qual è la differenza tra prompt caching e semantic caching?

Il prompt caching è server-side e richiede corrispondenza byte-per-byte del prefisso: risparmia sulle chiamate LLM ma le esegue comunque. Il semantic caching è client-side e usa embedding più vector search per intercettare query semanticamente equivalenti prima della chiamata LLM: elimina completamente la chiamata. Sono complementari: metti prima il semantic per ridurre il volume, poi il prompt caching per ridurre il costo delle chiamate che restano.

Quando NON conviene attivare il prompt caching?

Se il prompt è quasi interamente dinamico (utente diverso, contesto diverso, domanda diversa), la cache non riesce mai a hittare e paghi solo l'overhead di scrittura. Anche se il tuo volume è basso (poche chiamate all'ora con lo stesso contesto), il TTL scade prima del riuso. In questi casi conviene puntare tutto sul semantic caching o rivedere l'architettura dei prompt.

Il prompt caching funziona con i function call e i tool use?

Sì, ma con attenzioni. Su Anthropic puoi mettere un breakpoint dopo il blocco tools: se lo schema dei tool non cambia, la cache tiene. Su OpenAI il caching automatico include gli schemi tool nel prefisso, quindi vale la stessa regola: metti gli schemi in un ordine stabile. Un cambio anche minimo di descrizione o parametro tool invalida la cache.

Come monitoro l'efficacia del prompt caching in produzione?

La metrica principale è la cache hit ratio sui token, non sulle richieste, perché ti dice quanti soldi stai davvero risparmiando. Aggiungi: reads per write (per Anthropic), latenza p99 divisa in cold vs warm, cache invalidation rate. LangSmith e Langfuse espongono queste metriche in dashboard pronte; alternativa self-hosted con OpenTelemetry GenAI semantic conventions e Prometheus.