Cache dei prompt

Il "prompt caching" (cache dei prompt) ottimizza l'utilizzo dell'API consentendo di riprendere da prefissi specifici nei tuoi prompt. Questo riduce significativamente i tempi di elaborazione e i costi per attività ripetitive o prompt con elementi costanti.

Esistono due modi per abilitare la cache dei prompt:

• Cache automatica: Aggiungi un singolo campo cache_control al livello superiore della tua richiesta. Il sistema applica automaticamente il breakpoint della cache all'ultimo blocco memorizzabile nella cache 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 nella cache automaticamente.
• 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 la cache automatica:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    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 la cache automatica, il sistema memorizza nella cache tutto il contenuto fino all'ultimo blocco memorizzabile incluso. Nelle richieste successive con lo stesso prefisso, il contenuto in 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à in cache da una query recente.
2. Se lo trova, usa la versione in cache, riducendo tempi di elaborazione e costi.
3. Altrimenti, elabora l'intero prompt e memorizza nella cache il prefisso 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 in cache viene utilizzato.

La durata viene misurata dall'inizio della richiesta che scrive o legge la voce della cache, non dalla fine della sua risposta. Il tempo impiegato per generare una risposta viene conteggiato nella durata: se una risposta richiede 4 minuti di streaming, una richiesta successiva che riutilizza lo stesso prefisso in cache deve iniziare entro circa 1 minuto dal completamento di quella risposta.

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:

^{1 Gli hit e gli aggiornamenti della cache su Claude Fable 5.1 e Claude Mythos 5.1 hanno un prezzo pari a 0,025x il prezzo di input base. Tutti gli altri modelli usano il moltiplicatore standard di 0,1x.}

Modelli supportati

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

Cache automatica

La cache automatica è 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 della cache all'ultimo blocco memorizzabile nella cache.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a helpful assistant that remembers our conversation.",
    messages=[
        {"role": "user", "content": "My name is Alex. I work on machine learning."},
        {
            "role": "assistant",
            "content": "Nice to meet you, Alex! How can I help with your ML work today?",
        },
        {"role": "user", "content": "What did I say I work on?"},
    ],
)
print(response.usage.model_dump_json())

Come funziona la cache automatica nelle conversazioni multi-turno

Con la cache automatica, 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 della cache si sposta automaticamente sull'ultimo blocco memorizzabile in ogni richiesta, quindi non devi aggiornare alcun marcatore cache_control man mano che la conversazione cresce.

Supporto TTL

Per impostazione predefinita, la cache automatica usa 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 la cache a livello di blocco

La cache automatica è compatibile con i breakpoint di cache espliciti. Quando usati insieme, il breakpoint della cache automatica occupa uno dei 4 slot di breakpoint disponibili.

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

{
  "model": "claude-opus-5",
  "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

La cache automatica usa la stessa infrastruttura di cache 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, la cache automatica non ha alcun 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 la cache automatica).
• Se l'ultimo blocco non è idoneo come destinazione di un breakpoint di cache automatica, il sistema risale silenziosamente all'indietro per trovare il blocco idoneo più vicino. Se non ne trova nessuno, la cache viene saltata.

Breakpoint di cache espliciti

Per un maggiore controllo sulla cache, 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 tuo 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 la cache usando il parametro cache_control.

I prefissi della 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 usare 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 ti aiuta a ottimizzare la tua strategia di cache.

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 alcuna posizione precedente. Poiché l'hash è cumulativo e copre tutto fino al breakpoint incluso, modificare qualsiasi blocco al breakpoint o prima di esso produce un hash diverso alla richiesta successiva.

2. Le letture dalla cache cercano all'indietro le voci scritte da richieste precedenti. A ogni richiesta il sistema calcola l'hash del prefisso al tuo breakpoint e verifica se esiste una voce di cache corrispondente. Se non esiste, risale all'indietro un blocco alla volta, verificando se l'hash del prefisso in ciascuna posizione precedente corrisponde a qualcosa già presente nella cache. Cerca 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). Sulla Claude API, una sequenza di blocchi tool_use consecutivi conta come una posizione, e lo stesso vale per una sequenza di blocchi tool_result consecutivi, quindi un turno con molte chiamate di strumenti parallele non spinge da solo la voce della richiesta precedente fuori dalla finestra.

