Cache dei prompt

La cache dei prompt ottimizza l'utilizzo dell'API consentendo di riprendere da prefissi specifici nei tuoi prompt. Questo riduce significativamente il tempo di elaborazione e i costi per attività ripetitive o prompt con elementi costanti.

Esistono due modi per abilitare la cache dei prompt:

• Caching automatico: Aggiungi un singolo campo cache_control al livello superiore della tua richiesta. Il sistema applica automaticamente il breakpoint di cache all'ultimo blocco memorizzabile e lo sposta in avanti man mano che le conversazioni crescono. Ideale per conversazioni multi-turno in cui la cronologia crescente dei messaggi deve essere memorizzata automaticamente nella cache.
• Breakpoint di cache espliciti: Posiziona cache_control direttamente sui singoli blocchi di contenuto per un controllo granulare su cosa esattamente viene memorizzato nella cache.

Il modo più semplice per iniziare è con il caching automatico:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are an AI assistant tasked with analyzing literary works. Your goal is to provide insightful commentary on themes, characters, and writing style.",
    messages=[
        {
            "role": "user",
            "content": "Analyze the major themes in 'Pride and Prejudice'.",
        }
    ],
)
print(response.usage.model_dump_json())

Con il caching automatico, il sistema memorizza nella cache tutto il contenuto fino all'ultimo blocco memorizzabile incluso. Nelle richieste successive con lo stesso prefisso, il contenuto memorizzato nella cache viene riutilizzato automaticamente.



Come funziona la cache dei prompt

Quando invii una richiesta con la cache dei prompt abilitata:

1. Il sistema verifica se un prefisso del prompt, fino a un breakpoint di cache specificato, è già memorizzato nella cache da una query recente.
2. Se trovato, utilizza la versione memorizzata nella cache, riducendo il tempo di elaborazione e i costi.
3. Altrimenti, elabora l'intero prompt e memorizza il prefisso nella cache una volta che la risposta inizia.

Questo è particolarmente utile per:

• Prompt con molti esempi
• Grandi quantità di contesto o informazioni di background
• Attività ripetitive con istruzioni costanti
• Lunghe conversazioni multi-turno

Per impostazione predefinita, la cache ha una durata di 5 minuti. La cache viene aggiornata senza costi aggiuntivi ogni volta che il contenuto memorizzato viene utilizzato.



Prezzi

La cache dei prompt introduce una nuova struttura di prezzi. La tabella seguente mostra il prezzo per milione di token per ciascun modello supportato:



Modelli supportati

La cache dei prompt (sia automatica che esplicita) è supportata su tutti i modelli Claude attivi.



Caching automatico

Il caching automatico è il modo più semplice per abilitare la cache dei prompt. Invece di posizionare cache_control sui singoli blocchi di contenuto, aggiungi un singolo campo cache_control al livello superiore del corpo della richiesta. Il sistema applica automaticamente il breakpoint di cache all'ultimo blocco memorizzabile.



Come funziona il caching automatico nelle conversazioni multi-turno

Con il caching automatico, il punto di cache si sposta in avanti automaticamente man mano che le conversazioni crescono. Ogni nuova richiesta memorizza nella cache tutto fino all'ultimo blocco memorizzabile, e il contenuto precedente viene letto dalla cache.

Il breakpoint di cache si sposta automaticamente all'ultimo blocco memorizzabile in ogni richiesta, quindi non è necessario aggiornare alcun marcatore cache_control man mano che la conversazione cresce.



Supporto TTL

Per impostazione predefinita, il caching automatico utilizza un TTL di 5 minuti. Puoi specificare un TTL di 1 ora a 2 volte il prezzo base dei token di input:

{ "cache_control": { "type": "ephemeral", "ttl": "1h" } }



Combinazione con il caching a livello di blocco

Il caching automatico è compatibile con i breakpoint di cache espliciti. Quando usati insieme, il breakpoint di cache automatico utilizza uno dei 4 slot di breakpoint disponibili.

Questo ti consente di combinare entrambi gli approcci. Ad esempio, usa un breakpoint esplicito per memorizzare nella cache il tuo prompt di sistema, mentre il caching automatico gestisce la conversazione:

