Cache de prompts

O cache de prompts otimiza o uso da sua API permitindo retomar a partir de prefixos específicos em seus prompts. Isso reduz significativamente o tempo de processamento e os custos para tarefas repetitivas ou prompts com elementos consistentes.

Existem duas maneiras de ativar o cache de prompts:

• Cache automático: Adicione um único campo cache_control no nível superior da sua solicitação. O sistema aplica automaticamente o ponto de interrupção do cache ao último bloco armazenável em cache e o move para frente conforme as conversas crescem. Melhor para conversas multi-turno onde o histórico de mensagens crescente deve ser armazenado em cache automaticamente.
• Pontos de interrupção de cache explícitos: Coloque cache_control diretamente em blocos de conteúdo individuais para controle fino sobre exatamente o que é armazenado em cache.

A maneira mais simples de começar é com o cache automático:

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())

Com o cache automático, o sistema armazena em cache todo o conteúdo até e incluindo o último bloco armazenável em cache. Em solicitações subsequentes com o mesmo prefixo, o conteúdo em cache é reutilizado automaticamente.

Como funciona o cache de prompts

Quando você envia uma solicitação com o cache de prompts ativado:

1. O sistema verifica se um prefixo de prompt, até um ponto de interrupção de cache especificado, já está em cache de uma consulta recente.
2. Se encontrado, ele usa a versão em cache, reduzindo o tempo de processamento e os custos.
3. Caso contrário, ele processa o prompt completo e armazena em cache o prefixo assim que a resposta começa.

Isso é especialmente útil para:

• Prompts com muitos exemplos
• Grandes quantidades de contexto ou informações de fundo
• Tarefas repetitivas com instruções consistentes
• Conversas longas multi-turno

Por padrão, o cache tem uma vida útil de 5 minutos. O cache é atualizado sem custo adicional cada vez que o conteúdo em cache é usado.

Preços

O cache de prompts introduz uma nova estrutura de preços. A tabela abaixo mostra o preço por milhão de tokens para cada modelo suportado:

Modelos suportados

O cache de prompts (automático e explícito) é suportado em todos os modelos Claude ativos.

Cache automático

O cache automático é a maneira mais simples de ativar o cache de prompts. Em vez de colocar cache_control em blocos de conteúdo individuais, adicione um único campo cache_control no nível superior do corpo da sua solicitação. O sistema aplica automaticamente o ponto de interrupção do cache ao último bloco armazenável em cache.

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())

Como o cache automático funciona em conversas multi-turno

Com o cache automático, o ponto de cache se move para frente automaticamente conforme as conversas crescem. Cada nova solicitação armazena em cache tudo até o último bloco armazenável em cache, e o conteúdo anterior é lido do cache.

O ponto de interrupção do cache se move automaticamente para o último bloco armazenável em cache em cada solicitação, portanto você não precisa atualizar nenhum marcador cache_control conforme a conversa cresce.

Suporte a TTL

Por padrão, o cache automático usa um TTL de 5 minutos. Você pode especificar um TTL de 1 hora a 2x o preço do token de entrada base:

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

Combinando com cache em nível de bloco

O cache automático é compatível com pontos de interrupção de cache explícitos. Quando usados juntos, o ponto de interrupção de cache automático usa um dos 4 slots de ponto de interrupção disponíveis.

Isso permite combinar ambas as abordagens. Por exemplo, use pontos de interrupção explícitos para armazenar em cache seu prompt de sistema e ferramentas independentemente, enquanto o cache automático lida com a conversa:

{
  "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?" }]
}

O que permanece igual

O cache automático usa a mesma infraestrutura de cache subjacente. Preços, limites mínimos de tokens, requisitos de ordenação de contexto e a janela de lookback de 20 blocos se aplicam da mesma forma que com pontos de interrupção explícitos.

Casos extremos

