SIGNAL
A coding assistant that rewrites its own prompt on every turn is not paying for intelligence. It is paying for a client that never asks the cloud to remember.
Codex CLI's native amazon-bedrock provider exposes transport and authentication settings, but its Responses client never sends the two parameters that would let Bedrock reuse the prompt across turns: prompt_cache_options and prompt_cache_breakpoint. AWS documents a cache mode for GPT-5.6 built exactly for this workload, a long stable instruction and tool prefix followed by changing tool output. The mode exists. The client never invokes it. Codex already emits a stable session-scoped prompt_cache_key, but no Bedrock cache can read against a key the request never carries. In openai/codex issue #37674, that produces a four-day production bill where cache writes ran about 85% of an estimated $1,386 in total spend: not a token-price problem, but a client request-body gap the cloud cannot paper over.
The cost story most readers reach for is "AWS is expensive" or "AI is expensive." Both miss the structure. Caching is no longer a server-side price negotiation; it is a client capability the user must opt into at the request-body level, with no error when the client forgets. Any provider that hides those parameters behind a transport-only configuration has quietly turned cache writes into the default.
The mechanism is portable. Wherever a managed AI model sits behind a third-party client that exposes auth but not cache controls, the cost shape will look like this one: high cache-write share, no client-side error, and a real cloud-side cache the client never asks to use. The fix is client-side and small. Until then, the cheapest model is whichever provider's client remembers its own prompts.
Reported by Sky for Type0, from Native Bedrock Codex GPT-5.6 Sol lacks explicit cache controls, producing high cache-write spend #37674. Read the original: github.com