{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "system": [
    {
      "type": "text",
      "text": "You are a helpful assistant.",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "What are the key terms?" }]
}



Cosa rimane invariato

Il caching automatico utilizza la stessa infrastruttura di caching sottostante. Prezzi, soglie minime di token, requisiti di ordinamento del contesto e la finestra di lookback di 20 blocchi si applicano tutti allo stesso modo dei breakpoint espliciti.



Casi limite

• Se l'ultimo blocco ha già un cache_control esplicito con lo stesso TTL, il caching automatico non ha effetto.
• Se l'ultimo blocco ha un cache_control esplicito con un TTL diverso, l'API restituisce un errore 400.
• Se esistono già 4 breakpoint espliciti a livello di blocco, l'API restituisce un errore 400 (nessuno slot rimasto per il caching automatico).
• Se l'ultimo blocco non è idoneo come target del breakpoint di cache automatico, il sistema procede silenziosamente all'indietro per trovare il blocco idoneo più vicino. Se non ne viene trovato nessuno, il caching viene saltato.



Breakpoint di cache espliciti

Per un maggiore controllo sul caching, puoi posizionare cache_control direttamente sui singoli blocchi di contenuto. Questo è utile quando devi memorizzare nella cache sezioni diverse che cambiano con frequenze diverse, o quando hai bisogno di un controllo granulare su cosa esattamente viene memorizzato nella cache.



Strutturare il prompt

Posiziona il contenuto statico (definizioni degli strumenti, istruzioni di sistema, contesto, esempi) all'inizio del tuo prompt. Contrassegna la fine del contenuto riutilizzabile per il caching utilizzando il parametro cache_control.

I prefissi di cache vengono creati nel seguente ordine: tools, system, poi messages. Questo ordine forma una gerarchia in cui ogni livello si basa sui precedenti.



Come funziona il controllo automatico dei prefissi

Puoi utilizzare un solo breakpoint di cache alla fine del tuo contenuto statico, e il sistema troverà automaticamente il prefisso più lungo che una richiesta precedente ha già scritto nella cache. Comprendere come funziona questo meccanismo ti aiuta a ottimizzare la tua strategia di caching.

Tre principi fondamentali:

1. Le scritture nella cache avvengono solo al tuo breakpoint. Contrassegnare un blocco con cache_control scrive esattamente una voce di cache: un hash del prefisso che termina in quel blocco. Il sistema non scrive voci per nessuna posizione precedente. Poiché l'hash è cumulativo, coprendo tutto fino al breakpoint incluso, modificare qualsiasi blocco al breakpoint o prima di esso produce un hash diverso nella richiesta successiva.

2. Le letture dalla cache cercano all'indietro le voci che le richieste precedenti hanno scritto. A ogni richiesta il sistema calcola l'hash del prefisso al tuo breakpoint e verifica la presenza di una voce di cache corrispondente. Se non esiste, procede all'indietro un blocco alla volta, verificando se l'hash del prefisso in ogni posizione precedente corrisponde a qualcosa già presente nella cache. Sta cercando scritture precedenti, non contenuto stabile.

3. La finestra di lookback è di 20 blocchi. Il sistema controlla al massimo 20 posizioni per breakpoint, contando il breakpoint stesso come la prima. Se il sistema non trova alcuna voce corrispondente in quella finestra, il controllo si interrompe (o riprende dal breakpoint esplicito successivo, se presente).

Esempio: Lookback in una conversazione in crescita

Aggiungi nuovi blocchi a ogni turno e imposti cache_control sul blocco finale di ogni richiesta:

• Turno 1: 10 blocchi, breakpoint sul blocco 10. Non esistono voci di cache precedenti. Il sistema scrive una voce al blocco 10.
• Turno 2: 15 blocchi, breakpoint sul blocco 15. Il blocco 15 non ha alcuna voce, quindi il sistema procede all'indietro fino al blocco 10 e trova la voce del turno 1. Cache hit al blocco 10; il sistema elabora solo i blocchi da 11 a 15 ex novo e scrive una nuova voce al blocco 15.
• Turno 3: 35 blocchi, breakpoint sul blocco 35. Il sistema controlla 20 posizioni (blocchi da 35 a 16) e non trova nulla. La voce del turno 2 al blocco 15 è una posizione fuori dalla finestra, quindi non c'è cache hit. Aggiungere un secondo breakpoint al blocco 15 avvia una seconda finestra di lookback lì, che trova la voce del turno 2.

