Prompt Caching no GPT-6: Funcionamento, Práticas e Limitações

O que a OpenAI publicou

Em novembro de 2026, a OpenAI publicou a página Better prompt caching for GPT-6 descrevendo mudanças na forma como o cache de prompt funciona nos novos modelos da família GPT-6 (Sol e Luna, lançados no mesmo ciclo). O anúncio veio junto do corte de preços da API, com o GPT-6 Sol e GPT-6 Luna saindo pela metade do preço da geração 5.6. Para quem constrói agentes, a principal mudança não é o preço por token, mas sim o cache.

O núcleo do anúncio incluiu taxas de cache hit mais altas por padrão, com desconto de 90% nas leituras de tokens de input cacheados, além de um Prompt Caching Dashboard que mostra quanto do input está sendo cacheado ao longo do tempo e uma ferramenta de diagnóstico que explica oportunidades perdidas de cache e o que corrigir. Além disso, é possível alterar o esforço de raciocínio e a disponibilidade de ferramentas sem invalidar o cache, que era um dos principais motivos de cache miss antes.

Como o prompt caching funciona por baixo

O que o cache está guardando

Prompt caching não guarda a resposta, mas sim o estado interno já computado para um prefixo do prompt. Toda vez que você manda uma requisição, o modelo processa os tokens em ordem. Se os primeiros N tokens são idênticos a uma requisição recente, o serviço reusa o trabalho já feito para eles e só processa a parte nova.

O cache só serve enquanto o começo do pedido é literalmente o mesmo. Se você trocar uma vírgula no meio da parte estável, o prefixo deixa de bater.

Prefixo, breakpoint e a regra do 1024

Duas condições precisam ser atendidas para haver um cache hit. Primeiro, o prefixo deve ter um tamanho mínimo: o comprimento mínimo cacheável é de 1.024 tokens para GPT-5.6 e modelos posteriores. Segundo, precisa existir um breakpoint, um ponto no prompt que marca onde o prefixo reusável termina. O primeiro modo é implícito, onde o serviço escolhe o breakpoint sozinho, e o segundo é explícito, onde você marca onde ele fica.

O que invalida o cache

Reuso exige match exato de prefixo mais compatibilidade de configuração. O diagnóstico de cache compara sua requisição atual com uma resposta anterior para explicar por que um prefixo esperado não foi reusado. Antes do GPT-6, mudar o esforço de raciocínio ou ferramentas no meio de uma conversa quebrava o cache, mas agora não quebra mais.

TTL e retenção

O tempo que o prefixo sobrevive no cache é regido por TTL. Em modelos GPT-5.6 e posteriores, use prompt_cache_options.ttl para definir o tempo mínimo de vida dos breakpoints escritos pela requisição. O único valor suportado é 30 minutos, que também é o padrão.

O custo de escrever no cache

Cachear não é grátis. Para GPT-5.6 e posteriores, cache writes custam 1,25 vez a taxa padrão de input não cacheado. Um único reuso já paga o write. Reuso pesado é onde o desconto de 90% aparece de verdade.

O que isso significa na prática

A arquitetura de prompt que aproveita cache tem uma forma específica: instruções e ferramentas estáveis primeiro, contexto volátil depois. Um exemplo com breakpoint explícito, adaptado dos formatos que aparecem na documentação:

const response = await client.responses.create({
 model: "gpt-6-sol",
 prompt_cache_key: "support-agent:v4",
 prompt_cache_options: { mode: "explicit", ttl: "30m" },
 input: [
 {
 role: "developer",
 content: [
 { type: "text", text: "politica estavel e instrucoes operacionais..." },
 { type: "text", text: "", prompt_cache_breakpoint: true }
 ]
 },
 {
 role: "user",
 content: "por que minha fatura foi duplicada?"
 }
 ]
});

O prompt_cache_key ajuda o serviço a agrupar requisições que devem compartilhar cache. A pergunta do usuário fica depois do breakpoint, então varia livremente sem custo de invalidação.

Onde quebra

Pequenas mudanças que invalidam tudo

Ferramenta reordenada, schema de tool ligeiramente diferente, service tier trocado, ou uma linha de instrução adicionada no topo em vez de no fim: qualquer uma dessas coisas invalida o prefixo. O diagnóstico ajuda a identificar, mas a arquitetura deve ser desenhada para não gerar essas variações.

Modo implícito ainda tem armadilhas

No modo implícito, se o final da sua mensagem varia muito, você pode perder cache no prefixo que era estável. Modo explícito é a saída.

Escrever cache tem custo real

O 1,25x do cache write só compensa se o prefixo for reusado. Aplicação com muitas conversas únicas, prefixo enorme e pouco reuso paga cache write repetidas vezes sem colher benefício.

Depende do provedor

Se você acessa via Azure ou Bedrock, o comportamento pode variar. Cache pode simplesmente não funcionar em combinações específicas de modelo e provedor, e é comum descobrir isso apenas quando você mede.

O que não dá para afirmar ainda

• Não está claro no anúncio quanto exatamente subiu o hit rate por padrão em GPT-6 versus GPT-5.6. Os números públicos são casos de cliente, não uma média divulgada pela OpenAI.
• A OpenAI citou dados do GitHub mostrando que melhorias de caching cortaram os tokens de prompt processados em novo em mais de 50% ao longo de bilhões de requisições, mas o anúncio não separa quanto desse ganho vem especificamente dos novos modelos.
• Cache prewarming aparece mencionado em resumos de terceiros, mas os detalhes de API e disponibilidade não estão no que confirmei da documentação oficial.
• Não testei pessoalmente os novos endpoints do GPT-6. As afirmações de mecanismo aqui vêm da documentação e do anúncio, não de execução minha.

Como testar isso você mesmo

Um caminho pequeno para experimentar em uma tarde:

1. Escolha um endpoint que você já usa com prefixo grande e estável.
2. Faça duas chamadas idênticas em sequência e olhe prompt_tokens_details.cached_tokens na segunda resposta. Se vier zero, você não está batendo o mínimo de 1024 ou o prefixo não é literalmente idêntico.
3. Migre para Responses API se ainda estiver no Chat Completions, adicione prompt_cache_key estável por tipo de agente e prompt_cache_options: { mode: "explicit", ttl: "30m" }.
4. Coloque um prompt_cache_breakpoint no fim da parte estável, antes do conteúdo variável.
5. Force um miss (mude uma ferramenta, mude o modelo) e leia prompt_cache_diagnostics para ver o motivo reportado.
6. Abra o Prompt Caching Dashboard e compare hit rate antes e depois.

Se depois de tudo isso o hit rate não subir, o problema quase sempre é serialização não determinística ou variação no topo do prompt que você não estava notando. O diagnóstico existe para isso.