• Se o último bloco já tiver um cache_control explícito com o mesmo TTL, o cache automático é uma operação nula.
• Se o último bloco tiver um cache_control explícito com um TTL diferente, a API retorna um erro 400.
• Se 4 pontos de interrupção explícitos em nível de bloco já existirem, a API retorna um erro 400 (nenhum slot restante para cache automático).
• Se o último bloco não for elegível como alvo de ponto de interrupção de cache automático, o sistema silenciosamente caminha para trás para encontrar o bloco elegível mais próximo. Se nenhum for encontrado, o cache é ignorado.

Pontos de interrupção de cache explícitos

Para mais controle sobre o cache, você pode colocar cache_control diretamente em blocos de conteúdo individuais. Isso é útil quando você precisa armazenar em cache diferentes seções que mudam em frequências diferentes, ou precisa de controle fino sobre exatamente o que é armazenado em cache.

Estruturando seu prompt

Coloque conteúdo estático (definições de ferramentas, instruções do sistema, contexto, exemplos) no início do seu prompt. Marque o final do conteúdo reutilizável para cache usando o parâmetro cache_control.

Os prefixos de cache são criados na seguinte ordem: tools, system, depois messages. Essa ordem forma uma hierarquia onde cada nível se baseia nos anteriores.

Como funciona a verificação automática de prefixo

Você pode usar apenas um ponto de interrupção de cache no final do seu conteúdo estático, e o sistema encontrará automaticamente o prefixo mais longo que uma solicitação anterior já escreveu no cache. Entender como isso funciona ajuda você a otimizar sua estratégia de cache.

Três princípios principais:

1. As escritas de cache acontecem apenas no seu ponto de interrupção. Marcar um bloco com cache_control escreve exatamente uma entrada de cache: um hash do prefixo terminando naquele bloco. O sistema não escreve entradas para nenhuma posição anterior. Como o hash é cumulativo, cobrindo tudo até e incluindo o ponto de interrupção, alterar qualquer bloco no ou antes do ponto de interrupção produz um hash diferente na próxima solicitação.

2. As leituras de cache procuram para trás por entradas que solicitações anteriores escreveram. Em cada solicitação, o sistema calcula o hash do prefixo no seu ponto de interrupção e verifica uma entrada de cache correspondente. Se nenhuma existir, ele caminha para trás um bloco por vez, verificando se o hash do prefixo em cada posição anterior corresponde a algo já no cache. Está procurando por escritas anteriores, não por conteúdo estável.

3. A janela de lookback é de 20 blocos. O sistema verifica no máximo 20 posições por ponto de interrupção, contando o ponto de interrupção em si como o primeiro. Se o sistema não encontrar nenhuma entrada correspondente nessa janela, a verificação para (ou retoma do próximo ponto de interrupção explícito, se houver).

Exemplo: Lookback em uma conversa crescente

Você anexa novos blocos a cada turno e define cache_control no bloco final de cada solicitação:

• Turno 1: 10 blocos, ponto de interrupção no bloco 10. Nenhuma entrada de cache anterior existe. O sistema escreve uma entrada no bloco 10.
• Turno 2: 15 blocos, ponto de interrupção no bloco 15. O bloco 15 não tem entrada, então o sistema caminha para trás até o bloco 10 e encontra a entrada do turno 1. Acerto de cache no bloco 10; o sistema processa apenas blocos 11 a 15 novamente e escreve uma nova entrada no bloco 15.
• Turno 3: 35 blocos, ponto de interrupção no bloco 35. O sistema verifica 20 posições (blocos 35 a 16) e não encontra nada. A entrada do turno 2 no bloco 15 está uma posição fora da janela, então não há acerto de cache. Adicionar um segundo ponto de interrupção no bloco 15 inicia uma segunda janela de lookback lá, que encontra a entrada do turno 2.

Erro comum: Ponto de interrupção em conteúdo que muda a cada solicitação

Seu prompt tem um grande contexto de sistema estático (blocos 1 a 5) seguido por um bloco por solicitação contendo um timestamp e a mensagem do usuário (bloco 6). Você define cache_control no bloco 6:

• Solicitação 1: Escrita de cache no bloco 6. O hash inclui o timestamp.
• Solicitação 2: O timestamp difere, então o hash do prefixo no bloco 6 difere. O lookback caminha pelos blocos 5, 4, 3, 2 e 1, mas o sistema nunca escreveu uma entrada em nenhuma dessas posições. Nenhum acerto de cache. Você paga por uma escrita de cache nova em cada solicitação e nunca obtém uma leitura.

O lookback não encontra conteúdo estável atrás do seu ponto de interrupção e o armazena em cache. Ele encontra entradas que solicitações anteriores já escreveram, e as escritas acontecem apenas em pontos de interrupção. Mova cache_control para o bloco 5, o último bloco que permanece igual entre solicitações, e cada solicitação subsequente lê o prefixo em cache. O cache automático cai na mesma armadilha: coloca o ponto de interrupção no último bloco armazenável em cache, que nessa estrutura é aquele que muda a cada solicitação, então use um ponto de interrupção explícito no bloco 5 em vez disso.

Conclusão principal: Coloque cache_control no último bloco cujo prefixo é idêntico entre as solicitações que você deseja compartilhar um cache. Em uma conversa crescente, o bloco final funciona desde que cada turno adicione menos de 20 blocos: o conteúdo anterior nunca muda, então o lookback da próxima solicitação encontra a escrita anterior. Para um prompt com um sufixo variável (timestamps, contexto por solicitação, a mensagem recebida), coloque o ponto de interrupção no final do prefixo estático, não no bloco variável.

Quando usar múltiplos pontos de interrupção

Você pode definir até 4 pontos de interrupção de cache se quiser:

• Armazenar em cache diferentes seções que mudam em frequências diferentes (por exemplo, ferramentas raramente mudam, mas o contexto é atualizado diariamente)
• Ter mais controle sobre exatamente o que é armazenado em cache
• Garantir um acerto de cache quando uma conversa crescente move seu ponto de interrupção 20 ou mais blocos além da última escrita

Entendendo os custos do ponto de interrupção de cache

Os pontos de interrupção de cache em si não adicionam nenhum custo. Você é cobrado apenas por:

• Escritas de cache: Quando novo conteúdo é escrito no cache (25% mais que tokens de entrada base para TTL de 5 minutos)
• Leituras de cache: Quando conteúdo em cache é usado (10% do preço do token de entrada base)
• Tokens de entrada regular: Para qualquer conteúdo não armazenado em cache

Adicionar mais pontos de interrupção cache_control não aumenta seus custos - você ainda paga a mesma quantidade com base no que é realmente armazenado em cache e lido. Os pontos de interrupção simplesmente lhe dão controle sobre quais seções podem ser armazenadas em cache independentemente.

Estratégias de cache e considerações

Limitações de cache

O comprimento mínimo de prompt armazenável em cache é:

• 4096 tokens para Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6 e Claude Opus 4.5
• 2048 tokens para Claude Sonnet 4.6
• 1024 tokens para Claude Sonnet 4.5, Claude Opus 4.1, Claude Opus 4, Claude Sonnet 4 e Claude Sonnet 3.7 (descontinuado)
• 4096 tokens para Claude Haiku 4.5
• 2048 tokens para Claude Haiku 3.5 (descontinuado) e Claude Haiku 3

Prompts mais curtos não podem ser armazenados em cache, mesmo se marcados com cache_control. Qualquer solicitação para armazenar em cache menos que esse número de tokens será processada sem cache, e nenhum erro é retornado. Para verificar se um prompt foi armazenado em cache, verifique os campos de uso da resposta: se ambos cache_creation_input_tokens e cache_read_input_tokens forem 0, o prompt não foi armazenado em cache (provavelmente porque não atendeu ao requisito de comprimento mínimo).

Se seu prompt ficar um pouco abaixo do mínimo para o modelo que você está usando, expandir o conteúdo em cache para atingir o limite geralmente vale a pena. As leituras de cache custam significativamente menos que tokens de entrada não armazenados em cache, então atingir o mínimo pode reduzir custos para prompts frequentemente reutilizados.