Errore comune: Breakpoint su contenuto che cambia a ogni richiesta

Il tuo prompt ha un grande contesto di sistema statico (blocchi da 1 a 5) seguito da un blocco per richiesta contenente un timestamp e il messaggio dell'utente (blocco 6). Imposti cache_control sul blocco 6:

• Richiesta 1: Scrittura cache al blocco 6. L'hash include il timestamp.
• Richiesta 2: Il timestamp è diverso, quindi l'hash del prefisso al blocco 6 è diverso. Il lookback procede attraverso i blocchi 5, 4, 3, 2 e 1, ma il sistema non ha mai scritto una voce in nessuna di quelle posizioni. Nessun cache hit. Paghi per una nuova scrittura cache a ogni richiesta e non ottieni mai una lettura.

Il lookback non trova contenuto stabile dietro il tuo breakpoint e lo memorizza nella cache. Trova voci che le richieste precedenti hanno già scritto, e le scritture avvengono solo ai breakpoint. Sposta cache_control al blocco 5, l'ultimo blocco che rimane invariato tra le richieste, e ogni richiesta successiva leggerà il prefisso memorizzato nella cache. Il caching automatico cade nella stessa trappola: posiziona il breakpoint sull'ultimo blocco memorizzabile, che in questa struttura è quello che cambia a ogni richiesta, quindi usa invece un breakpoint esplicito sul blocco 5.

Conclusione chiave: Posiziona cache_control sull'ultimo blocco il cui prefisso è identico tra le richieste che vuoi condividano una cache. In una conversazione in crescita il blocco finale funziona purché ogni turno aggiunga meno di 20 blocchi: il contenuto precedente non cambia mai, quindi il lookback della richiesta successiva trova la scrittura precedente. Per un prompt con un suffisso variabile (timestamp, contesto per richiesta, il messaggio in arrivo), posiziona il breakpoint alla fine del prefisso statico, non sul blocco variabile.



Quando usare più breakpoint

Puoi definire fino a 4 breakpoint di cache se vuoi:

• Memorizzare nella cache sezioni diverse che cambiano con frequenze diverse (ad esempio, gli strumenti cambiano raramente, ma il contesto si aggiorna quotidianamente)
• Avere maggiore controllo su cosa esattamente viene memorizzato nella cache
• Garantire un cache hit quando una conversazione in crescita spinge il tuo breakpoint 20 o più blocchi oltre l'ultima scrittura cache



Comprendere i costi dei breakpoint di cache

I breakpoint di cache di per sé non aggiungono alcun costo. Ti viene addebitato solo per:

• Scritture cache: Quando nuovo contenuto viene scritto nella cache (25% in più rispetto ai token di input base per TTL di 5 minuti)
• Letture cache: Quando il contenuto memorizzato nella cache viene utilizzato (10% del prezzo base dei token di input)
• Token di input regolari: Per qualsiasi contenuto non memorizzato nella cache

Aggiungere più breakpoint cache_control non aumenta i tuoi costi - paghi comunque lo stesso importo in base a quale contenuto viene effettivamente memorizzato nella cache e letto. I breakpoint ti danno semplicemente il controllo su quali sezioni possono essere memorizzate nella cache in modo indipendente.



Strategie e considerazioni sul caching



Limitazioni della cache

Sull'API Claude, Claude Platform on AWS, Vertex AI e Microsoft Foundry (beta), la lunghezza minima del prompt memorizzabile nella cache è:

• 512 token per Claude Fable 5 e Claude Mythos 5
• 2.048 token per Claude Mythos Preview e Claude Opus 4.7
• 4.096 token per Claude Opus 4.6 e Claude Opus 4.5
• 1.024 token per Claude Opus 4.8, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1 (deprecato), Claude Opus 4 (deprecato) e Claude Sonnet 4 (deprecato)
• 4.096 token per Claude Haiku 4.5
• 2.048 token per Claude Haiku 3.5 (ritirato, eccetto su Vertex AI)

