Cache de Prompts em Claude, GPT-5 e Gemini: Guia Prático para Cortar Custos de LLM em 2026

Atualizado: 7 de julho de 2026

O cache de prompts é um mecanismo em que o provedor do LLM armazena o estado de atenção pré-computado de um prefixo de prompt e o reutiliza em chamadas seguintes, reduzindo o custo de tokens de entrada em 75% a 90% e cortando a latência de time-to-first-token em até 85%. Em 2026, Anthropic, OpenAI e Google implementam esse recurso de formas bem diferentes: controle manual explícito, cache automático por prefixo e um modelo híbrido implícito/explícito, respectivamente. Este guia mostra como cada API funciona, quando cada uma compensa, e como estruturar prompts para maximizar acertos em produção.

• Claude (Anthropic) usa cache_control explícito com TTL de 5 min (padrão, 1.25× write) ou 1 h (2× write); leitura custa 0.1× do input padrão.
• OpenAI aplica cache automaticamente para prefixos de 1.024+ tokens; em GPT-5.5 a janela de retenção padrão passou para 24 horas em maio de 2026, com desconto de até 90% em leituras.
• Google Gemini oferece cache implícito (automático, sem custo de armazenamento) e explícito (mínimo de 32.768 tokens, TTL configurável, cobrança de storage por hora).
• O prefixo importa: coloque conteúdo estável no início (system, ferramentas, documentos) e conteúdo variável no final. Caso contrário, o cache nunca é atingido.
• O break-even do cache de 5 min do Claude ocorre na segunda requisição; o de 1 h, na terceira. Meça cached_tokens em cada resposta antes de otimizar.
• Combine três camadas (exact-match, cache semântico via GPTCache/Redis, e cache do provedor) para cobrir o espectro completo de padrões de consulta.

Como funciona o cache de prompts em LLMs?

Todo LLM baseado em Transformer processa a entrada em duas fases: prefill (calcular as ativações de atenção para cada token do prompt) e decoding (gerar tokens de saída um a um). Prefill é caro. É a fase que domina o custo de entrada e a latência inicial. O cache de prompts persiste o estado da KV (key-value) cache das camadas de atenção logo após o prefixo estável, para que a próxima requisição com o mesmo prefixo pule direto para o decoding.

Isso é diferente de cache semântico, que armazena respostas completas indexadas por embeddings de similaridade. O cache de prompts do provedor opera no nível do modelo e nunca modifica a resposta; a saída ainda é gerada normalmente, só o custo de reprocessar o prefixo é eliminado. Honestamente, depois de integrar as três APIs em projetos reais, minha regra prática ficou simples: sempre que um prefixo estável passar de 1.024 tokens e for reutilizado em minutos, o cache paga o custo de write já na segunda ou terceira chamada. Antes disso, não vale a pena e você acaba pagando mais.

Os três grandes provedores implementaram cache com filosofias distintas. A Anthropic exige controle explícito via marcadores no prompt. A OpenAI ativa automaticamente e você só descobre pelo campo cached_tokens na resposta. O Google oferece os dois modos. Cada abordagem tem consequências para arquitetura, previsibilidade de custo e observabilidade.

Cache de prompts no Claude: cache_control e TTLs

No Claude, você marca até 4 pontos de quebra em um prompt usando cache_control: { type: "ephemeral" }. Tudo desde o início do prompt (ferramentas, system, messages) até esse marcador é armazenado como um bloco cacheável. A próxima chamada que começar com exatamente os mesmos bytes lê do cache em vez de re-executar o prefill.

import anthropic

client = anthropic.Anthropic()

# Documento longo e estático (contrato, base de conhecimento, exemplos few-shot)
CONTRATO = open("contrato_master.txt").read()  # ~40k tokens

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "Você é um analista jurídico. Responda apenas com base no contrato fornecido."
        },
        {
            "type": "text",
            "text": CONTRATO,
            # Marcador: TUDO acima é armazenado por 1 hora
            "cache_control": {"type": "ephemeral", "ttl": "1h"}
        }
    ],
    messages=[
        {"role": "user", "content": "Qual é o prazo de rescisão da cláusula 12?"}
    ]
)

# Métricas de cache aparecem em response.usage
print(response.usage.cache_creation_input_tokens)  # write, só na 1ª chamada
print(response.usage.cache_read_input_tokens)      # read, 0.1× do custo

Preços e TTLs em 2026

De acordo com a documentação oficial de prompt caching do Claude, leituras de cache custam 0.1× do input padrão. Writes de 5 min custam 1.25× e writes de 1 h custam 2×. Para o Claude Sonnet 4.6: leitura a US$ 0,30/1M tokens (vs. US$ 3,00 base), write de 5 min a US$ 3,75/1M, write de 1 h a US$ 6,00/1M. O break-even do cache de 5 min ocorre na segunda leitura; o de 1 h, na terceira.

