Cache de prompt do GPT-6: 90% de desconto em leituras em cache e como realmente acertar o cache

Cada loop de agente que você executa reenvia a mesma abertura. O system prompt, as definições de ferramentas, a especificação OpenAPI, as convenções do repositório. O modelo já viu esse prefixo cem vezes hoje, e você pagou o preço total de entrada por ele todas as vezes.

Experimente o Apidog hoje

Em escala, essa conta fica barulhenta. A OpenAI afirma que seu próprio pesquisador mediano gasta mais de US$ 600 por dia com agentes de código, e o percentil 90 gasta US$ 7.000 por dia. Essas são pessoas executando as ferramentas internas de um laboratório, não uma API em produção atendendo clientes.

Junto com o GPT-6 Sol e o GPT-6 Luna, em 22 de setembro de 2026, a OpenAI lançou uma versão de prompt caching que ataca exatamente isso. As leituras de entrada em cache têm 90% de desconto, as taxas de acerto são maiores por padrão, duas das mudanças que mais quebravam o cache não o quebram mais, você pode colocar breakpoints explícitos, e agora existe um Prompt Caching Dashboard mais uma ferramenta de diagnóstico para ver o que está realmente acontecendo. O GitHub, rodando isso em produção, relata mais de 50% menos tokens de prompt precisando de processamento novo em bilhões de requisições.

Este guia cobre o que mudou, quanto vale o desconto em dinheiro real, como dispor um prompt para que o cache realmente acerte, e como testar que ele continua acertando depois que alguém refatorar seu system prompt.

O que foi lançado

Mudança	O que significa para o seu código
90% de desconto nas leituras de entrada em cache	O prefixo repetido é cobrado a um décimo da taxa de entrada
Taxas de acerto maiores por padrão	Integrações existentes ganham parte disso sem mudança de código
Mudar o esforço de raciocínio não quebra mais o cache	Você pode escalar de low para max no meio da sessão e manter o prefixo aquecido
Mudar a disponibilidade de ferramentas não quebra mais o cache	Adicione ou remova uma ferramenta sem pagar por um prefixo frio
Breakpoints explícitos	Você decide onde o prefixo em cache termina em vez de adivinhar
Prompt Caching Dashboard e uma ferramenta de diagnóstico	A taxa de acerto se torna algo que você mede, não algo que você presume

As três primeiras importam mais para agentes. A última importa mais para o engenheiro que tem que explicar a fatura do mês passado.

A aritmética

O prompt caching só toca nos tokens de entrada. O preço de saída não muda, então um agente que escreve respostas longas a partir de um prompt curto quase não vai notar. Um agente que lê um contexto grande e estável e emite um veredito curto vai notar muito.

Veja o que o desconto faz com as tarifas publicadas para os dois novos modelos:

Modelo	Entrada por 1M	Leitura em cache por 1M	Saída por 1M	Contexto
GPT-6 Sol (gpt-6-sol)	$2.00	$0.20	$10.00	872k
GPT-6 Luna (gpt-6-luna)	$0.10	$0.01	$0.50	1M

A coluna de leitura em cache é o desconto de 90% aplicado à tarifa de entrada publicada. Confirme na página de preços ao vivo antes de montar um orçamento com base nisso.

Agora um cenário concreto. Digamos que você execute um agente de revisão de código: 40.000 tokens de prefixo estável (system prompt, esquemas de ferramentas, o documento OpenAPI do serviço, suas convenções de API) mais cerca de 2.000 tokens de diff por execução, 500 execuções por dia.

	Sol, sem acertos de cache	Sol, prefixo em cache	Luna, sem acertos de cache	Luna, prefixo em cache
Tokens de prefixo por dia	20M a $2.00 = $40.00	20M a $0.20 = $4.00	20M a $0.10 = $2.00	20M a $0.01 = $0.20
Tokens novos por dia	1M a $2.00 = $2.00	1M a $2.00 = $2.00	1M a $0.10 = $0.10	1M a $0.10 = $0.10
Custo diário de entrada	$42.00	$6.00	$2.10	$0.30