La disponibilità dei modelli varia in base alla piattaforma, così come il minimo per i modelli appena rilasciati: su Amazon Bedrock, la lunghezza minima del prompt memorizzabile nella cache per Claude Fable 5 e Claude Mythos 5 è di 1.024 token.

I prompt più brevi non possono essere memorizzati nella cache, anche se contrassegnati con cache_control. Qualsiasi richiesta di memorizzare nella cache meno di questo numero di token verrà elaborata senza caching, e non verrà restituito alcun errore. Per verificare se un prompt è stato memorizzato nella cache, controlla i campi di utilizzo della risposta: se sia cache_creation_input_tokens che cache_read_input_tokens sono 0, il prompt non è stato memorizzato nella cache (probabilmente perché non soddisfaceva il requisito di lunghezza minima).

Se il tuo prompt è appena al di sotto del minimo per il tuo modello e piattaforma, espandere il contenuto memorizzato nella cache per raggiungere la soglia è spesso vantaggioso. Le letture dalla cache costano significativamente meno dei token di input non memorizzati nella cache, quindi raggiungere il minimo può ridurre i costi per i prompt riutilizzati frequentemente.

Per le richieste concorrenti, nota che una voce di cache diventa disponibile solo dopo che la prima risposta inizia. Se hai bisogno di cache hit per richieste parallele, attendi la prima risposta prima di inviare le richieste successive.

Attualmente, "ephemeral" è l'unico tipo di cache supportato, che per impostazione predefinita ha una durata di 5 minuti.



Cosa può essere memorizzato nella cache

La maggior parte dei blocchi nella richiesta può essere memorizzata nella cache. Questo include:

• Strumenti: Definizioni degli strumenti nell'array tools
• Messaggi di sistema: Blocchi di contenuto nell'array system
• Messaggi di testo: Blocchi di contenuto nell'array messages.content, sia per i turni utente che assistente
• Immagini e documenti: Blocchi di contenuto nell'array messages.content, nei turni utente
• Uso degli strumenti e risultati degli strumenti: Blocchi di contenuto nell'array messages.content, sia nei turni utente che assistente

Ciascuno di questi elementi può essere memorizzato nella cache, automaticamente o contrassegnandoli con cache_control.



Cosa non può essere memorizzato nella cache

Sebbene la maggior parte dei blocchi di richiesta possa essere memorizzata nella cache, ci sono alcune eccezioni:

• I blocchi di pensiero non possono essere memorizzati nella cache direttamente con cache_control. Tuttavia, i blocchi di pensiero POSSONO essere memorizzati nella cache insieme ad altro contenuto quando appaiono nei turni assistente precedenti. Quando memorizzati nella cache in questo modo, CONTANO come token di input quando letti dalla cache.

• I sotto-blocchi di contenuto (come le citazioni) non possono essere memorizzati nella cache direttamente. Memorizza invece nella cache il blocco di livello superiore.

  Nel caso delle citazioni, i blocchi di contenuto documento di livello superiore che fungono da materiale sorgente per le citazioni possono essere memorizzati nella cache. Questo ti consente di utilizzare efficacemente la cache dei prompt con le citazioni memorizzando nella cache i documenti a cui le citazioni faranno riferimento.

• I blocchi di testo vuoti non possono essere memorizzati nella cache.



Cosa invalida la cache

Le modifiche al contenuto memorizzato nella cache possono invalidare parte o tutta la cache.

Come descritto in Strutturare il prompt, la cache segue la gerarchia: tools → system → messages. Le modifiche a ciascun livello invalidano quel livello e tutti i livelli successivi.

La tabella seguente mostra quali parti della cache vengono invalidate da diversi tipi di modifiche. ✘ indica che la cache è invalidata, mentre ✓ indica che la cache rimane valida.



Monitorare le prestazioni della cache

