Codex no Bedrock da AWS gera gasto extra por não usar cache explícito de prompt

Uma issue aberta no repositório oficial do Codex (openai/codex, #37674) documenta um problema que atinge diretamente quem usa o Codex CLI conectado ao Amazon Bedrock: o provider nativo amazon-bedrock não consegue ativar o cache explícito de prompt do modelo GPT-5.6 Sol. O resultado, segundo o relato, é um volume grande de tokens de cache-write e um custo materialmente mais alto em cargas de trabalho de coding agêntico.

O que a issue relata

O autor (apexethdev) rodou o Codex CLI na versão 0.147.0, com o provider native amazon-bedrock, no endpoint Bedrock Mantle Responses API em us-east-1, usando o modelo openai.gpt-5.6-sol. A partir dos dados do Cost Explorer, ele montou uma estimativa de custo com consciência de cache para os dias 05 a 08 de agosto de 2026:

• 3.656 requests
• 171,94 milhões de cache-write tokens
• US$ 1.182,09 de custo estimado só em cache-write
• US$ 1.386,46 de custo total estimado

Ou seja, as escritas de cache representaram cerca de 85% do gasto estimado do modelo. Em uma sessão local isolada, ele observou 76 requests do Sol com 6,709 milhões de cache_write_input_tokens, zero cached_input_tokens e uma média de cerca de 88 mil tokens de cache-write por request. Não houve erros de cliente nas métricas do CloudWatch correspondentes.

O próprio autor deixa claro na issue que esses são valores derivados de uso, não faturas finalizadas da AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps →, e que nem toda escrita de cache é um defeito: cold starts, prompts genuinamente distintos, forks e compactação de contexto podem exigir writes legítimos.

Por que isso acontece na prática

O ponto técnico central é que o Codex já emite um prompt_cache_key com escopo de sessão, mas os tipos de request tanto para HTTP quanto para WebSocket na Responses API não incluem dois campos importantes:

• prompt_cache_options
• prompt_cache_breakpoint

Sem esses campos, não há como sinalizar ao Bedrock que um prefixo estável do prompt (instruções longas e definições de ferramentas que se repetem entre turnos) deveria ser reaproveitado do cache em vez de reescrito a cada chamada. Como a configuração do provider nativo do Bedrock expõe apenas ajustes de transporte e autenticação, e não transformação estruturada do corpo da requisição, não dá para contornar isso via config.toml.

A AWS documenta o modo de cache explícito do GPT-5.6 no Bedrock justamente para fluxos agênticos: instruções e definições de ferramentas longas e estáveis, seguidas de conteúdo variável de ferramenta e usuário. É exatamente o padrão descrito no relato, o que faz o cache-write repetido virar um custo evitável.

A issue se relaciona à #35300, mas adiciona evidência independente de uso em produção pelo provider nativo do Bedrock.

O que foi pedido

O relato não é só uma reclamação: ele traz um pedido de comportamento estruturado. Entre os itens solicitados:

• Suporte à serialização de prompt_cache_options para providers Responses compatíveis com GPT-5.6.
• Um campo tipado prompt_cache_breakpoint nos blocos de conteúdo de entrada suportados.
• Um mecanismo de capability gate por provider/modelo e uma estratégia de colocação segura do breakpoint no fim do prefixo estável de instruções/ferramentas medido pelo Codex.
• Exposição de leituras e escritas de cache na telemetria de uso por turno, para o usuário conseguir diagnosticar reescritas caras de prefixo completo.

A issue foi atribuída a celia-oai e marcada como enhancement, além de receber os rótulos CLI, aws-bedrock e rate-limits. No momento da captura da fonte, ela aparece como fechada.

O que muda para quem desenvolve no Brasil

O uso de agentes de coding conectados ao Bedrock tem crescido entre times brasileiros que preferem manter dados e billing dentro da própria conta AWS, muitas vezes por questões de compliance, contrato empresarial ou faturamento consolidado em nuvem. Para esse público, o alerta é direto: se você roda o Codex CLI com o provider nativo amazon-bedrock e GPT-5.6 Sol, vale conferir no Cost Explorer e no CloudWatch quanto do seu gasto está vindo de cache_write_input_tokens em vez de leituras de cache.

Um indicador prático do problema é ver cached_input_tokens zerado enquanto o cache-write acumula dezenas de milhares de tokens por request, o cenário exato descrito na issue. Como o custo é cobrado em dólar e depois convertido, o efeito sobre o orçamento de um time brasileiro tende a ser ainda mais sensível, especialmente em workloads longos e repetitivos de automação de código.

O que ainda fica em aberto: como e quando o suporte a cache explícito será exposto no provider nativo do Bedrock, e se haverá uma forma de configurar o breakpoint sem depender de nova versão do CLI. Enquanto isso não chega, quem opera esse setup deve monitorar de perto a telemetria de tokens e considerar validar os números com a fatura real da AWS, já que as estimativas da issue vêm de dados de uso e não de invoice finalizada.

Fonte: Hacker News