Um detalhe crítico: o relógio do cache reseta a cada leitura. Uma conversa ativa mantém o cache quente indefinidamente sem pagar write novamente. Isso muda drasticamente a matemática para sessões de chat longas, agentes iterativos e loops de tool use. Se você está construindo agentes com chamadas de ferramenta em cadeia (assunto que cobri no guia de function calling e tool use em agentes de IA), a definição das ferramentas é candidata perfeita para o primeiro cache_control.

Cache automático no OpenAI GPT-5

A OpenAI adotou a estratégia oposta: o cache é totalmente automático e você não configura nada. Qualquer prefixo de 1.024 tokens ou mais que apareça repetidamente em requisições recentes é armazenado. O sistema procura o maior prefixo já visto e desconta apenas essa porção. Se o primeiro caractere diferir, é cache miss e o campo cached_tokens retorna zero.

from openai import OpenAI

client = OpenAI()

# Prompt com prefixo grande e estável primeiro (ordem importa!)
system_prompt = f"""Você é um assistente técnico especialista em Kubernetes.
Base de conhecimento:
{documentacao_kubernetes}  # ~15k tokens estáticos
Diretrizes de resposta:
- Sempre cite comandos kubectl específicos
- Retorne exemplos em YAML quando aplicável
"""

resp = client.chat.completions.create(
    model="gpt-5.5",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": "Como fazer rolling update em um Deployment?"}
    ]
)

# cached_tokens = 0 na primeira chamada, ~15000 nas seguintes
print(resp.usage.prompt_tokens_details.cached_tokens)

Janela de retenção estendida para 24 horas

Em maio de 2026, a OpenAI aumentou a janela padrão de retenção de cache para 24 horas em GPT-5.5 e modelos posteriores da série GPT-5 (para organizações sem Zero Data Retention ativado). Isso muda o cálculo de forma significativa. Cargas noturnas, batch jobs recorrentes e agendamentos periódicos passam a se beneficiar sem esforço adicional. Antes, você precisava rodar as chamadas em blocos apertados dentro de poucos minutos. Detalhes na página oficial de prompt caching da OpenAI.

Tokens em cache custam 10% do preço normal de input no GPT-5.5 (US$ 0,50/1M vs. US$ 5,00/1M base), o famoso "desconto de 90%" mencionado com frequência. Modelos mais antigos como GPT-5.4 têm desconto de 75%. Não há custo de write extra e não há storage fee, o que torna o cache da OpenAI mais barato de operar em média, mas menos previsível, porque você não controla quando ele expira.

Cache de contexto no Google Gemini: implícito vs explícito

O Gemini oferece dois modos, e escolher entre eles é a decisão arquitetural mais importante. O cache implícito é automático a partir do Gemini 2.5, tem mínimo de 1.024 tokens no Flash e 2.048 no Pro, aplica o desconto de 90% quando há hit, e não cobra armazenamento. É a escolha padrão para apps com tráfego imprevisível.

O cache explícito exige mínimo de 32.768 tokens, garante o desconto (nada de "usually results in cost savings"), permite configurar TTL além dos 60 minutos padrão, mas cobra armazenamento por hora enquanto o cache estiver vivo. Vale para workloads de alto volume onde você precisa de previsibilidade de custo.

from google import genai
from google.genai import types

client = genai.Client()

# Cache explícito de um manual grande
cache = client.caches.create(
    model="gemini-2.5-pro",
    config=types.CreateCachedContentConfig(
        display_name="manual_produto_v3",
        system_instruction="Responda apenas com base no manual em anexo.",
        contents=[MANUAL_COMPLETO],  # deve ter 32k+ tokens
        ttl="3600s",  # 1 hora; ajustável
    )
)

# Referenciar o cache em requisições subsequentes
response = client.models.generate_content(
    model="gemini-2.5-pro",
    contents="Qual o procedimento de instalação?",
    config=types.GenerateContentConfig(cached_content=cache.name)
)

print(response.usage_metadata.cached_content_token_count)

A documentação oficial de caching da Gemini API detalha os endpoints de gerenciamento (list, update TTL, delete). Do meu ponto de vista de integração: use implícito no protótipo e migre para explícito quando o custo de storage por hora ficar menor que a economia garantida em token reads. Não é uma decisão que precisa ser tomada no primeiro dia.

Comparação lado a lado dos três provedores

