Um bug do Codex pode fazer o GPT-5.6 no Bedrock custar 2,5 vezes o necessário

Em 23 de julho, o Governance Gateway que mantemos entre o Codex e o Bedrock bloqueou as requisições de uma pessoa da equipe de engenharia quando o limite de gasto foi atingido. O bloqueio era esperado; chegar ao limite tão rápido, não. O que nos confundiu foi perceber que, para essa pessoa específica, o custo estava relacionado às gravações no cache de prompts; nunca havíamos visto isso ser um problema, e o fato de elas representarem 90% dos custos dessa pessoa era ainda mais desconcertante.

Os dados de cobrança deixavam duas possibilidades: ou o preço das gravações no cache do GPT-5.6 havia tornado o tráfego normal do Codex inesperadamente caro, ou o Codex enviava as requisições de uma forma que impedia a reutilização. Rastreamos o tráfego afetado desde o registro do Governance Gateway até o JSON exato enviado ao Bedrock e então reproduzimos essas requisições em condições controladas.

Gravações no cache representaram 90% dos custos de uma pessoa com GPT-5.6

Como o Governance Gateway registra o uso de tokens por requisição, conseguimos isolar o tráfego dessa pessoa. Conciliamos esses dados com o AWS Cost Explorer para OpenAI GPT-5.6 Sol (Amazon Bedrock Edition). Nos dias completos de 1 a 23 de julho de 2026, filtrados por RECORD_TYPE = Usage, os custos se dividiam assim:

Os tokens de gravação superavam os de leitura em 9,1 para 1. Incluindo a entrada sem cache, apenas 9,6% dos tokens de entrada vieram do cache. No mesmo período, o mesmo caminho do Codex registrou 9,17M tokens de entrada no GPT-5.5 sem uma cobrança separada por gravação.

Nas tarifas do Bedrock aplicáveis ao GPT-5.5, gravações no cache não tinham cobrança separada. O GPT-5.6 cobra uma gravação a 1,25× a entrada comum e uma leitura a 0,10×. Regravar um prefixo reutilizável custa, portanto, 12,5 vezes o valor de lê-lo. Esses preços explicam por que as falhas ficaram caras, mas não por que o Codex continuava falhando.

O Codex omite o breakpoint e muda a chave de cache

Um cache de prompts reutiliza um prefixo exato, portanto precisa saber onde termina o conteúdo estável. Cada requisição codex exec começa com instruções, ferramentas e contexto do ambiente; a entrada específica da tarefa vem depois. O GPT-5.6 aceita este marcador no último bloco estável:

"prompt_cache_breakpoint": {"mode": "explicit"}

O Codex não consegue construir esse campo no bloco de conteúdo. Seu tipo de requisição relevante contém apenas:

pub enum ContentItem {
    InputText { text: String },
    ...
}

Não há um mapa para campos adicionais, e as estruturas da Responses API expõem prompt_cache_key, mas não prompt_cache_options. A configuração do provedor altera a conexão, não o conteúdo aninhado em input. Além disso, o Codex gera a chave de cache a partir de um novo UUID de sessão, portanto execuções independentes apresentam o mesmo prefixo sob identidades diferentes.

O guia de migração da OpenAI para o GPT-5.6 está incluído no Codex. Ele descreve o mesmo padrão: um prefixo estável grande seguido de um sufixo que muda pode perder o cache quando o único breakpoint gerenciado fica perto da mensagem mais recente. O guia recomenda acrescentar o marcador acima.

O breakpoint e a chave estável foram necessários

Como o Governance Gateway interpreta o corpo de cada requisição antes de assiná-la para o Bedrock, pudemos reproduzir os corpos realmente enviados pelo Codex. Um teste inicial de seis requisições aplicou as duas mudanças juntas. Os acertos subiram de 0% para 98,6%, e as gravações nas requisições quentes caíram de cerca de 9.060 tokens para 123–128. Isso mostrou que a correção conjunta funcionava; faltava saber se as duas mudanças eram necessárias.

Para descobrir, variamos o breakpoint e a chave de forma independente em três requisições capturadas:

Somente a última combinação reutilizou o prefixo. Os tokens de gravação caíram 65%, e o custo do replay caiu de US$ 0,1161 para US$ 0,0471 nas tarifas publicadas do Bedrock. As requisições sem modificação custaram cerca de 2,5 vezes mais.

Esse resultado é específico do que observamos no Bedrock Mantle. A OpenAI descreve prompt_cache_key como uma dica de roteamento usada com o hash do prefixo, portanto outros backends podem se comportar de outra forma.

Ler um prefixo em cache custa 0,10×; regravá-lo custa 1,25×

