Prompt caching

Prompt caching 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 coerenti.

Ci sono due modi per abilitare prompt caching:

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

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

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    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 tutto il contenuto fino a e incluso l'ultimo blocco cacheable. Nelle richieste successive con lo stesso prefisso, il contenuto memorizzato viene riutilizzato automaticamente.

Come funziona prompt caching

Quando invii una richiesta con prompt caching abilitato:

1. Il sistema verifica se un prefisso del prompt, fino a un breakpoint della cache specificato, è già memorizzato da una query recente.
2. Se trovato, utilizza la versione memorizzata, riducendo il tempo di elaborazione e i costi.
3. Altrimenti, elabora il prompt completo e memorizza 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 coerenti
• 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

Prompt caching introduce una nuova struttura di prezzi. La tabella seguente mostra il prezzo per milione di token per ogni modello supportato:

Modelli supportati

Prompt caching (sia automatico che esplicito) è supportato su tutti i modelli Claude attivi.

Caching automatico

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

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    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 il caching automatico nelle conversazioni multi-turno

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

Il breakpoint della cache si sposta automaticamente all'ultimo blocco cacheable 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 del token di input di base:

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

Combinazione con caching a livello di blocco

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

Questo ti consente di combinare entrambi gli approcci. Ad esempio, utilizza breakpoint espliciti per memorizzare il tuo prompt di sistema e gli strumenti in modo indipendente, mentre il caching automatico gestisce la conversazione:

{
  "model": "claude-opus-4-7",
  "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 uguale

Il caching automatico utilizza la stessa infrastruttura di caching sottostante. I prezzi, le soglie minime di token, i requisiti di ordinamento del contesto e la finestra di lookback di 20 blocchi si applicano 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 è un no-op.
• Se l'ultimo blocco ha un cache_control esplicito con un TTL diverso, l'API restituisce un errore 400.
• Se 4 breakpoint a livello di blocco espliciti già esistono, l'API restituisce un errore 400 (nessuno slot rimasto per il caching automatico).
• Se l'ultimo blocco non è idoneo come target di breakpoint della cache automatica, il sistema cammina silenziosamente all'indietro per trovare il blocco idoneo più vicino. Se nessuno viene trovato, il caching viene saltato.

Breakpoint della cache espliciti

Per un maggiore controllo sulla caching, puoi posizionare cache_control direttamente su singoli blocchi di contenuto. Questo è utile quando è necessario memorizzare diverse sezioni che cambiano a frequenze diverse, o quando è necessario un controllo granulare su esattamente cosa viene memorizzato.

Strutturazione del tuo prompt

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

I prefissi della cache vengono creati nel seguente ordine: tools, system, quindi messages. Questo ordine forma una gerarchia in cui ogni livello si basa su quelli precedenti.

Come funziona il controllo automatico del prefisso

Puoi utilizzare un solo breakpoint della 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 aiuta a ottimizzare la tua strategia di caching.

Tre principi fondamentali:

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

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

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

Esempio: Lookback in una conversazione in crescita

Aggiungi nuovi blocchi ad ogni turno e imposta cache_control sul blocco finale di ogni richiesta:

• Turno 1: 10 blocchi, breakpoint sul blocco 10. Non esistono voci della cache precedenti. Il sistema scrive una voce al blocco 10.
• Turno 2: 15 blocchi, breakpoint sul blocco 15. Il blocco 15 non ha voce, quindi il sistema cammina all'indietro al blocco 10 e trova la voce del turno 1. Cache hit al blocco 10; il sistema elabora solo i blocchi 11 attraverso 15 da zero e scrive una nuova voce al blocco 15.
• Turno 3: 35 blocchi, breakpoint sul blocco 35. Il sistema verifica 20 posizioni (blocchi 35 attraverso 16) e non trova nulla. La voce del turno 2 al blocco 15 è una posizione al di fuori della 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 ad ogni richiesta

Il tuo prompt ha un grande contesto di sistema statico (blocchi 1 attraverso 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 della cache al blocco 6. L'hash include il timestamp.
• Richiesta 2: Il timestamp differisce, quindi l'hash del prefisso al blocco 6 differisce. Il lookback cammina 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 una scrittura della cache da zero ad ogni richiesta e non ottieni mai una lettura.

Il lookback non trova contenuto stabile dietro il tuo breakpoint e lo memorizza. 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 lo stesso tra le richieste, e ogni richiesta successiva legge il prefisso memorizzato. Il caching automatico colpisce la stessa trappola: posiziona il breakpoint sull'ultimo blocco cacheable, che in questa struttura è quello che cambia ad ogni richiesta, quindi utilizza un breakpoint esplicito al blocco 5 invece.

Punto chiave: Posiziona cache_control sull'ultimo blocco il cui prefisso è identico tra le richieste che desideri condividere una cache. In una conversazione in crescita il blocco finale 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 utilizzare più breakpoint

Puoi definire fino a 4 breakpoint della cache se desideri:

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

Comprensione dei costi dei breakpoint della cache

I breakpoint della cache stessi non aggiungono alcun costo. Sei addebitato solo per:

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

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

Strategie di caching e considerazioni

Limitazioni della cache

La lunghezza minima del prompt cacheable è:

• 4096 token per Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6 e Claude Opus 4.5
• 2048 token per Claude Sonnet 4.6
• 1024 token per Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4 e Claude Sonnet 3.7 (deprecato)
• 4096 token per Claude Haiku 4.5
• 2048 token per Claude Haiku 3.5 (deprecato) e Claude Haiku 3

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

Se il tuo prompt è leggermente al di sotto del minimo per il modello che stai utilizzando, espandere il contenuto memorizzato per raggiungere la soglia è spesso utile. Le letture della cache costano significativamente meno dei token di input non memorizzati, quindi raggiungere il minimo può ridurre i costi per i prompt frequentemente riutilizzati.

Per le richieste simultanee, nota che una voce della 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

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

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

Ognuno di questi elementi può essere memorizzato, automaticamente o contrassegnandoli con cache_control.

Cosa non può essere memorizzato

Mentre la maggior parte dei blocchi di richiesta può essere memorizzata, ci sono alcune eccezioni:

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

• I blocchi di sub-contenuto (come citazioni) stessi non possono essere memorizzati direttamente. Invece, memorizza il blocco di livello superiore.

  Nel caso delle citazioni, i blocchi di contenuto del documento di livello superiore che servono come materiale di origine per le citazioni possono essere memorizzati. Questo ti consente di utilizzare prompt caching con citazioni in modo efficace memorizzando i documenti a cui le citazioni faranno riferimento.

• I blocchi di testo vuoti non possono essere memorizzati.

Cosa invalida la cache

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

Come descritto in Strutturazione del tuo prompt, la cache segue la gerarchia: tools → system → messages. Le modifiche a ogni 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.

Tracciamento delle prestazioni della cache

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

• cache_creation_input_tokens: Numero di token scritti nella cache quando si crea 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 da o utilizzati per creare una cache (cioè, token dopo l'ultimo breakpoint della cache).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Caching con thinking blocks

Quando si utilizza extended thinking con prompt caching, i thinking blocks hanno un comportamento speciale:

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

Conteggio dei token di input: Quando i thinking blocks vengono letti dalla cache, contano come token di input nelle tue metriche di utilizzo. Questo è importante per il calcolo dei costi e il budgeting dei token.

Modelli di invalidazione della cache:

• La cache rimane valida quando solo i risultati degli strumenti vengono forniti come messaggi dell'utente
• La cache viene invalidata quando viene aggiunto contenuto dell'utente non relativo ai risultati degli strumenti, causando la rimozione di tutti i precedenti thinking blocks
• Questo comportamento di caching si verifica anche senza marcatori cache_control espliciti

Per ulteriori dettagli sull'invalidazione della cache, vedi Cosa invalida la cache.

Esempio con uso di 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]
# Non-tool-result user block causes all thinking blocks to be ignored
# This request is processed as if thinking blocks were never present

Quando viene incluso un blocco utente non relativo ai risultati degli strumenti, designa un nuovo ciclo dell'assistente e tutti i precedenti thinking blocks vengono rimossi dal contesto.

Per informazioni più dettagliate, vedi la documentazione extended thinking.

Archiviazione e condivisione della cache

• Isolamento dell'organizzazione: Le cache sono isolate tra le organizzazioni. Diverse organizzazioni non condividono mai le cache, anche se utilizzano prompt identici.

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

• Generazione di token di output: Il prompt caching non ha alcun effetto sulla generazione di token di output. La risposta che ricevi sarà identica a quella che otterresti se il prompt caching non fosse utilizzato.

Best practice per un caching efficace

Per ottimizzare le prestazioni del prompt caching:

• Inizia con caching automatico per conversazioni multi-turno. Gestisce automaticamente la gestione dei breakpoint.
• Utilizza breakpoint espliciti a livello di blocco quando hai bisogno di memorizzare nella cache sezioni diverse con diverse frequenze di modifica.
• Memorizza nella cache contenuti stabili e riutilizzabili 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.
• Utilizza i breakpoint della cache strategicamente 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 hit della cache e regola la tua strategia secondo le necessità.

Ottimizzazione per diversi casi d'uso

Personalizza la tua strategia di prompt caching al tuo scenario:

• Agenti conversazionali: Riduci il costo e la latenza per conversazioni estese, specialmente quelle con istruzioni lunghe o documenti caricati.
• Assistenti di codifica: Migliora l'autocompletamento e le domande sulla base di codice mantenendo sezioni rilevanti o una versione riassunta della base di codice nel prompt.
• Elaborazione di documenti di grandi dimensioni: Incorpora materiale completo di lunga forma incluse immagini nel tuo prompt senza aumentare la latenza della risposta.
• Set di istruzioni dettagliati: Condividi elenchi estesi di istruzioni, procedure ed esempi per ottimizzare le risposte di Claude. Gli sviluppatori spesso includono uno o due esempi nel prompt, ma con il prompt caching puoi ottenere prestazioni ancora migliori includendo 20+ esempi diversi di risposte di alta qualità.
• Uso di strumenti agentic: Migliora le prestazioni per scenari che coinvolgono più chiamate di strumenti e modifiche di codice iterative, dove ogni passaggio in genere richiede 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(i) nel prompt e lasciando che gli utenti facciano domande.

Risoluzione dei problemi comuni

Se riscontri comportamenti inaspettati:

• Assicurati che le sezioni memorizzate nella cache siano identiche tra le chiamate. Per i breakpoint espliciti, verifica che i marcatori cache_control siano negli stessi percorsi
• Verifica che le chiamate vengano effettuate entro la durata della cache (5 minuti per impostazione predefinita)
• Verifica che tool_choice e l'utilizzo delle immagini rimangono coerenti tra le chiamate
• Convalida che stai memorizzando nella cache almeno il numero minimo di token per il modello che stai utilizzando (vedi Limitazioni della cache). Gli errori di caching basati sulla lunghezza sono silenziosi: la richiesta ha successo ma sia cache_creation_input_tokens che cache_read_input_tokens saranno 0
• Conferma che il tuo breakpoint è su un blocco che rimane identico tra le richieste. Le scritture della 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 loro stessi breakpoint
• Verifica che le chiavi nei tuoi blocchi di contenuto tool_use abbiano un ordine stabile poiché alcuni linguaggi (ad esempio, Swift, Go) randomizzano l'ordine delle chiavi durante la conversione JSON, interrompendo le cache

Durata della cache di 1 ora

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

Per utilizzare la cache estesa, includi ttl nella definizione di 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": 456,
      "ephemeral_1h_input_tokens": 100
    }
  }
}

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