Característica	Anthropic Claude	OpenAI GPT-5	Google Gemini
Ativação	Explícita (cache_control)	Automática	Implícita e explícita
Mínimo de tokens	1.024 (Sonnet/Opus), 2.048 (Haiku)	1.024	1.024 (Flash) / 2.048 (Pro implícito) / 32.768 (explícito)
TTL padrão	5 minutos (extensível a 1 h)	24 horas (GPT-5.5+, sem ZDR)	60 minutos (explícito, ajustável)
Desconto na leitura	90% (0.1× input)	75 a 90% conforme modelo	90% em 2.5+, 75% em 2.0
Custo de write	+25% (5 min) ou +100% (1 h)	Zero	Zero (implícito) / storage/hora (explícito)
Reset de TTL na leitura	Sim	Sim	Não (TTL fixo)
Isolamento	Por workspace (fev/2026)	Por organização	Por projeto
Observabilidade	cache_creation_input_tokens, cache_read_input_tokens	cached_tokens	cachedContentTokenCount

Se o seu caso pesa mais em previsibilidade de custo e você quer desativar o cache em condições específicas, vá de Anthropic ou Gemini explícito. Se quer economia sem pensar e roda a mesma consulta muitas vezes por dia, OpenAI ou Gemini implícito. Aplicativos que orquestram vários modelos ao mesmo tempo (algo comum em pipelines RAG, como descrevi no guia de pipelines RAG em produção) precisam abstrair o cache por trás de uma camada de gateway.

Como estruturar prompts para maximizar acertos de cache

Todo cache de prompts é prefix-based: ele armazena um prefixo exato do prompt e reutiliza sempre que a próxima chamada começa com os mesmos bytes. A implicação prática é que a ordem dos blocos importa muito mais do que a maioria dos desenvolvedores percebe.

Regra fundamental: estável antes, variável depois

Ordene o conteúdo do prompt em camadas, do mais estático ao mais volátil:

1. Definições de ferramentas / tool schemas: mudam raramente.
2. System prompt: persona, regras, formato de saída.
3. Documentos de contexto: bases de conhecimento, exemplos few-shot.
4. Histórico de conversação: cresce, mas de forma monotônica.
5. Pergunta atual do usuário: sempre no final.

Um erro clássico é injetar timestamps, IDs de sessão ou variáveis dinâmicas no início do system prompt. Isso invalida todo o prefixo em cada requisição e derruba a taxa de hit para zero. Já vi essa armadilha derrubar a taxa de acerto de 82% para 3% em um único deploy. Se você precisa de metadados dinâmicos, mova-os para o final do prompt ou passe-os pela mensagem do usuário.

Ferramentas em cache

No Claude, o bloco de tools é a primeira coisa cacheável, antes até do system prompt. Colocar um cache_control na última ferramenta congela toda a lista, o que é ideal para agentes com dezenas de tools cujos schemas raramente mudam. Isso é especialmente potente para agentes MCP; abordei o padrão em detalhes no guia de servidores MCP em Python.

Cache semântico: GPTCache, Redis Vector e Qdrant

O cache do provedor cobre consultas idênticas com prefixo estável. Ele não ajuda quando o usuário pergunta "quanto custa o plano premium?" agora, e outro pergunta "qual é o preço do premium?" 30 segundos depois. Isso é o território do cache semântico: uma camada de aplicação que armazena pares (embedding, resposta) e retorna a resposta armazenada quando a similaridade de coseno passa de um limiar. Um hit elimina a chamada ao LLM completamente, com zero custo de token e latência sub-milissegundo.

from gptcache import cache
from gptcache.adapter import openai
from gptcache.embedding import Onnx
from gptcache.manager import CacheBase, VectorBase, get_data_manager
from gptcache.similarity_evaluation.distance import SearchDistanceEvaluation

# Setup: SQLite para metadados, FAISS para embeddings
encoder = Onnx()
data_manager = get_data_manager(
    CacheBase("sqlite"),
    VectorBase("faiss", dimension=encoder.dimension)
)
cache.init(
    embedding_func=encoder.to_embeddings,
    data_manager=data_manager,
    similarity_evaluation=SearchDistanceEvaluation(),
)
cache.set_openai_key()

# Uso: idêntico à API OpenAI, cache transparente
response = openai.ChatCompletion.create(
    model="gpt-5.5",
    messages=[{"role": "user", "content": "Como configurar HTTPS no nginx?"}]
)

Escolhendo o modelo de embedding

O modelo de embedding determina a qualidade do cache mais do que qualquer outra escolha. Um modelo ruim mapeia consultas semanticamente distintas para vetores próximos, causando falsos hits: sua API retorna a resposta errada com convicção. BGE-M3 em 512 dimensões é o ponto de partida certo para a maioria dos casos. Antes de subir para produção, avalie a taxa de falsos hits em um conjunto de teste, o mesmo tipo de rigor que aplico em qualquer pipeline de LLM e que discuti no guia de avaliação de LLMs com DeepEval e Ragas.

Empilhando as três camadas

