Codex on AWS Bedrock overpays for cache: no control over prompt caching
Translated by a model; the original is in Russian.
A user going by apexethdev has opened issue #37674 in the OpenAI Codex repository, about unexpectedly high bills when working through the native Amazon Bedrock provider. The problem is that Codex CLI's requests to Bedrock can't take advantage of explicit prompt caching control for the GPT-5.6 Sol model. For agentic development — where long, stable instructions and tool descriptions are repeated from request to request — this turns into a huge volume of “cache-write” tokens and a noticeably higher cost.
What the numbers showed
The author offers an estimate based on AWS Cost Explorer data and the Bedrock pricing schedule for the completed days from August 5 to 8, 2026. Over that period the Sol model accounted for 3,656 requests and 171.94 million cache-write tokens. The estimated cost of the cache writes alone came to about $1,182, while total spending was on the order of $1,386. In other words, cache writes ate up roughly 85% of all spending on the model.
A separate local Codex session painted a similar picture: 76 requests, 6.709 million cache-write tokens, and at the same time zero cache-read tokens — an average of about 88 thousand write tokens per request. No client-side errors were recorded in the CloudWatch metrics. The author stresses that these are calculated estimates, not the final figures from an AWS bill.
What's causing it
Codex already passes a session-bound prompt_cache_key, but the request bodies (both over HTTP and over WebSocket) lack the prompt_cache_options and prompt_cache_breakpoint fields. The built-in Bedrock provider configuration is responsible only for transport and authentication, not for transforming the request body, so there's no way to enable caching through config.toml. Yet AWS itself documents the explicit caching mode for GPT-5.6 precisely for scenarios like this: a stable prefix of instructions and tool definitions followed by changing content.
As a fix, the proposal is to add serialization of prompt_cache_options, a typed prompt_cache_breakpoint field, a mechanism for detecting provider and model capabilities, and reporting of cache read and write statistics in per-turn telemetry — so that users can catch expensive rewrites of the entire prefix in time. The author cautions that not every cache write is a defect: cold starts, genuinely new prompts, forks, and context compaction all require writes as well.
Source: Hacker News
Comments
Sign in, to comment.