Isso é aproximadamente 86% de desconto na conta de entrada no Sol para uma carga de trabalho cuja forma não mudou em nada. A única coisa que mudou foi se o prefixo permaneceu idêntico byte a byte entre as chamadas.

Vale colocar ao lado disso: o Claude Opus 5.5 lista leituras em cache a $0.20 por milhão contra $4.00 de entrada, com escritas de cache a $5.00 por milhão. O preço de leitura fica no mesmo patamar do Sol, e a Anthropic cobra um prêmio explícito para escrever o cache. O lançamento da OpenAI não declara uma tarifa de escrita de cache para Sol ou Luna, o que é uma das questões em aberto no fim deste texto. Se você está comparando contas inteiras em vez de números isolados, nosso resumo da guerra de preços de modelos de setembro de 2026 coloca todos os três lançamentos em uma tabela.

Por que os erros de cache geralmente eram culpa sua

O prompt caching faz correspondência por prefixo. O cache é indexado pela sequência inicial de tokens na sua requisição, então o primeiro byte que difere da chamada anterior invalida tudo depois dele. Um caractere no lugar errado custa a você todo o desconto de 40.000 tokens. Os infratores clássicos, em ordem aproximada de frequência com que aparecem em código real:

• Um timestamp, request ID ou trace ID injetado no system prompt.
• O nome do usuário, ID da organização ou locale colocado acima das instruções estáticas em vez de abaixo delas.
• Contexto recuperado inserido antes das definições de ferramentas, de modo que cada nova recuperação desloca todo o prefixo.
• Um array de ferramentas construído a partir de um set ou dicionário, de modo que a ordem das chaves JSON embaralha entre processos.
• Exemplos de few-shot rotacionados por requisição para variar.

Mais dois costumavam estar nessa lista e agora saíram dela. Mudar o esforço de raciocínio não quebra mais o cache, então um agente que roda em low nos turnos fáceis e escala para max no difícil mantém seu prefixo aquecido durante a escalada. Mudar a disponibilidade de ferramentas também não a quebra mais, então condicionar uma ferramenta perigosa a uma verificação de permissão não força mais uma leitura fria de tudo acima dela. Esses dois padrões são extremamente comuns em frameworks de agentes e, até agora, zeravam silenciosamente o cache exatamente nos turnos que mais custavam.

Disponha o prompt com o estável primeiro, o volátil por último

A disciplina sobrevive a toda mudança futura de preço: ordene seu contexto por frequência de mudança, o mais estável no topo.

1. Instruções de sistema ou de desenvolvedor que são idênticas para todo usuário.
2. Esquemas de ferramentas e funções, serializados em uma ordem fixa.
3. Material de referência compartilhado e longo: o documento OpenAPI, o guia de estilo, o esquema do banco de dados.
4. Contexto por inquilino ou por projeto que muda raramente.
5. Trechos recuperados, que mudam a cada consulta.
6. O turno do usuário e qualquer coisa com um relógio nele.

As camadas um a três são o seu cache. Se um timestamp tiver que estar no prompt, coloque-o no turno do usuário, não na mensagem de sistema. Se sua lista de ferramentas é montada dinamicamente, ordene-a e congele a ordem das chaves JSON para que dois processos a serializem de forma idêntica.

from openai import OpenAI

client = OpenAI()

STATIC_PREFIX = [
    {"role": "developer", "content": SYSTEM_INSTRUCTIONS},   # never changes
    {"role": "developer", "content": OPENAPI_DOCUMENT},      # changes on deploy
]

response = client.responses.create(
    model="gpt-6-sol",
    reasoning={"effort": "low"},
    tools=SORTED_TOOL_SCHEMAS,
    prompt_cache_key="review-agent:v7",
    input=STATIC_PREFIX + [
        {"role": "user", "content": f"Review this diff:\n{diff}"},  # volatile, last
    ],
)

print(response.usage)

Os breakpoints explícitos nesta versão permitem que você marque onde esse prefixo em cache termina em vez de depender da plataforma para inferi-lo. Isso é mais útil quando a camada quatro é grande: um bloco por inquilino que é estável para um cliente e diferente para o próximo, onde você quer a fronteira traçada deliberadamente em vez de no token que a heurística escolheu.