Esempio: Lookback in una conversazione crescente

Aggiungi nuovi blocchi a ogni turno e imposti cache_control sull'ultimo blocco 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 risale al blocco 10 e trova la voce del turno 1. Cache hit al blocco 10; il sistema elabora da zero solo i blocchi da 11 a 15 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'è alcun cache hit. Aggiungere un secondo breakpoint al blocco 15 avvia lì una seconda finestra di lookback, che trova la voce del turno 2.

Errore comune: Breakpoint su contenuto che cambia a ogni richiesta

Il tuo prompt ha un ampio 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 nella 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 attraversa 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 una nuova scrittura nella cache a ogni richiesta e non ottieni mai una lettura.

Il lookback non trova contenuto stabile dietro il tuo breakpoint per memorizzarlo nella cache. Trova voci che richieste precedenti hanno già scritto, e le scritture avvengono solo ai breakpoint. Sposta cache_control al blocco 5, l'ultimo blocco che rimane uguale tra le richieste, e ogni richiesta successiva leggerà il prefisso in cache. La cache automatica 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.

Punto chiave: Posiziona cache_control sull'ultimo blocco il cui prefisso è identico tra le richieste che vuoi condividano una cache. In una conversazione crescente l'ultimo blocco funziona finché ogni turno aggiunge 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 più controllo su cosa esattamente viene memorizzato nella cache
• Garantire un cache hit quando una conversazione crescente spinge il tuo breakpoint 20 o più blocchi oltre l'ultima scrittura nella cache

Comprendere i costi dei breakpoint di cache

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

• Scritture nella cache: Quando nuovo contenuto viene scritto nella cache (25% in più rispetto ai token di input base per il TTL di 5 minuti)
• Letture dalla cache: Quando il contenuto in cache viene utilizzato (10% del prezzo base dei token di input, o 2,5% su Claude Fable 5.1 e Claude Mythos 5.1)
• Token di input regolari: Per qualsiasi contenuto non in 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 il controllo su quali sezioni possono essere memorizzate nella cache in modo indipendente.

Strategie e considerazioni sulla cache

Limitazioni della cache

Sulla Claude API, Claude Platform on AWS, Google Cloud e Microsoft Foundry, la lunghezza minima del prompt memorizzabile nella cache è:

• 512 token per Claude Fable 5.1, Claude Mythos 5.1, Claude Opus 5, 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 5, Claude Sonnet 4.6, Claude Sonnet 4.5, Claude Opus 4.1 (ritirato, tranne su Bedrock e Google Cloud), Claude Opus 4 (ritirato, tranne su Google Cloud) e Claude Sonnet 4 (ritirato, tranne su Bedrock e Google Cloud)
• 4.096 token per Claude Haiku 4.5
• 2.048 token per Claude Haiku 3.5 (ritirato, tranne su Bedrock e Google Cloud)

Questi minimi si applicano su ogni piattaforma in cui ciascun modello è disponibile.

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 cache, e non viene restituito alcun errore. Per verificare se un prompt è stato memorizzato nella cache, controlla i campi usage 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 la tua piattaforma, spesso vale la pena espandere il contenuto in cache per raggiungere la soglia. Le letture dalla cache costano significativamente meno dei token di input non in cache, quindi raggiungere il minimo può ridurre i costi per i prompt riutilizzati frequentemente.

Per le richieste concorrenti, tieni presente che una voce di cache diventa disponibile solo dopo l'inizio della prima risposta. 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 dell'utente che dell'assistente
• Immagini e documenti: Blocchi di contenuto nell'array messages.content, nei turni dell'utente
• Uso degli strumenti e risultati degli strumenti: Blocchi di contenuto nell'array messages.content, sia nei turni dell'utente che dell'assistente

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

Cosa non può essere memorizzato nella cache

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