Monitora le prestazioni della cache utilizzando questi campi di risposta dell'API, all'interno di usage nella risposta (o nell'evento message_start se usi lo streaming):

• cache_creation_input_tokens: Numero di token scritti nella cache durante la creazione di una nuova voce.
• cache_read_input_tokens: Numero di token recuperati dalla cache per questa richiesta.
• input_tokens: Numero di token di input che non sono stati letti dalla cache né utilizzati per crearne una (ovvero, i token dopo l'ultimo breakpoint di cache).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens



Caching con blocchi di pensiero

Quando usi il pensiero esteso con la cache dei prompt, i blocchi di pensiero hanno un comportamento speciale:

Caching automatico insieme ad altro contenuto: Sebbene i blocchi di pensiero non possano essere contrassegnati esplicitamente con cache_control, vengono memorizzati nella cache come parte del contenuto della richiesta quando effettui chiamate API successive con risultati degli strumenti. Questo accade comunemente durante l'uso degli strumenti quando passi indietro i blocchi di pensiero per continuare la conversazione.

Conteggio dei token di input: Quando i blocchi di pensiero vengono letti dalla cache, contano come token di input nelle tue metriche di utilizzo. Questo è importante per il calcolo dei costi e la pianificazione del budget di token.

Pattern di invalidazione della cache:

• La cache rimane valida quando vengono forniti solo risultati degli strumenti come messaggi utente
• Su Opus 4.5+ e Sonnet 4.6+, i blocchi di pensiero vengono preservati per impostazione predefinita anche quando viene aggiunto contenuto utente non-tool-result, quindi la cache rimane valida
• Sui modelli Opus/Sonnet precedenti e su tutti i modelli Haiku, la cache viene invalidata quando viene aggiunto contenuto utente non-tool-result, causando la rimozione di tutti i blocchi di pensiero precedenti dal contesto
• Questo comportamento di caching si verifica anche senza marcatori cache_control espliciti

Per maggiori dettagli sull'invalidazione della cache, consulta Cosa invalida la cache.

Esempio con uso degli strumenti:

Request 1: User: "What's the weather in Paris?"
Response: [thinking_block_1] + [tool_use block 1]

Request 2:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True]
Response: [thinking_block_2] + [text block 2]
# Request 2 caches its request content (not the response)
# The cache includes: user message, thinking_block_1, tool_use block 1, and tool_result_1

Request 3:
User: ["What's the weather in Paris?"],
Assistant: [thinking_block_1] + [tool_use block 1],
User: [tool_result_1, cache=True],
Assistant: [thinking_block_2] + [text block 2],
User: [Text response, cache=True]
# On earlier Opus/Sonnet and all Haiku models, non-tool-result user block causes prior thinking blocks to be stripped; on Opus 4.5+/Sonnet 4.6+ they are kept

Sui modelli Opus/Sonnet precedenti e su tutti i modelli Haiku, tutti i blocchi di pensiero precedenti vengono rimossi dal contesto a questo punto. Su Opus 4.5+ e Sonnet 4.6+, i blocchi di pensiero precedenti vengono mantenuti per impostazione predefinita e rimangono parte del prefisso memorizzato nella cache.

Per informazioni più dettagliate, consulta la documentazione sul pensiero esteso.



Archiviazione e condivisione della cache

• Isolamento per organizzazione e workspace: Le cache sono isolate tra organizzazioni. Organizzazioni diverse non condividono mai le cache, anche se utilizzano prompt identici. A partire dal 5 febbraio 2026, le cache sono isolate anche per workspace all'interno di un'organizzazione sull'API Claude, Claude Platform on AWS e Microsoft Foundry (beta); Bedrock e Vertex AI continuano a utilizzare solo l'isolamento a livello di organizzazione.

• Corrispondenza esatta: I cache hit richiedono segmenti di prompt identici al 100%, inclusi tutto il testo e le immagini fino al blocco contrassegnato con cache control incluso.

• Generazione di token di output: La cache dei prompt non ha alcun effetto sulla generazione dei token di output. La risposta che ricevi è identica a quella che otterresti se la cache dei prompt non fosse utilizzata.



Best practice per un caching efficace

Per ottimizzare le prestazioni della cache dei prompt:

• Inizia con il caching automatico per le conversazioni multi-turno. Gestisce automaticamente i breakpoint.
• Usa breakpoint espliciti a livello di blocco quando devi memorizzare nella cache sezioni diverse con frequenze di modifica diverse.
• Memorizza nella cache contenuto stabile e riutilizzabile come istruzioni di sistema, informazioni di background, contesti ampi o definizioni di strumenti frequenti.
• Posiziona il contenuto memorizzato nella cache all'inizio del prompt per le migliori prestazioni.
• Usa i breakpoint di cache strategicamente per separare diverse sezioni di prefisso memorizzabili.
• Posiziona il breakpoint sull'ultimo blocco che rimane identico tra le richieste. Per un prompt con un prefisso statico e un suffisso variabile (timestamp, contesto per richiesta, il messaggio in arrivo), questo è la fine del prefisso, non il blocco variabile.
• Analizza regolarmente i tassi di cache hit e adatta la tua strategia secondo necessità.



Ottimizzazione per diversi casi d'uso

Adatta la tua strategia di cache dei prompt al tuo scenario:

• Agenti conversazionali: Riduci costi e latenza per conversazioni estese, specialmente quelle con istruzioni lunghe o documenti caricati.
• Assistenti di codifica: Migliora il completamento automatico e le Q&A sulla codebase mantenendo sezioni rilevanti o una versione riassunta della codebase nel prompt.
• Elaborazione di documenti di grandi dimensioni: Incorpora materiale completo in formato lungo, incluse le immagini, nel tuo prompt senza aumentare la latenza della risposta.
• Set di istruzioni dettagliati: Condividi elenchi estesi di istruzioni, procedure ed esempi per affinare le risposte di Claude. Gli sviluppatori spesso includono uno o due esempi nel prompt, ma con la cache dei prompt puoi ottenere prestazioni ancora migliori includendo oltre 20 esempi diversificati di risposte di alta qualità.
• Uso degli strumenti agentico: Migliora le prestazioni per scenari che coinvolgono più chiamate a strumenti e modifiche iterative al codice, dove ogni passaggio richiede tipicamente una nuova chiamata API.
• Dialoga con libri, articoli, documentazione, trascrizioni di podcast e altri contenuti in formato lungo: Dai vita a qualsiasi base di conoscenza incorporando l'intero documento (o documenti) nel prompt e consentendo agli utenti di porre domande.



Risoluzione dei problemi comuni

Se riscontri comportamenti imprevisti:

• Assicurati che le sezioni memorizzate nella cache siano identiche tra le chiamate. Per i breakpoint espliciti, verifica che i marcatori cache_control siano nelle stesse posizioni
• Verifica che le chiamate vengano effettuate entro la durata della cache (5 minuti per impostazione predefinita)
• Verifica che tool_choice e l'uso delle immagini rimangano coerenti tra le chiamate
• Verifica di memorizzare nella cache almeno il numero minimo di token per il tuo modello e piattaforma (consulta Limitazioni della cache)
• Conferma che il tuo breakpoint sia su un blocco che rimane identico tra le richieste. Le scritture cache avvengono solo al breakpoint, e se quel blocco cambia (timestamp, contesto per richiesta, il messaggio in arrivo), l'hash del prefisso non corrisponde mai. Il lookback non trova contenuto stabile dietro il breakpoint; trova solo voci che le richieste precedenti hanno scritto ai propri breakpoint
• Verifica che le chiavi nei tuoi blocchi di contenuto tool_use abbiano un ordinamento stabile, poiché alcuni linguaggi (ad esempio, Swift, Go) randomizzano l'ordine delle chiavi durante la conversione JSON, interrompendo le cache
• Usa la diagnostica della cache per far sì che l'API confronti richieste consecutive e riporti quale parte del prompt è divergente



Durata della cache di 1 ora

Se ritieni che 5 minuti siano troppo pochi, Anthropic offre anche una durata della cache di 1 ora a un costo aggiuntivo.

Per utilizzare la cache estesa, includi ttl nella definizione cache_control in questo modo:

"cache_control": {
  "type": "ephemeral",
  "ttl": "1h"
}

La risposta includerà informazioni dettagliate sulla cache come le seguenti:

{
  "usage": {
    "input_tokens": 2048,
    "cache_read_input_tokens": 1800,
    "cache_creation_input_tokens": 248,
    "output_tokens": 503,

    "cache_creation": {
      "ephemeral_5m_input_tokens": 148,
      "ephemeral_1h_input_tokens": 100
    }
  }
}

Nota che il campo cache_creation_input_tokens corrente è uguale alla somma dei valori nell'oggetto cache_creation.



Quando usare la cache di 1 ora

Se hai prompt che vengono utilizzati con cadenza regolare (ovvero, prompt di sistema utilizzati più frequentemente di ogni 5 minuti), continua a utilizzare la cache di 5 minuti, poiché questa continuerà a essere aggiornata senza costi aggiuntivi.

La cache di 1 ora è più adatta nei seguenti scenari:

• Quando hai prompt che probabilmente vengono utilizzati meno frequentemente di 5 minuti, ma più frequentemente di ogni ora. Ad esempio, quando un side-agent agentico impiegherà più di 5 minuti, o quando memorizzi una lunga conversazione chat con un utente e generalmente ti aspetti che quell'utente potrebbe non rispondere nei prossimi 5 minuti.
• Quando la latenza è importante e i tuoi prompt di follow-up potrebbero essere inviati oltre i 5 minuti.
• Quando vuoi migliorare l'utilizzo del tuo limite di velocità, poiché i cache hit non vengono detratti dal tuo limite di velocità.



Combinare TTL diversi

Puoi utilizzare sia controlli cache di 1 ora che di 5 minuti nella stessa richiesta, ma con un vincolo importante: le voci di cache con TTL più lungo devono apparire prima di quelle con TTL più breve (ovvero, una voce di cache di 1 ora deve apparire prima di qualsiasi voce di cache di 5 minuti).

Quando combini TTL, l'API determina tre posizioni di fatturazione nel tuo prompt:

1. Posizione A: Il conteggio dei token al cache hit più alto (o 0 se non ci sono hit).
2. Posizione B: Il conteggio dei token al blocco cache_control di 1 ora più alto dopo A (o uguale ad A se non ne esistono).
3. Posizione C: Il conteggio dei token all'ultimo blocco cache_control.

Ti verrà addebitato per:

1. Token di lettura cache per A.
2. Token di scrittura cache di 1 ora per (B - A).
3. Token di scrittura cache di 5 minuti per (C - B).

Ecco 3 esempi. Questo rappresenta i token di input di 3 richieste, ciascuna delle quali ha cache hit e cache miss diversi. Ciascuna ha un prezzo calcolato diverso, mostrato nei riquadri colorati, come risultato.



Pre-riscaldamento della cache

Il pre-riscaldamento della cache ti consente di caricare il tuo prompt di sistema o le definizioni degli strumenti nella cache dei prompt prima che un utente attivi una richiesta reale. Questo elimina la penalità di latenza da cache miss sulla prima interazione dell'utente, riducendo il "time-to-first-token" (tempo al primo token), o TTFT, per applicazioni sensibili alla latenza.



Come funziona

Imposta max_tokens: 0 nella tua richiesta. L'API legge il tuo prompt nel modello e scrive la cache a qualsiasi breakpoint cache_control, quindi restituisce immediatamente senza generare alcun output. La risposta ha un array content vuoto, stop_reason: "max_tokens" e un blocco usage completamente popolato.

Posiziona il breakpoint cache_control sull'ultimo blocco condiviso con la richiesta di follow-up (tipicamente il tuo prompt di sistema o le definizioni degli strumenti), non sul messaggio utente segnaposto. Altrimenti la voce di cache è associata al segnaposto e la richiesta di follow-up non la troverà. Questo significa utilizzare un breakpoint di cache esplicito anziché il caching automatico, poiché il caching automatico posiziona il breakpoint sull'ultimo blocco, che qui è il segnaposto. Il messaggio utente segnaposto può essere qualsiasi stringa con contenuto non composto solo da spazi (gli esempi qui usano "warmup"); il suo contenuto viene letto nel modello ma non riceve mai risposta.

L'API restituisce un array content vuoto:

{
  "id": "msg_01XFDUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "content": [],
  "model": "claude-opus-4-8",
  "stop_reason": "max_tokens",
  "stop_sequence": null,
  "usage": {
    "input_tokens": 8,
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 0,
    "cache_creation": {
      "ephemeral_5m_input_tokens": 5120,
      "ephemeral_1h_input_tokens": 0
    },
    "iterations": [
      {
        "input_tokens": 8,
        "output_tokens": 0,
        "cache_read_input_tokens": 0,
        "cache_creation_input_tokens": 5120,
        "cache_creation": {
          "ephemeral_5m_input_tokens": 5120,
          "ephemeral_1h_input_tokens": 0
        },
        "type": "message"
      }
    ],
    "output_tokens": 0,
    "service_tier": "standard",
    "inference_geo": "global"
  }
}



Pattern di utilizzo tipico

Invia una richiesta di pre-riscaldamento all'avvio della tua applicazione (o a intervalli programmati), quindi invia le richieste utente reali dopo il completamento del pre-riscaldamento:

client = anthropic.Anthropic()

SYSTEM_PROMPT = [
    {
        "type": "text",
        "text": "You are an expert software engineer with deep knowledge of distributed systems...",
        "cache_control": {"type": "ephemeral"},
    }
]


def prewarm_cache() -> None:
    """Call this at application startup or on a scheduled interval."""
    client.messages.create(
        model="claude-opus-4-8",
        max_tokens=0,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": "warmup"}],
    )


def respond(user_message: str) -> anthropic.types.Message:
    """The real user request; benefits from a warm cache."""
    return client.messages.create(
        model="claude-opus-4-8",
        max_tokens=1024,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": user_message}],
    )


# Riscalda la cache prima che arrivi qualsiasi traffico utente.
prewarm_cache()

# In seguito, quando l'utente invia un messaggio, il prefisso del prompt di sistema è già nella cache.
response = respond("How do I implement a binary search tree?")
print(response.content[0].text)

Tieni presente che il TTL della cache si applica comunque. Per la cache predefinita di 5 minuti, invia una nuova richiesta di pre-riscaldamento almeno ogni 5 minuti per mantenere la cache calda. Per intervalli più lunghi tra le richieste utente, usa invece la durata della cache di 1 ora.



Limitazioni

Una richiesta con max_tokens: 0 viene rifiutata con un invalid_request_error se è impostato uno qualsiasi dei seguenti parametri, poiché ciascuno implica un output che un budget di zero token non può produrre:

• stream: true
• Pensiero esteso (thinking.type: "enabled")
• Output strutturati (output_config.format)
• tool_choice di tipo {"type": "tool", ...} o {"type": "any"}

max_tokens: 0 viene rifiutato anche all'interno di una richiesta Message Batches. Il pre-warming mira al time-to-first-token, che non si applica all'elaborazione batch, e una voce di cache scritta durante l'elaborazione batch probabilmente scadrebbe prima dell'esecuzione della richiesta successiva.



Sostituire il workaround max_tokens=1

Prima che max_tokens: 0 fosse disponibile, alcune applicazioni utilizzavano chiamate di warm-up con max_tokens: 1 per ottenere lo stesso effetto. L'approccio max_tokens: 0 è preferibile: non viene prodotto alcun output, quindi non c'è nessuna risposta di un singolo token da scartare, non vengono fatturati token di output e l'intento della richiesta è inequivocabile.



Esempi di cache dei prompt

Per aiutarti a iniziare con la cache dei prompt, il cookbook sulla cache dei prompt fornisce esempi dettagliati e best practice.

I seguenti frammenti di codice mostrano vari pattern di cache dei prompt. Questi esempi dimostrano come implementare la cache in diversi scenari, aiutandoti a comprendere le applicazioni pratiche di questa funzionalità:



Conservazione dei dati

La cache dei prompt (sia automatica che esplicita) è idonea per ZDR. Anthropic non memorizza il testo grezzo dei tuoi prompt o delle risposte di Claude.

Le rappresentazioni della cache KV (key-value) e gli hash crittografici del contenuto memorizzato nella cache sono conservati solo in memoria e non vengono archiviati in modo persistente. Le voci memorizzate nella cache hanno una durata minima di 5 minuti (standard) o 1 ora (estesa), dopo la quale vengono eliminate prontamente, anche se non immediatamente. Le voci della cache sono isolate tra le organizzazioni e, sull'API Claude, Claude Platform su AWS e Microsoft Foundry (beta), tra i workspace all'interno di un'organizzazione.

Per l'idoneità ZDR su tutte le funzionalità, consulta API e conservazione dei dati.



FAQ

Questo è importante per comprendere sia i costi che i limiti di velocità, poiché input_tokens sarà tipicamente molto più piccolo del tuo input totale quando usi il caching in modo efficace.