Prompt caching da Anthropic corta até 90% do custo de token repetido em produção

Documentação oficial da Anthropic detalha como cache hits custam apenas 10% do preço base de input, uma conta que muda a margem de quem reenvia contexto grande a cada chamada de API.

O prompt caching da Anthropic é fácil de esquecer porque parece detalhe de infraestrutura. Não é. Segundo a documentação oficial do recurso, cache hits (quando o modelo reaproveita um prefixo de prompt já processado) custam 10% do preço de input normal na maioria dos modelos, e 2,5% nos mais recentes, Claude Fable 5.1 e Claude Mythos 5.1. Para qualquer produto que manda o mesmo contexto grande (base de conhecimento, definição de ferramentas, histórico de conversa) a cada chamada, isso não é otimização de performance. É reescrita da estrutura de custo variável do produto.

A conta que muda de fato

A tabela de preços da Anthropic tem cinco colunas por modelo: input base, escrita de cache de 5 minutos, escrita de cache de 1 hora, leitura de cache (hit) e output. No Claude Sonnet 4.5, por exemplo, o input base custa US$ 3 por milhão de tokens (MTok), a escrita de cache de 5 minutos custa US$ 3,75/MTok (25% mais caro que o base) e a leitura de cache custa US$ 0,30/MTok, dez vezes mais barato.

Aplicando isso a um caso concreto: um agente de suporte com uma base de conhecimento de 15.000 tokens no system prompt, reaproveitada em dez interações de uma mesma sessão em menos de cinco minutos. Sem cache, cada chamada reprocessa os 15.000 tokens a US$ 3/MTok: dez chamadas custam US$ 0,45 só nessa fatia fixa do prompt. Com cache automático, a primeira chamada grava (US$ 3,75/MTok x 15.000 tokens = US$ 0,056) e as outras nove leem do cache (US$ 0,30/MTok x 15.000 tokens x 9 = US$ 0,04). Total: US$ 0,097, uma queda de cerca de 78% nessa parte da conta. Esse número é derivado da tabela oficial, não uma medição, mas mostra a ordem de grandeza que o mecanismo entrega quando o padrão de tráfego é favorável.

Por que a maioria dos produtos AI-native reenvia contexto do zero

O motivo pelo qual esse ganho não é automático é estrutural: aplicações que usam RAG↳RAG6 conteúdosTécnica RAG com a biblioteca Langchain: tutorial para aplicar agoraData · jun 2024Como avaliar LLMs, RAG e Agentes de IA: Teoria e prática.AI · abr 2026RAG Não É Memória: O Problema Real dos Agentes de IAAI · mai 2026Ver tudo em AI →, agentes com definição extensa de tools, ou copilotos de código que mandam o repositório inteiro como contexto tendem a montar o prompt do zero em cada chamada, porque é o jeito mais simples de programar. A documentação da Anthropic descreve dois modos de ativar o cache: automático, com um único campo cache_control no topo da requisição que a API empurra sozinho para o último bloco cacheável a cada turno, e explícito, com cache_control marcado bloco a bloco para controle fino sobre o que fica estável e o que muda.

O detalhe que separa quem economiza de quem não economiza está na ordem de montagem do prompt: a hierarquia de cache segue tools, depois system, depois messages, e qualquer mudança em um nível invalida esse nível e todos os seguintes. Isso significa que colocar conteúdo variável (um timestamp, o id da sessão, o texto do usuário) antes do conteúdo estático destrói o cache lá na frente, mesmo que o resto do prompt seja idêntico entre chamadas.

A pegadinha que a própria documentação alerta

A Anthropic descreve explicitamente esse erro comum: se o breakpoint de cache é colocado no último bloco do prompt, e esse último bloco muda a cada requisição (por exemplo, tem um timestamp embutido), o sistema nunca encontra uma escrita anterior para reaproveitar. Resultado prático: toda chamada paga o prêmio de escrita de cache (25% mais caro que o input normal na TTL de 5 minutos) e nunca chega a pagar o preço de leitura, que é a parte barata. Ou seja, uma implementação malfeita de prompt caching não é neutra, ela aumenta a fatura em relação a nunca ter usado cache.