• I blocchi di thinking non possono essere memorizzati nella cache direttamente con cache_control. Tuttavia, i blocchi di thinking POSSONO essere memorizzati nella cache insieme ad altro contenuto quando compaiono in turni precedenti dell'assistente. 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 permette di usare 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 in cache possono invalidare parte o tutta la cache.

Come descritto in Strutturare il tuo 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 viene invalidata, mentre ✓ indica che la cache rimane valida.

Monitorare le prestazioni della cache

Monitora le prestazioni della cache usando questi campi della risposta API, all'interno di usage nella risposta (o nell'evento message_start in caso di 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é usati per creare una cache (cioè, i token dopo l'ultimo breakpoint di cache).

Cache con blocchi di thinking

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

Cache automatica insieme ad altro contenuto: Sebbene i blocchi di thinking 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 ripassi i blocchi di thinking per continuare la conversazione.

Conteggio dei token di input: Quando i blocchi di thinking 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 thinking vengono preservati per impostazione predefinita anche quando viene aggiunto contenuto utente diverso dai risultati degli strumenti, 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 diverso dai risultati degli strumenti, causando la rimozione dal contesto di tutti i blocchi di thinking precedenti
• Questo comportamento della cache 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 thinking precedenti vengono rimossi dal contesto a questo punto. Su Opus 4.5+ e Sonnet 4.6+, i blocchi di thinking precedenti vengono mantenuti per impostazione predefinita e rimangono parte del prefisso in cache.

Per informazioni più dettagliate, consulta Thinking e cache dei prompt.

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 usano prompt identici. Le cache sono inoltre isolate per workspace all'interno di un'organizzazione sulla Claude API, su Claude Platform on AWS e su Microsoft Foundry; Bedrock e Google Cloud usano 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 dei 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 usata.

Best practice per una cache efficace

Per ottimizzare le prestazioni della cache dei prompt:

• Inizia con la cache automatica per le conversazioni multi-turno. Gestisce automaticamente i breakpoint.
• Usa i 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 in cache all'inizio del prompt per le migliori prestazioni.
• Usa i breakpoint di cache in modo strategico per separare diverse sezioni di prefisso memorizzabili nella cache.
• 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 programmazione: Migliora l'autocompletamento e le domande e risposte sulla codebase mantenendo nel prompt le sezioni rilevanti o una versione riassunta della codebase.
• Elaborazione di documenti di grandi dimensioni: Incorpora nel tuo prompt materiale completo di lunga forma, incluse immagini, 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 più di 20 esempi diversificati di risposte di alta qualità.
• Uso degli strumenti agentico: Migliora le prestazioni per scenari che coinvolgono più chiamate di strumenti e modifiche iterative al codice, dove ogni passaggio richiede tipicamente una nuova chiamata API.
• Parla con libri, articoli, documentazione, trascrizioni di podcast e altri contenuti di lunga forma: Dai vita a qualsiasi base di conoscenza incorporando l'intero documento (o documenti) nel prompt e lasciando che gli utenti gli pongano domande.

Risoluzione dei problemi comuni

Se riscontri un comportamento inatteso:

• Assicurati che le sezioni in cache siano identiche tra le chiamate. Per i breakpoint espliciti, verifica che i marcatori cache_control siano nelle stesse posizioni
• Controlla che le chiamate vengano effettuate entro la durata della cache (5 minuti per impostazione predefinita)
• Verifica che tool_choice, l'uso delle immagini, la configurazione del thinking e output_config.effort rimangano coerenti tra le chiamate
• Verifica di memorizzare nella cache almeno il numero minimo di token per il tuo modello e la tua piattaforma (consulta Limitazioni della cache)
• Conferma che il tuo breakpoint sia su un blocco che rimane identico tra le richieste. Le scritture nella 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 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, rompendo 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 usare la cache estesa, includi ttl nella definizione di cache_control in questo modo:

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

La risposta include 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 l'attuale campo cache_creation_input_tokens è uguale alla somma dei valori nell'oggetto cache_creation.

Se vedi scritture ephemeral_5m_input_tokens che non hai richiesto mentre usi strumenti server come la ricerca web, consulta Uso degli strumenti con la cache dei prompt.

Quando usare la cache di 1 ora

Se hai prompt che vengono usati con cadenza regolare (cioè, prompt di sistema usati più frequentemente di ogni 5 minuti), continua a usare la cache di 5 minuti, perché questa continuerà a essere aggiornata senza costi aggiuntivi.

La cache di 1 ora è ideale nei seguenti scenari:

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

Combinare TTL diversi

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

Quando combini TTL diversi, 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:

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

Ecco tre esempi. Questo raffigura i token di input di 3 richieste, ciascuna delle quali ha cache hit e cache miss diversi. Di conseguenza, ciascuna ha un prezzo calcolato diverso, mostrato nei riquadri colorati.

Pre-riscaldamento della cache

Il "cache pre-warming" (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 dovuta al cache miss sulla prima interazione dell'utente, riducendo il "time-to-first-token" (tempo al primo token), o TTFT, per le 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 in corrispondenza di 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 successiva (tipicamente il tuo prompt di sistema o le definizioni degli strumenti), non sul messaggio utente segnaposto. Altrimenti la voce della cache viene associata al segnaposto e la richiesta successiva non la troverà. Usa anche la stessa configurazione di thinking e lo stesso output_config.effort delle tue richieste successive: questi valori vengono resi nel prompt (vedi Cosa invalida la cache), quindi un pre-riscaldamento con una configurazione diversa può scrivere una voce che il tuo traffico reale non raggiunge mai. Questo significa usare un breakpoint di cache esplicito anziché la cache automatica, poiché la cache automatica posiziona il breakpoint sull'ultimo blocco, che in questo caso è il segnaposto. Il messaggio utente segnaposto può essere qualsiasi stringa con contenuto diverso da spazi bianchi (gli esempi qui usano "warmup"); il suo contenuto viene letto nel modello ma non riceve mai risposta.

client = anthropic.Anthropic()

# Esegui questo prima dell'arrivo degli utenti per preriscaldare la cache condivisa del prompt di sistema.
prewarm = client.messages.create(
    model="claude-opus-5",
    max_tokens=0,
    system=[
        {
            "type": "text",
            "text": "You are an expert software engineer with deep knowledge of distributed systems...",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "warmup"}],
)
print(prewarm.stop_reason)  # "max_tokens"
print(prewarm.content)  # []
print(prewarm.usage)

L'API restituisce un array content vuoto:

{
  "id": "msg_01XFDUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "content": [],
  "model": "claude-opus-5",
  "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"
  }
}

Schema di utilizzo tipico

Invia una richiesta di pre-riscaldamento all'avvio della tua applicazione (o a intervalli pianificati), 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-5",
        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-5",
        max_tokens=1024,
        system=SYSTEM_PROMPT,
        messages=[{"role": "user", "content": user_message}],
    )