Quando utilizzare la cache di 1 ora

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

La cache di 1 ora è meglio utilizzata nei seguenti scenari:

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

Miscelazione di diversi TTL

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

Quando si mescolano i TTL, l'API determina tre posizioni di fatturazione nel tuo prompt:

1. Posizione A: Il conteggio dei token al massimo hit della cache (o 0 se nessun hit).
2. Posizione B: Il conteggio dei token al massimo blocco cache_control di 1 ora dopo A (o uguale a A se nessuno esiste).
3. Posizione C: Il conteggio dei token all'ultimo blocco cache_control.

Ti verrà addebitato per:

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

Ecco 3 esempi. Questo raffigura i token di input di 3 richieste, ognuna delle quali ha diversi hit della cache e cache miss. Ognuna ha un diverso prezzo calcolato, mostrato nelle caselle colorate, di conseguenza.

Esempi di prompt caching

Per aiutarti a iniziare con il prompt caching, il cookbook sul prompt caching fornisce esempi dettagliati e best practice.

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

Conservazione dei dati

La memorizzazione nella 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 vengono mantenuti solo in memoria e non vengono archiviati a riposo. Le voci della cache hanno una durata minima di 5 minuti (standard) o 60 minuti (estesa), dopo di che vengono eliminate prontamente, anche se non immediatamente. Le voci della cache sono isolate tra le organizzazioni.

Per l'idoneità a ZDR in tutte le funzioni, vedi API e conservazione dei dati.

FAQ