Codex AWS Bedrock cache bug: how a toggle 5x'd a bill

The Codex AWS Bedrock cache bug is the most useful thing I have read this month, because it is not a bug in anybody's application code. It is a billing failure caused by a prompt cache quietly not hitting, and the person paying only found out by reading AWS Cost Explorer.

I am commenting on openai/codex issue #37674, opened on 9 August 2026 by GitHub user apexethdev. It is still open at the time of writing. Everything below is my reading of it, not a reprint.

---

💸 The numbers that started it

The reporter was running Codex CLI 0.147.0 against the native amazon-bedrock provider, model openai.gpt-5.6-sol, on the Bedrock Mantle Responses API in us-east-1. Over four completed days they pulled usage quantities out of Cost Explorer and applied the Bedrock rate card:

Metric	Value
Requests (5–8 Aug 2026)	3,656
Cache-write tokens	171.94M
Estimated cache-write cost	$1,182.09
Estimated total cost	$1,386.46
Cache-write share of spend	~85%

A single local session showed the same shape in miniature: 76 requests, 6.709M cache_write_input_tokens, zero cached_input_tokens, averaging roughly 88K cache-write tokens per request.

The reporter is careful to say these are usage-derived estimates, not a finalised AWS invoice. I am repeating that caveat because it matters.

Zero cache reads is the tell. The agent was writing the cache on every single turn and never reading it back.

---

🔍 Why the headline says 10x and the thread says 5x

The version of this story doing the rounds is "10x charges." The thread itself is more specific and more interesting. A second user, kevmyung, reported that upgrading from 0.146.0 to 0.147.0 moved their cache write-to-read ratio from 0.08 to 8.84, with daily cost rising to at least 5x its previous level. Rolling back to 0.146.0 put the ratio straight back to 0.025 with a 97% cache-read rate.

That is a cleaner signal than any dollar figure, and it is the one you can reproduce yourself:

cache_write_input_tokens / cached_input_tokens

Healthy long agent sessions sit far below 1. If that number crosses 1 and stays there, your prompt prefix is being re-billed every turn.

---

🛠️ The actual cause was a tool being switched on

On 20 August 2026, celia-oai (the OpenAI engineer the issue is assigned to) replied that the cause is most likely a cache miss introduced by the newly enabled web search tool, and that they are working with the Bedrock team on a fix. The suggested workaround, in config.toml:

web_search = "disabled"

Codex can still search via shell commands, so you lose less than the setting name suggests. kevmyung then tested it on 0.148.0 and confirmed the behaviour:

web_search setting	Cache reads
"cached"	zero
"disabled"	caching resumed normally

Key takeaway: a single tool definition appended to your system prompt can invalidate the entire cached prefix behind it, and the cost of that invalidation scales with your context size, not with the size of the tool definition.

That is the general lesson, and it applies to every provider with prompt caching, not just Bedrock. A cached prefix is a prefix. Change any byte early in it and everything after it is a cache write.

---

📉 The deeper gap in the client

Separately from the web-search trigger, the thread surfaced a real structural gap. Contributor jdcodes1 traced it on main: the Responses request structs carry only prompt_cache_key, with no prompt_cache_options and no per-block prompt_cache_breakpoint anywhere in codex-api. On Bedrock, where caching for this model is explicit opt-in rather than implicit, that means there is no supported way to say "cache up to here."

Two community patches exist. One from devonpmack adds the request-body side. Another from scottleibrand sets explicit breakpoints at stable and recent-history boundaries, and reports from production testing:

• 35 rollouts, 1,486 provider responses
• 30 multi-request sessions, all cache-healthy
• 97.771% aggregate cache-read ratio after seed requests
• 99.958% aggregate read-or-write coverage

Those are fork PRs, not merged upstream. Treat them as evidence the fix is tractable, not as something to run on a production key tonight.

---

🌐 Why this lands harder from Sri Lanka

If you are in Colombo running an agentic coding setup on your own card, the failure mode is not "a surprise line item on the company AWS account." It is a USD charge against a personal card, converted at the day's rate, with an outward remittance limit sitting behind it.

Three habits worth building:

1. Set an AWS Budget with an alert before you set up the model. Not after. A daily threshold at 2x your expected spend catches a cache regression within 24 hours instead of at month end.
2. Pin your CLI version. The 0.146 → 0.147 jump in this thread cost real money. Auto-updating a metered client is a billing decision, not a convenience.
3. Read the usage fields per turn. Cache reads and cache writes as separate buckets. If your tooling only shows "input tokens," you are blind to exactly this class of bug.

Before you commit to a workload, it is worth modelling the two scenarios side by side. Our prompt caching cost calculator shows what a cached prefix should cost versus a rewritten one, and the AI agent cost calculator covers multi-turn sessions where the prefix grows every turn. For the LKR side of the sum, the live LKR exchange rate is there.

---

💡 What this means for you

The reporter's own framing is the fairest one in the thread: not every cache write is a defect. Cold starts, genuinely new prompts, forks and context compaction all legitimately require writes. The problem is a client that gives you no way to use the documented caching mechanism, combined with a default that silently turns it off.

Bottom line: with agentic coding tools, your bill is a function of your cache hit rate, not of how much you typed. Instrument that ratio, alert on it, and pin the version that produced it.

If you are on Codex CLI with Bedrock right now, check your cache-read ratio today, and try web_search = "disabled" if it is at zero. If you are on any other agent, the audit is the same: find where your cached prefix ends, and find out what changes it.