Para solicitações simultâneas, observe que uma entrada de cache só fica disponível após o início da primeira resposta. Se você precisar de acertos de cache para solicitações paralelas, aguarde a primeira resposta antes de enviar solicitações subsequentes.

Atualmente, "ephemeral" é o único tipo de cache suportado, que por padrão tem uma vida útil de 5 minutos.

O que pode ser armazenado em cache

A maioria dos blocos na solicitação pode ser armazenada em cache. Isso inclui:

• Ferramentas: Definições de ferramentas no array tools
• Mensagens do sistema: Blocos de conteúdo no array system
• Mensagens de texto: Blocos de conteúdo no array messages.content, para turnos de usuário e assistente
• Imagens e documentos: Blocos de conteúdo no array messages.content, em turnos de usuário
• Uso de ferramentas e resultados de ferramentas: Blocos de conteúdo no array messages.content, em turnos de usuário e assistente

Cada um desses elementos pode ser armazenado em cache, automaticamente ou marcando-os com cache_control.

O que não pode ser armazenado em cache

Embora a maioria dos blocos de solicitação possa ser armazenada em cache, existem algumas exceções:

• Blocos de pensamento não podem ser armazenados em cache diretamente com cache_control. No entanto, blocos de pensamento PODEM ser armazenados em cache junto com outro conteúdo quando aparecem em turnos anteriores do assistente. Quando armazenados em cache dessa forma, eles CONTAM como tokens de entrada quando lidos do cache.

• Blocos de sub-conteúdo (como citações) em si não podem ser armazenados em cache diretamente. Em vez disso, armazene em cache o bloco de nível superior.

  No caso de citações, os blocos de conteúdo de documento de nível superior que servem como material de origem para citações podem ser armazenados em cache. Isso permite que você use cache de prompts com citações efetivamente armazenando em cache os documentos que as citações referenciarão.

• Blocos de texto vazios não podem ser armazenados em cache.

O que invalida o cache

Modificações no conteúdo em cache podem invalidar parte ou todo o cache.

Conforme descrito em Estruturando seu prompt, o cache segue a hierarquia: tools → system → messages. Alterações em cada nível invalidam esse nível e todos os níveis subsequentes.

A tabela a seguir mostra quais partes do cache são invalidadas por diferentes tipos de alterações. ✘ indica que o cache é invalidado, enquanto ✓ indica que o cache permanece válido.

Rastreando o desempenho do cache

Monitore o desempenho do cache usando esses campos de resposta da API, dentro de usage na resposta (ou evento message_start se streaming):

• cache_creation_input_tokens: Número de tokens escritos no cache ao criar uma nova entrada.
• cache_read_input_tokens: Número de tokens recuperados do cache para esta solicitação.
• input_tokens: Número de tokens de entrada que não foram lidos ou usados para criar um cache (ou seja, tokens após o último ponto de interrupção de cache).

total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens

Cache com blocos de pensamento

Ao usar pensamento estendido com cache de prompt, blocos de pensamento têm comportamento especial:

Cache automático junto com outro conteúdo: Embora blocos de pensamento não possam ser explicitamente marcados com cache_control, eles são armazenados em cache como parte do conteúdo da solicitação quando você faz chamadas de API subsequentes com resultados de ferramentas. Isso ocorre comumente durante o uso de ferramentas quando você passa blocos de pensamento de volta para continuar a conversa.

Contagem de tokens de entrada: Quando blocos de pensamento são lidos do cache, eles contam como tokens de entrada em suas métricas de uso. Isso é importante para cálculo de custo e orçamento de tokens.

Padrões de invalidação de cache:

• O cache permanece válido quando apenas resultados de ferramentas são fornecidos como mensagens do usuário
• O cache é invalidado quando conteúdo de usuário que não é resultado de ferramenta é adicionado, causando a remoção de todos os blocos de pensamento anteriores
• Este comportamento de cache ocorre mesmo sem marcadores cache_control explícitos

Para mais detalhes sobre invalidação de cache, consulte O que invalida o cache.