Para quem decide arquitetura de produto, isso vira item de checklist antes de comemorar a economia projetada: o breakpoint precisa ficar no último bloco cujo prefixo é idêntico entre as chamadas que devem compartilhar cache, não no último bloco do prompt. Trocar a ordem de dois blocos no código pode ser a diferença entre cortar custo em 80% e aumentar em 25%.

Limites que travam produtos com prompt pequeno

Existe um piso de tokens para o cache funcionar: 512 tokens em Opus 5 e nos modelos Fable/Mythos, 1.024 em Sonnet 5 e Sonnet 4.5, e até 4.096 em Haiku 4.5. Abaixo disso a Anthropic simplesmente processa sem cache e sem erro, o que é perigoso porque o time de produto pode achar que está economizando quando não está: os campos cache_creation_input_tokens e cache_read_input_tokens na resposta da API voltam zerados, e é só olhando para eles que se confirma o hit.

Produtos com system prompt curto (instruções de 300 a 800 tokens, sem base de conhecimento embutida) simplesmente não se beneficiam do mecanismo como está hoje, a menos que artificialmente ampliem o contexto estático para passar do piso, o que só vale a pena se esse contexto for reutilizado muitas vezes.

TTL de 5 minutos versus 1 hora: uma escolha de tráfego, não de preço

O cache padrão dura 5 minutos e é renovado sem custo extra a cada leitura, mas o relógio conta a partir do início da requisição que grava ou lê o cache, não do fim da resposta. Para produtos com tráfego intenso e sessões contínuas, isso é suficiente. Para ferramentas B2B com uso esparso, em que o usuário demora mais de 5 minutos entre uma chamada e outra, o cache expira antes do próximo hit, e a opção é pagar TTL de 1 hora a 2x o preço base de input (US$ 6/MTok em vez de US$ 3/MTok no Sonnet 4.5, por exemplo). Isso só compensa se o volume de leituras subsequentes dentro dessa hora for alto suficiente para amortizar o dobro pago em relação ao input normal. Produto de baixo volume com TTL de 1 hora pode acabar pagando mais do que pagaria sem cache nenhum.

O contraponto: isso não é vantagem competitiva da Anthropic

O argumento mais forte contra tratar isso como diferencial estratégico é que context caching tende a ser prática comum entre provedores de LLM de escala: dado o incentivo econômico compartilhado (reduzir custo de reprocessar contexto repetido), é razoável supor que outros grandes provedores ofereçam mecanismos equivalentes de cache de contexto. Se essa leitura estiver correta, prompt caching não seria um fosso exclusivo da Anthropic, mas piso competitivo que todo provedor de LLM de escala precisa ter. O que muda de fornecedor para fornecedor é a semântica de implementação (breakpoints explícitos, janela de lookback de 20 blocos, hierarquia tools/system/messages), e é isso que gera lock-in de engenharia: uma vez que o time estrutura o prompt em torno das regras específicas de cache da Anthropic, migrar para outro provedor no meio da operação significa reescrever essa estrutura, não só trocar a chamada de API.

O que isso muda para quem decide

A implicação prática para quem constrói produto de IA no Brasil e paga por token é dupla. Primeiro, o unit economics de qualquer feature que reenvia contexto grande repetidamente (RAG com base de conhecimento estável, copiloto com repositório fixo, agente com definição extensa de tools) precisa ser recalculado assumindo cache bem estruturado, porque a diferença entre 100% e 10% do preço de input é grande demais para ignorar na precificação do produto. Segundo, e mais importante para quem já tem cache implementado: vale auditar os campos de uso da resposta da API para confirmar que há hits reais, porque a forma mais comum de errar aqui (breakpoint em conteúdo que muda a cada chamada) não gera erro, gera fatura mais alta em silêncio.

Fonte: Anthropic, documentação oficial de Prompt Caching (https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching).

Fonte: Anthropic — Documentação oficial de Prompt Caching