Prompt caching no GPT-6 Astra: como reaproveitar o contexto em vez de reenviar tudo em cada chamada

Fala aí, beleza? A OpenAI anunciou o GPT-6 Astra em 03/09/2026 como novo modelo de ponta, e junto veio a conta: US$ 10 por 1 milhão de tokens de entrada no tier Standard

Agora pensa na sua aplicação que faz centenas de chamadas parecidas por dia

Mesmo system prompt, mesmo catálogo de tools, mesmo documento de referência, mesmo schema de saída… e você paga input cheio em TODO esse pedaço repetido, chamada após chamada

É dinheiro queimado no mesmo texto 🙂

A boa notícia é que existe caminho: o prompt caching GPT-6 Astra guarda o prefixo repetido da sua requisição e cobra a leitura dele a US$ 1,00 por 1 milhão de tokens, ou seja, 0,1x da taxa de input padrão

Neste post tu vais ver o que precisa estar no lugar, como organizar o prompt, quais parâmetros controlam a fronteira do cache e como medir se a economia é real

O que você precisa antes de ativar o cache no GPT-6 Astra:

Antes de mexer no código, quatro coisas precisam existir

• Acesso ao modelo na API, com o model ID gpt-6-astra. A OpenAI confirmou que o modelo está no ar na API, e nos planos do ChatGPT o rollout é escalonado: já disponível para Pro, Enterprise e Business Premium no ChatGPT Work e no Codex, com Plus e Business podendo levar alguns dias
• Um prefixo estático de pelo menos 1.024 tokens. Esse é o tamanho mínimo de prompt pro cache funcionar em GPT-5.6 e modelos posteriores (nos modelos anteriores ao GPT-5.6 o mínimo era 2.048 tokens)
• Um prefixo que REALMENTE se repete entre chamadas, byte a byte. O cache hit exige prefixo repetido exato
• Leitura dos campos da resposta: cached_tokens e cache_write_tokens são o que transforma "achismo de economia" em número

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Sem esses quatro pontos, não tem cache hit e não tem economia

E tem um detalhe que muita gente ignora: escrita no cache é cobrada

O cache write custa US$ 12,50 por 1 milhão de tokens, equivalente a 1,25x a taxa de input não cacheado

Ou seja: você paga um pouco MAIS na primeira vez pra pagar muito menos nas seguintes

Como reaproveitar o contexto no GPT-6 Astra passo a passo:

A lógica toda é uma só: o que não muda vai pra frente, o que muda vai pro fim

Se você já mexeu com cache de HTTP, a analogia serve bem: o cache só acerta se a chave for idêntica. Aqui a chave é o começo do seu prompt

Bora ver na prática?

1. Separe o que é estático do que é variável na sua requisição. Pega sua chamada atual e marca linha por linha: isso muda a cada request ou não? Instruções, exemplos, schemas e documentos de apoio quase sempre são fixos. Pergunta do usuário, histórico da conversa e ID de sessão são variáveis

O erro comum deste passo: achar que o system prompt é 100% estático quando ele tem um timestamp, o nome do usuário ou a data de hoje interpolados no topo. Um caractere diferente no começo já quebra a correspondência exata de prefixo, e aí não sobra cache nenhum

2. Mova todo o conteúdo estático pro começo e o variável pro fim. Essa é a recomendação oficial de organização do prompt: conteúdo estático (instruções, exemplos, schemas, documentos de referência) na frente, conteúdo variável atrás. E o que exatamente é cacheável? Todo o prefixo da requisição: mensagens, imagens, áudio, definições de tools e schemas de structured output

[ PREFIXO ESTATICO  ->  vira cache ]
1. instrucoes do sistema (fixas, sem data e sem nome de usuario)
2. definicoes de tools
3. schema de structured output
4. exemplos few-shot
5. documento de referencia / politica / manual

[ SUFIXO VARIAVEL  ->  nunca cacheia ]
6. historico recente da conversa
7. pergunta do usuario

O erro comum deste passo: deixar a definição de tools DEPOIS da mensagem do usuário porque "o SDK aceita nessa ordem". Aceita, sim, mas aí seu bloco mais gordo e mais fixo fica fora do prefixo reaproveitável

3. Garanta o mínimo de 1.024 tokens no prefixo e lembre dos incrementos de 128 tokens. Abaixo de 1.024 tokens de prefixo, não há cache. E os hits ocorrem em incrementos de 128 tokens, então o pedacinho final que não fecha o incremento simplesmente não conta

O erro comum deste passo: instrução curtinha de 300 tokens e expectativa de economia. Não vai rolar. Se o seu prefixo é magro, o cache não é o seu problema a resolver hoje

4. Use prompt_cache_key pra agrupar requisições do mesmo prefixo. O parâmetro é opcional e ajuda a agrupar e rotear requisições que compartilham o mesmo prefixo para o mesmo cache

{
  "model": "gpt-6-astra",
  "prompt_cache_key": "classificador-tickets-v4"
}

Tome cuidado! O erro comum deste passo é tratar o prompt_cache_key como garantia: ele influencia roteamento, mas não fixa a máquina nem garante cache hit. Outra pegadinha é usar uma chave por usuário quando o prefixo é o MESMO pra todo mundo, espalhando o que deveria estar junto

5. Controle a fronteira do cache quando não quiser depender do modo implícito. Em GPT-5.6 e posteriores existem dois controles: prompt_cache_options.mode, que escolhe entre caching implícito ou explicit-only, e prompt_cache_breakpoint, que marca a fronteira escolhida por você

