A $300 Codex Bill Came Back as $1,200. Nothing Changed.

TL;DR

If you run Codex CLI against Amazon Bedrock, go look at your bill before you read the rest of this. Users on issue #37674 report that since version 0.147.0 the prompt cache stopped hitting entirely: cache reads at zero, near-full prefix rewrites on every turn, each one billed at 1.25x the uncached input rate. One user measured a cache write-to-read ratio jumping from 0.08 to 8.84 and daily spend of at least 5x. An OpenAI engineer replied on August 20 blaming a newly enabled web search tool and posted a one-line workaround. The issue is still open.

Why a cache miss on Bedrock is worse than free

This only bites on the newest models, and that is the part most people have not internalized. Per AWS documentation, GPT-5.5 and earlier cache automatically on Bedrock with no cache-write fee. GPT-5.6 Sol, Terra and Luna moved to explicit cache breakpoints: 1,024-token minimum prefix, 30-minute default TTL, reads at a 90% discount, and writes billed at 1.25x the uncached input token rate.

So a cache miss on GPT-5.6 is not cost-neutral. It is a 25% surcharge on your entire stable prefix, charged again on every single turn of an agent loop that was specifically designed to send that prefix over and over.

Think of it as a coat check that started charging a small fee to hang the coat and pennies to hand it back. Great deal, right up until something makes you re-hang the same coat every time you walk past.

The regression, as measured

The clearest datapoint in the thread comes from a user who bisected it against Codex versions. After upgrading from 0.146.0 to 0.147.0 on the Bedrock provider, they report the cache write-to-read ratio went from 0.08 to 8.84 and daily cost rose to at least 5x. Rolling back to 0.146.0 dropped the ratio straight back to 0.025 with a 97% cache-read rate.

The signature to look for in your own usage payloads is blunt: cache_write_tokens large on every request, cached_tokens sitting at zero. AWS spells out the healthy version of the same fields, where reads are high and writes are zero once a prefix is established.

What it cost the people who noticed

The original report, filed August 9, covers four completed days of production usage from August 5 to 8: 3,656 requests, 171.94M cache-write tokens, and a Cost Explorer plus rate-card estimate of $1,182.09 in cache-write spend inside $1,386.46 total for the model. That is roughly 85% of the model's estimated spend going to writing a cache nobody was reading.

The reporter is careful to label those as usage-derived estimates rather than finalized AWS invoice amounts, and so are we. On August 21 the same user posted a blunter version: a bill past $1,200 that would normally have been about $300, caught a day late.

OpenAI's answer, and the one-line workaround

On August 20 an OpenAI engineer replied in the thread:

this is most likely caused by cache miss caused by newly turned on web search tool and we are working with bedrock team for the fix. In the meantime, feel free to disable the tool as a workaround (in config, add web_search = "disabled"). note codex will still be able to perform web search via other tools such as shell commands

Hours later, the user who did the version bisect confirmed it on 0.148.0: with web_search = "cached" the cache reads stayed at zero, and with web_search = "disabled" caching resumed normally. So the remedy today is to switch off a tool that was switched on for you, and let the agent shell out to search instead.

Worth noting what that diagnosis implies. The trigger is not something you configured, did not appear in your diff, and shows up only as a number in a billing console you probably check weekly.

The structural gap underneath it

The web search tool is the proximate cause. There is a longer-running hole beneath it, filed on July 25 as issue #35300: Codex cannot emit a prompt_cache_breakpoint at all.

A contributor audit posted August 18 against main found the Responses request structs carry only prompt_cache_key, with no prompt_cache_options and no per-block breakpoint field anywhere in the API crate. AWS documents implicit mode as the default, which drops an automatic breakpoint on the latest message. That works when the stable prefix genuinely stays stable. It gives you nothing to grab when something upstream keeps moving the prefix, because Codex has no way to pin a breakpoint at the boundary between its constant instructions and tool specs and the per-turn tail, even though it is the code that builds that boundary.

One user got tired of waiting and shipped a patch on a personal fork that sets explicit breakpoints at stable and recent-history boundaries. Their reported test run: 35 Bedrock rollouts, 1,486 provider responses, 30 multi-request sessions all cache-healthy, and a 97.771% aggregate cache-read ratio after seed requests. Upstream PRs to the repo are invitation-only, which is why the fix lives on a fork rather than in your next release.

What to do this morning

• Check the ratio, not the total. Compare cache_write_tokens against cached_tokens in your Responses usage objects. Zero reads with large writes every turn is the tell.
• Set the workaround. Add web_search = "disabled" to your Codex config if you are on the Bedrock provider. The cached value is not a middle ground here; it still produced zero reads in testing.
• Pull four days of Cost Explorer. The reporters caught this because they priced cache-write quantities against the rate card, not because anything failed. There were no client errors in CloudWatch.
• This is Bedrock-specific. The reports concern the native Bedrock provider and the Mantle Responses endpoint. Direct first-party OpenAI inference is described in the thread as behaving as expected.

The caveats, straight

OpenAI's explanation is hedged as "most likely" and the fix is described as in progress with the Bedrock team, not shipped. The dollar figures are user estimates derived from Cost Explorer quantities and published rates, not settled invoices. The workaround has one public confirmation on 0.148.0 so far. The issue remains open, tagged aws-bedrock and rate-limits, and it reached the Hacker News front page overnight, which historically does more for fix velocity than any of the above.

Key Takeaways

• Codex CLI users on Amazon Bedrock report zero prompt-cache reads and full-prefix cache writes since 0.147.0, with one bisect showing the write-to-read ratio going from 0.08 to 8.84 and reverting to 0.025 on rollback.
• On GPT-5.6 models on Bedrock, cache writes are billed at 1.25x uncached input and reads at a 90% discount, so a persistent miss is a surcharge rather than a lost discount. GPT-5.5 and earlier had no cache-write fee.
• The originally filed four-day estimate put $1,182.09 of $1,386.46 in model spend into cache writes across 3,656 requests, and a later comment describes a $300 bill arriving above $1,200.
• An OpenAI engineer attributes it to a newly enabled web search tool and recommends web_search = "disabled"; that was confirmed working on 0.148.0 while the cached setting was not.
• Underneath the regression, Codex still cannot emit explicit cache breakpoints at all, an open request since July 25 that a community fork has patched independently.
• Nothing here throws an error. If you are running agents against a metered provider, cache-hit ratio belongs on your dashboard next to latency and token count.

Sources: openai/codex issue #37674, openai/codex issue #35300, AWS Bedrock prompt caching documentation, AWS: OpenAI models and Codex GA on Bedrock, Codex 0.148.0 release, community cache-breakpoint patch, Hacker News discussion.