O padrão de produção mais confiável empilha três camadas de cache: exact-match (hash da requisição), semântico (similaridade vetorial), e provider prompt cache (KV cache do fornecedor). Cada camada apanha um perfil de tráfego diferente. Redis cobre naturalmente todas as três porque suporta strings, vetores e TTLs no mesmo servidor.

Como medir acertos de cache e monitorar economia

Um cache que você não mede é um cache que não existe. Todo provedor expõe métricas na resposta. Leia-as em toda chamada em desenvolvimento e amostre em produção:

• Claude: response.usage.cache_read_input_tokens e cache_creation_input_tokens.
• OpenAI: response.usage.prompt_tokens_details.cached_tokens.
• Gemini: response.usage_metadata.cached_content_token_count.

Calcule a taxa de hit, ou seja, (tokens lidos do cache) dividido por (total de tokens de input), por rota, por modelo e por hora. Meta razoável em produção para pipelines com prefixos estáveis: 70 a 85%. Abaixo disso, algo está invalidando o prefixo. Envie essas métricas para seu sistema de observabilidade (Datadog, Grafana, Langfuse) junto com o custo por chamada.

Quando NÃO usar cache de prompts

Nem todo caso de uso ganha com cache. Pule cache de prompts quando:

• Prefixos mudam a cada chamada: timestamps, sessão, contexto altamente personalizado por usuário. O write nunca é amortizado.
• Volume baixo (menos de 2 a 3 chamadas por janela de TTL): no Claude, você paga o custo extra do write e nunca lê do cache.
• Conteúdo abaixo do mínimo do provedor: 1.024 tokens em Claude/OpenAI/Gemini Flash; 2.048 em Gemini Pro implícito; 32.768 em Gemini explícito.
• Prompts que devem gerar respostas frescas: geração criativa, respostas dependentes de estado externo em tempo real.
• Regulações de privacidade estritas: mesmo com Zero Data Retention, valide com o time de segurança se o modelo de isolamento (workspace, org, projeto) atende ao seu marco regulatório.

Uma armadilha comum em cache semântico é personalização vazando: dois usuários fazem perguntas semanticamente parecidas mas com contextos diferentes ("meu saldo é X" vs. "meu saldo é Y"), e o cache retorna a resposta errada. Já vi esse tipo de bug passar por code review, então: sempre escope chaves de cache semântico por user_id ou tenant.

Perguntas frequentes

Qual é o tamanho mínimo de prompt para o cache funcionar?

Depende do provedor. OpenAI e Claude ativam a partir de 1.024 tokens (2.048 no Claude Haiku). Gemini implícito: 1.024 no Flash, 2.048 no Pro. Gemini explícito exige 32.768 tokens no mínimo. Abaixo desses limiares, a chamada é cobrada como input normal, sem desconto.

Qual a diferença entre cache de prompts e cache semântico?

Cache de prompts é fornecido pelo próprio provedor do LLM e opera por correspondência de bytes do prefixo. Ele reduz o custo de reprocessar entrada, mas o LLM ainda gera a resposta. Cache semântico opera na aplicação, indexa perguntas por embeddings e retorna respostas armazenadas para consultas similares, eliminando a chamada ao LLM completamente. Em produção, os dois se complementam.

O cache do OpenAI realmente dura 24 horas?

Sim, desde 29 de maio de 2026, o padrão para GPT-5.5 e modelos posteriores da série GPT-5 é 24 horas de retenção, para organizações sem Zero Data Retention ativado. Antes, a janela era de poucos minutos. Verifique cached_tokens na resposta para confirmar que o hit está ocorrendo.

Preciso mudar meu código para usar prompt caching?

No OpenAI, não: o cache é totalmente automático. No Gemini implícito, também não. No Claude e no Gemini explícito, sim: você adiciona marcadores (cache_control) ou cria caches via API e referencia o ID. Em todos os casos, revisar a ordem dos blocos (estável antes, variável depois) é essencial para maximizar hits.

Cache de prompts é seguro para dados sensíveis?

Anthropic e OpenAI declaram que os caches são elegíveis a Zero Data Retention e representações de KV cache ficam em memória, não em disco. Ainda assim, o isolamento varia: Claude passou a ser por workspace em fev/2026, OpenAI é por organização, Gemini é por projeto. Para dados regulados (PHI, PCI), valide o modelo de isolamento com o time de compliance antes de ativar.

Como sei se meu cache está sendo realmente utilizado?

Cada resposta traz uma métrica: cache_read_input_tokens no Claude, cached_tokens no OpenAI, cachedContentTokenCount no Gemini. Se esses valores forem zero em requisições que deveriam bater no cache, algo no prefixo mudou. Normalmente, uma variável dinâmica injetada acima do bloco cacheável. Amostre em produção e alerte quando a taxa de hit cair abaixo do esperado.