# Riscalda la cache prima che arrivi il traffico degli utenti.
prewarm_cache()

# Più tardi, quando l'utente invia un messaggio, il prefisso del prompt di sistema è già in cache.
response = respond("How do I implement a binary search tree?")
for block in response.content:
    if block.type == "text":
        print(block.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 degli utenti, 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 elementi, 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-riscaldamento 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 la soluzione alternativa max_tokens=1

Prima che max_tokens: 0 fosse disponibile, alcune applicazioni usavano chiamate di riscaldamento con max_tokens: 1 per ottenere lo stesso effetto. L'approccio max_tokens: 0 è preferibile: non viene prodotto alcun output, quindi non c'è alcuna 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 schemi di cache dei prompt. Questi esempi dimostrano come implementare la cache in diversi scenari, aiutandoti a comprendere le applicazioni pratiche di questa funzionalità:

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "You are an AI assistant tasked with analyzing legal documents.",
        },
        {
            "type": "text",
            "text": "Here is the full text of a complex legal agreement: [Insert full text of a 50-page legal agreement here]",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "What are the key terms and conditions in this agreement?",
        }
    ],
)
print(response.usage.model_dump_json())

{
  "model": "claude-opus-5",
  "max_tokens": 1024,
  "tools": [
    {
      "name": "get_weather",
      "description": "Get the current weather in a given location",
      "input_schema": {
        "type": "object",
        "properties": { "location": { "type": "string" } },
        "required": ["location"]
      }
    },
    {
      "name": "get_time",
      "description": "Get the current time in a given time zone",
      "input_schema": {
        "type": "object",
        "properties": { "timezone": { "type": "string" } },
        "required": ["timezone"]
      },
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "What is the weather and time in New York?" }]
}

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "...long system prompt",
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        # ...lunga conversazione finora
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Hello, can you tell me more about the solar system?",
                }
            ],
        },
        {
            "role": "assistant",
            "content": "Certainly! The solar system is the collection of celestial bodies that orbit our Sun. It consists of eight planets, numerous moons, asteroids, comets, and other objects. The planets, in order from closest to farthest from the Sun, are: Mercury, Venus, Earth, Mars, Jupiter, Saturn, Uranus, and Neptune. Each planet has its own unique characteristics and features. Is there a specific aspect of the solar system you'd like to know more about?",
        },
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Good to know."},
                {
                    "type": "text",
                    "text": "Tell me more about Mars.",
                    "cache_control": {"type": "ephemeral"},
                },
            ],
        },
    ],
)
print(response.usage.model_dump_json())

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    tools=[
        {
            "name": "search_documents",
            "description": "Search through the knowledge base",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "Search query"}
                },
                "required": ["query"],
            },
        },
        {
            "name": "get_document",
            "description": "Retrieve a specific document by ID",
            "input_schema": {
                "type": "object",
                "properties": {
                    "doc_id": {"type": "string", "description": "Document ID"}
                },
                "required": ["doc_id"],
            },
            "cache_control": {"type": "ephemeral"},
        },
    ],
    system=[
        {
            "type": "text",
            "text": "You are a helpful research assistant with access to a document knowledge base.\n\n# Instructions\n- Always search for relevant documents before answering\n- Provide citations for your sources\n- Be objective and accurate in your responses\n- If multiple documents contain relevant information, synthesize them\n- Acknowledge when information is not available in the knowledge base",
            "cache_control": {"type": "ephemeral"},
        },
        {
            "type": "text",
            "text": "# Knowledge Base Context\n\nHere are the relevant documents for this conversation:\n\n## Document 1: Solar System Overview\nThe solar system consists of the Sun and all objects that orbit it...\n\n## Document 2: Planetary Characteristics\nEach planet has unique features. Mercury is the smallest planet...\n\n## Document 3: Mars Exploration\nMars has been a target of exploration for decades...\n\n[Additional documents...]",
            "cache_control": {"type": "ephemeral"},
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "Can you search for information about Mars rovers?",
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "tool_use",
                    "id": "tool_1",
                    "name": "search_documents",
                    "input": {"query": "Mars rovers"},
                }
            ],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "tool_result",
                    "tool_use_id": "tool_1",
                    "content": "Found 3 relevant documents: Document 3 (Mars Exploration), Document 7 (Rover Technology), Document 9 (Mission History)",
                }
            ],
        },
        {
            "role": "assistant",
            "content": [
                {
                    "type": "text",
                    "text": "I found 3 relevant documents about Mars rovers. Let me get more details from the Mars Exploration document.",
                }
            ],
        },
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Yes, please tell me about the Perseverance rover specifically.",
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        },
    ],
)
print(response.usage.model_dump_json())

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 in cache sono conservati solo in memoria e non vengono memorizzati a riposo. Le voci in 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, sulla Claude API, su Claude Platform su AWS e su Microsoft Foundry, tra i workspace all'interno di un'organizzazione.

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

FAQ

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

client.beta.prompt_caching.messages.create(**params)

client.messages.create(**params)

client.beta.promptCaching.messages.create(/* ... */);

client.messages.create(/* ... */);