Exemplo com uso de ferramentas:

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 um bloco de usuário que não é resultado de ferramenta é incluído, ele designa um novo loop de assistente e todos os blocos de pensamento anteriores são removidos do contexto.

Para informações mais detalhadas, consulte a documentação de pensamento estendido.

Armazenamento e compartilhamento de cache

• Isolamento de Organização: Os caches são isolados entre organizações. Diferentes organizações nunca compartilham caches, mesmo que usem prompts idênticos.

• Correspondência Exata: Os cache hits requerem segmentos de prompt 100% idênticos, incluindo todo o texto e imagens até e incluindo o bloco marcado com controle de cache.

• Geração de Token de Saída: O cache de prompt não tem efeito na geração de token de saída. A resposta que você recebe será idêntica ao que você obteria se o cache de prompt não fosse usado.

Melhores práticas para cache eficaz

Para otimizar o desempenho do cache de prompt:

• Comece com cache automático para conversas multi-turno. Ele gerencia pontos de interrupção automaticamente.
• Use pontos de interrupção explícitos no nível de bloco quando você precisar armazenar em cache diferentes seções com diferentes frequências de mudança.
• Armazene em cache conteúdo estável e reutilizável como instruções do sistema, informações de fundo, contextos grandes ou definições de ferramentas frequentes.
• Coloque conteúdo em cache no início do prompt para melhor desempenho.
• Use pontos de interrupção de cache estrategicamente para separar diferentes seções de prefixo armazenáveis em cache.
• Coloque o ponto de interrupção no último bloco que permanece idêntico entre solicitações. Para um prompt com um prefixo estático e um sufixo variável (timestamps, contexto por solicitação, a mensagem recebida), isso é o final do prefixo, não o bloco variável.
• Analise regularmente as taxas de cache hit e ajuste sua estratégia conforme necessário.

Otimização para diferentes casos de uso

Adapte sua estratégia de cache de prompt ao seu cenário:

• Agentes conversacionais: Reduza custo e latência para conversas estendidas, especialmente aquelas com instruções longas ou documentos enviados.
• Assistentes de codificação: Melhore o autocomplete e Q&A de base de código mantendo seções relevantes ou uma versão resumida da base de código no prompt.
• Processamento de documentos grandes: Incorpore material completo de longa forma incluindo imagens em seu prompt sem aumentar a latência de resposta.
• Conjuntos de instruções detalhadas: Compartilhe listas extensas de instruções, procedimentos e exemplos para ajustar as respostas do Claude. Desenvolvedores frequentemente incluem um ou dois exemplos no prompt, mas com cache de prompt você pode obter ainda melhor desempenho incluindo 20+ exemplos diversos de respostas de alta qualidade.
• Uso de ferramentas agentic: Melhore o desempenho para cenários envolvendo múltiplas chamadas de ferramentas e mudanças de código iterativas, onde cada etapa normalmente requer uma nova chamada de API.
• Converse com livros, artigos, documentação, transcrições de podcasts e outro conteúdo de longa forma: Traga qualquer base de conhecimento à vida incorporando o(s) documento(s) inteiro(s) no prompt e deixando os usuários fazerem perguntas a ele.

Solução de problemas comuns

Se experimentar comportamento inesperado:

• Certifique-se de que as seções em cache são idênticas entre chamadas. Para pontos de interrupção explícitos, verifique se os marcadores cache_control estão nos mesmos locais
• Verifique se as chamadas são feitas dentro do tempo de vida do cache (5 minutos por padrão)
• Verifique se tool_choice e o uso de imagem permanecem consistentes entre chamadas
• Valide que você está armazenando em cache pelo menos o número mínimo de tokens para o modelo que está usando (consulte Limitações de cache). Falhas de cache baseadas em comprimento são silenciosas: a solicitação é bem-sucedida, mas tanto cache_creation_input_tokens quanto cache_read_input_tokens serão 0
• Confirme que seu ponto de interrupção está em um bloco que permanece idêntico entre solicitações. As gravações de cache acontecem apenas no ponto de interrupção, e se esse bloco mudar (timestamps, contexto por solicitação, a mensagem recebida), o hash do prefixo nunca corresponde. O lookback não encontra conteúdo estável atrás do ponto de interrupção; ele apenas encontra entradas que solicitações anteriores gravaram em seus próprios pontos de interrupção
• Verifique se as chaves em seus blocos de conteúdo tool_use têm ordenação estável, pois algumas linguagens (por exemplo, Swift, Go) randomizam a ordem das chaves durante a conversão JSON, quebrando caches