Para N requisições com o mesmo prefixo, gravá-lo sempre custa 1,25 × N. Gravar uma vez e depois ler custa 1,25 + 0,10 × (N − 1).

Se o prefixo não será reutilizado, uma gravação custa 1,25 sem gerar economia posterior. O modo explícito sem breakpoints mantém essa requisição como entrada comum a 1,00.

As cotas variam entre provedores. O Bedrock exclui leituras de cache das cotas aplicáveis do Mantle, enquanto o guia da API da OpenAI diz que prompts em cache continuam contando. O GPT-5.6 não tem uma cota por conta publicada no Bedrock, e não observamos throttling; neste incidente, o efeito medido foi o custo.

O Governance Gateway insere o breakpoint e substitui a chave da sessão

Nas requisições da Responses API do GPT-5.6 vindas do Codex, o Governance Gateway lê o corpo JSON, marca o último bloco estável, substitui o UUID da sessão por uma chave com escopo definido, serializa o corpo novamente e assina a requisição para o Bedrock. Ele mantém os breakpoints do cliente e ignora blocos de conteúdo que não podem receber um marcador.

Mantemos prompt_cache_options.mode no valor padrão. Assim, o GPT-5.6 pode usar nosso marcador de inicialização e ainda gerenciar outro breakpoint perto da mensagem mais recente. O primeiro permite reutilização entre sessões; o segundo atende aos turnos posteriores de uma conversa. Forçar o modo exclusivamente explícito apenas com o marcador inicial eliminaria esse segundo benefício.

Para impedir que usuários ou prompts sem relação compartilhem uma identidade de cache, a chave deriva do principal autenticado, modelo, versão do prompt e das ferramentas, schema das ferramentas e fingerprint do prefixo. O resultado é opaco e não contém PII nem texto do prompt. A OpenAI recomenda manter o tráfego perto de 15 requisições por minuto por chave; shards determinísticos podem distribuir volumes maiores, ao custo de uma gravação fria por shard.

O Codex 0.146.0 ainda não consegue enviar o breakpoint

A versão estável Codex 0.146.0 ainda não consegue emitir o breakpoint. Tanto essa tag quanto o snapshot de main consultado mantêm uma variante InputText contendo apenas text. O problema de construção da requisição continua aberto na #35300.

O PR #33454, já incorporado, leva cache_write_tokens aos eventos de uso e à telemetria, mas não altera a requisição.

Uma correção nativa precisa de um breakpoint opcional nos tipos de conteúdo compatíveis, enviado apenas aos backends que o aceitam. Até lá, nosso Governance Gateway precisa acrescentar o campo antes do Bedrock. O tráfego direto entre Codex e Bedrock continua sem ele.

Leituras e gravações de cache fazem parte de input_tokens

Nas respostas do Bedrock Mantle, leituras e gravações de cache já estão incluídas em input_tokens; não são tokens adicionais. Nossas chamadas fria e quente mostraram:

entrada_sem_cache = input_tokens - cached_tokens - cache_write_tokens

Nas tarifas atuais do GPT-5.6 Sol na região US East:

custo = entrada_sem_cache × US$ 5,50/M
      + cache_write_tokens × US$ 6,88/M
      + cached_tokens × US$ 0,55/M
      + output_tokens × US$ 33,00/M

Use a subtração acima para os dados da resposta. No Cost Explorer e no CUR, entrada comum, gravações e leituras já aparecem em linhas separadas, portanto some essas linhas.

• Use RECORD_TYPE = Usage e dias fechados no Cost Explorer; períodos atuais são estimados.
• Interprete 30m no tipo de uso como a vida útil mínima documentada de 30 minutos, não como expiração exata. Um teste frio exige prefixo ou chave únicos.
• As métricas publicadas do AWS/BedrockMantle não expõem campo específico de cache. Persista os detalhes de leitura e gravação de cada resposta.

Gravações repetidas no cache fizeram as mesmas requisições custarem 2,5 vezes mais

Quando conseguimos ver os corpos das requisições, a causa ficou clara: o Codex repetia o mesmo conteúdo de inicialização, mas não dava ao Bedrock nem um limite estável nem uma identidade de cache estável. O Bedrock continuava gravando um prefixo que poderia ter lido.

O Governance Gateway agora fornece ambos no tráfego roteado, reduzindo o custo do replay em 59% sem sacrificar o cache dos turnos posteriores da conversa. Requisições diretas entre Codex e Bedrock não passam por essa correção, portanto o Codex ainda precisa oferecer suporte nativo ao breakpoint.

Leitura relacionada: Codex e OpenAI Agents no Amazon Bedrock, governança de Claude Code, Desktop e Codex atrás de um único Governance Gateway e Claude Code na AWS.