Versione a própria chave de cache, como em review-agent:v7 acima. Quando você mudar o prefixo de propósito, incremente a versão, e você verá o período frio nas suas métricas em vez de se perguntar por que os custos dispararam.

Verifique, não presuma

O objeto usage em cada resposta informa quantos tokens de entrada foram servidos do cache. Leia-o, registre-o e crie alertas sobre ele. Um formato aproximado:

usage = response.usage
cached = usage.input_tokens_details.cached_tokens
total_in = usage.input_tokens

print(f"cache hit rate: {cached / total_in:.0%}  billed fresh: {total_in - cached}")

Os nomes de campos nos trechos acima vêm dos formatos atuais da API da OpenAI, e não do anúncio de lançamento, então confira-os na referência antes de publicar. O princípio não muda: a resposta diz a verdade, então coloque esse número em um dashboard.

O novo Prompt Caching Dashboard e a ferramenta de diagnóstico cobrem a visão em nível de frota, que é onde você vai identificar o padrão que o GitHub relata: mais de 50% dos tokens de prompt não precisando mais de processamento novo em bilhões de requisições. Essa é uma medição de toda a plataforma, e a única forma de saber o seu próprio número é medi-lo.

O modo de falha é silencioso. Nada dá erro quando o cache deixa de acertar. Um colega de equipe adiciona um request ID ao system prompt para depuração, o prefixo esfria, e o único sinal é uma linha lenta na fatura três semanas depois.

Isso faz disso um teste de regressão, não um problema de monitoramento. Trate o endpoint do modelo como qualquer outra API da qual você depende: salve a requisição no Apidog, assegure que usage.input_tokens_details.cached_tokens exceda um piso na segunda chamada de um cenário, e execute em um agendamento no CI. Duas chamadas em sequência, uma para aquecer e uma para verificar, é o teste inteiro, e uma refatoração de prompt que mata o cache passa a falhar no pull request em vez de na conta.

A nota de rodapé sobre latência

O cache reduz o trabalho feito antes do primeiro token, então geralmente ajuda tanto o tempo até o primeiro token quanto o custo. Não espere que ele salve os modos de raciocínio.

A Artificial Analysis, uma terceira parte, mede o tempo até o primeiro token em 102,15 segundos para o GPT-6 Sol e 124,23 segundos para o GPT-6 Luna em suas variantes de raciocínio "max". Esses não são os números que você verá com esforço low, e não são números do fornecedor, então trate-os como indicativos. O ponto se mantém de qualquer forma: nenhum desconto de cache transforma um orçamento de raciocínio de dois minutos em um interativo. Meça a latência por nível de esforço antes de prometer um tempo de resposta. Nosso guia da API do GPT-6 Astra cobre os níveis de esforço em mais detalhes.

O que o lançamento não responde

Vale confirmar quatro coisas antes de comprometer um design com isso:

• Se as escritas de cache têm custo no Sol e no Luna, e a que tarifa.
• Quanto tempo um prefixo em cache vive sem tráfego, e se os controles de retenção da era do GPT-5.6 continuam valendo sem alterações.
• Se a tarifa de leitura em cache do GPT-6 Astra passou para o mesmo desconto de 90%, já que o material de lançamento cobre os novos modelos.
• O nome exato do parâmetro para breakpoints explícitos, que o anúncio descreve por capacidade em vez de por campo.

Nenhuma delas bloqueia o trabalho de disposição. Ordenação com o estável primeiro, uma chave de cache versionada e uma verificação sobre tokens em cache compensam sob qualquer uma das respostas.

A versão curta

Ordene seu prompt por volatilidade e mantenha o relógio fora da mensagem de sistema. Versione a chave de cache para que mudanças deliberadas sejam visíveis. Leia cached_tokens em cada resposta e coloque um piso sob ele no CI. Escale o esforço de raciocínio e alterne ferramentas livremente agora, porque nenhum dos dois custa mais o prefixo. Para contexto sobre o mecanismo em si, nosso explicativo sobre como o prompt caching funciona cobre os fundamentos.

Os preços desses modelos vão mudar de novo. Sempre mudam. A disciplina de disposição do prompt é a parte que continua compensando depois que o próximo lançamento redefine cada número da tabela.