Duração de cache de 1 hora

Se você achar que 5 minutos é muito curto, Anthropic também oferece uma duração de cache de 1 hora com custo adicional.

Para usar o cache estendido, inclua ttl na definição cache_control assim:

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

A resposta incluirá informações detalhadas de cache como a seguinte:

{
  "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
    }
  }
}

Observe que o campo cache_creation_input_tokens atual é igual à soma dos valores no objeto cache_creation.

Quando usar o cache de 1 hora

Se você tiver prompts que são usados em uma cadência regular (ou seja, prompts do sistema que são usados com mais frequência do que a cada 5 minutos), continue usando o cache de 5 minutos, pois isso continuará sendo atualizado sem custo adicional.

O cache de 1 hora é melhor usado nos seguintes cenários:

• Quando você tem prompts que provavelmente são usados com menos frequência do que 5 minutos, mas mais frequentemente do que a cada hora. Por exemplo, quando um agente secundário agentic levará mais de 5 minutos, ou ao armazenar uma conversa de chat longa com um usuário e você geralmente espera que esse usuário possa não responder nos próximos 5 minutos.
• Quando a latência é importante e seus prompts de acompanhamento podem ser enviados além de 5 minutos.
• Quando você quer melhorar sua utilização de limite de taxa, já que cache hits não são deduzidos contra seu limite de taxa.

Misturando diferentes TTLs

Você pode usar controles de cache de 1 hora e 5 minutos na mesma solicitação, mas com uma restrição importante: Entradas de cache com TTL mais longo devem aparecer antes de TTLs mais curtos (ou seja, uma entrada de cache de 1 hora deve aparecer antes de qualquer entrada de cache de 5 minutos).

Ao misturar TTLs, a API determina três locais de faturamento em seu prompt:

1. Posição A: A contagem de tokens no cache hit mais alto (ou 0 se não houver hits).
2. Posição B: A contagem de tokens no bloco cache_control de 1 hora mais alto após A (ou igual a A se nenhum existir).
3. Posição C: A contagem de tokens no último bloco cache_control.

Você será cobrado por:

1. Tokens de leitura de cache para A.
2. Tokens de gravação de cache de 1 hora para (B - A).
3. Tokens de gravação de cache de 5 minutos para (C - B).

Aqui estão 3 exemplos. Isso mostra os tokens de entrada de 3 solicitações, cada uma com diferentes cache hits e cache misses. Cada um tem um preço calculado diferente, mostrado nas caixas coloridas, como resultado.

Exemplos de cache de prompt

Para ajudá-lo a começar com o cache de prompt, o cookbook de cache de prompt fornece exemplos detalhados e melhores práticas.

Os seguintes trechos de código demonstram vários padrões de cache de prompt. Estes exemplos mostram como implementar o cache em diferentes cenários, ajudando você a entender as aplicações práticas deste recurso:

Retenção de dados

O cache de prompts (automático e explícito) é elegível para ZDR. A Anthropic não armazena o texto bruto de seus prompts ou das respostas do Claude.

As representações de cache KV (chave-valor) e hashes criptográficos do conteúdo em cache são mantidos apenas na memória e não são armazenados em repouso. As entradas em cache têm um tempo de vida mínimo de 5 minutos (padrão) ou 60 minutos (estendido), após o qual são prontamente, embora não imediatamente, deletadas. As entradas de cache são isoladas entre organizações.

Para elegibilidade de ZDR em todos os recursos, consulte API and data retention.

FAQ