Codex no Bedrock da AWS gera gasto extra por não usar cache explícito de prompt
Issue no repositório do Codex mostra que o provider nativo da Amazon Bedrock não expõe controles de cache, inflando tokens de cache-write em workloads de coding agêntico.
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_optionsprompt_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_optionspara providers Responses compatíveis com GPT-5.6. - Um campo tipado
prompt_cache_breakpointnos 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
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