{
  "model": "gpt-6-astra",
  "prompt_cache_key": "classificador-tickets-v4",
  "prompt_cache_options": { "mode": "explicit-only" }
}

O erro comum deste passo: marcar o breakpoint depois do conteúdo variável. Se a fronteira cai depois da pergunta do usuário, aquele trecho muda a cada chamada e você acaba pagando escrita sem nunca colher leitura

6. Meça cached_tokens e cache_write_tokens e compare escrita com leitura. Registre os dois campos na resposta e compare o volume de escrita com as leituras posteriores: é assim que você enxerga o custo líquido, não a impressão de economia

cached_tokens        -> tokens do prefixo lidos do cache (0,1x do input)
cache_write_tokens   -> tokens gravados no cache (1,25x do input)

O erro comum deste passo: olhar só o cached_tokens, comemorar e ignorar que a escrita está sendo refeita toda hora (sinal claro de prefixo instável). Vale a mesma disciplina de quando você decide rodar o mesmo prompt várias vezes antes de confiar no resultado: sem repetição controlada, você está lendo ruído

Quando o cache compensa (e quando não vale a pena)?

A conta é simples e cabe numa linha: pagar 1,25x na escrita só compensa se o prefixo for reutilizado, porque cada leitura seguinte custa 0,1x da taxa de input

Ou seja, a pergunta certa não é "meu prompt é grande?", é "meu prefixo repete?"

Cenários onde repete muito, e o cache brilha:

• Agente com system prompt longo e catálogo de tools fixo. As definições de tools entram no prefixo cacheável, e num agente elas costumam ser o bloco mais pesado e mais estável de todos
• RAG com documento base repetido. Manual, política interna, contrato modelo: se o mesmo documento vai em toda chamada, ele é candidato natural a ficar no começo do prompt
• Classificador com schema e exemplos fixos. Schema de structured output mais few-shot na frente, ticket do cliente no fim. É o formato mais previsível de todos, porque só a última parte muda

E quando NÃO vale? Chamada única, prompt montado sob medida pra cada request, prefixo que nunca repete

Aí você paga a escrita a 1,25x e não colhe leitura nenhuma, o que é literalmente o pior dos mundos

Tem também o fator tempo: o prefixo cacheado fica elegível pra reuso por cerca de 30 minutos após a última escrita ou reuso, e a OpenAI pode retê-lo por mais tempo

Então volume concentrado ajuda: cem chamadas espalhadas ao longo do dia aproveitam muito menos que cem chamadas na mesma janela de trabalho

Quer o critério mais honesto? Se você não consegue apontar o bloco fixo da sua requisição em dez segundos, o passo anterior ao cache é organizar o prompt, não configurar parâmetro

Cache, contexto longo e tiers de preço: o que mais mexe na sua conta?

O cache não age sozinho na fatura. Existem outros multiplicadores no GPT-6 Astra, e eles se somam

O primeiro deles é o tamanho do prompt

O modelo tem contexto de 1.050.000 tokens e máximo de 128.000 tokens de saída, o que abre espaço pra prefixos gigantes… e é justamente aí que mora a pegadinha

Existe um limiar de cobrança: prompts com mais de 272 mil tokens de entrada são cobrados a 2x nas taxas de input E de cache, além de 1,5x no output, valendo pra requisição inteira

Repare no detalhe: o multiplicador de 2x pega também a taxa de cache, então o token lido do cache fica mais caro nessa faixa, e não só o token novo

Na prática isso significa que passar dos 272 mil tokens não é um degrauzinho, é a requisição toda mudando de faixa. Um prefixo colossal continua sendo mais barato que reenviar tudo sem cache, mas ele não escapa do multiplicador de contexto longo

Se a ideia de encher a janela te interessa, vale entender antes o que cabe na janela de contexto do GPT-6 Astra e decidir o tamanho do prefixo com números na mão

E ainda tem o tier: Batch e Flex custam 50% das taxas Standard, enquanto o modo Fast custa 2x as taxas aplicáveis

Com essa tabela na mesa, a decisão fica combinatória: tier escolhido, tamanho do prefixo e frequência de reuso

Detalhes que a documentação atual não fecha (como retenção estendida ou combinação exata do desconto de cache com outros tiers) eu prefiro não ensinar por achismo, beleza? Melhor você medir na sua conta do que seguir número inventado

Se quiser conferir a fonte e os parâmetros com calma, o guia de prompt caching da OpenAI é onde essas regras estão descritas

Vídeo: contexto grande na prática

Pra começar do zero com a ideia de reaproveitar contexto, este vídeo do canal mostra uma IA de programar grátis, sem login e com 1 milhão de contexto (MiMo Code)

Dá uma olhada pra ver janela de contexto grande funcionando na prática 😀

Conclusão

Se você guardar uma frase deste post, guarda esta: estático na frente, variável no fim, e medir

O resto é consequência. O prefixo repetido exato é o que vira cache, os 1.024 tokens são o portão de entrada, os incrementos de 128 tokens definem o que realmente conta e a leitura a 0,1x é o que paga a escrita a 1,25x

E não esquece do limiar: passou de 272 mil tokens de entrada, a requisição inteira entra na faixa de 2x em input e cache

Próximo passo prático e bem simples: monta seu prompt na ordem certa, roda duas chamadas iguais em sequência e compara cached_tokens e cache_write_tokens entre elas

Se a segunda chamada mostrar leitura de cache no lugar de escrita, você confirmou o hit e pode escalar com tranquilidade

Se não mostrar, tem alguma coisa variável escondida no topo do seu prompt… e agora tu sabes exatamente onde procurar 🙂

até o próximo post!