Cache writes ate 85% of a Codex Bedrock bill

A bug report filed against the Codex repository puts four days of Amazon Bedrock spending on one agentic coding workload at an estimated $1,386.46, with roughly 85% of that going to prompt cache writes. According to the issue on Github, native Codex CLI 0.147.0 requests cannot opt into explicit prompt caching for GPT-5.6 Sol.

At a glance

• Codex already sends a session-scoped prompt_cache_key, but its Responses request types, both HTTP and WebSocket, carry neither prompt_cache_options nor prompt_cache_breakpoint, the fields Bedrock's explicit cache mode requires.
• A single local Codex session logged 76 Sol requests with 6.709M cache-write input tokens, zero cached input tokens, and an average near 88K cache-write tokens per request.
• Because the built-in Bedrock provider config exposes only transport and authentication settings, no config.toml change can enable the documented explicit-cache path, leaving affected users without a workaround.

Prompt caching is the main cost lever agentic coding tools have: a long, stable prefix of instructions and tool definitions is written once and read back cheaply on every turn. With only the write path available, that economics inverts and the bill tracks prefix length instead of new work. The case reads as a provider-parity gap, where a capability AWS documents for exactly this workload is unreachable from the client generating it.

Cache writes accounted for about 85% of the model's estimated Bedrock spend

The reporter compiled AWS Cost Explorer usage quantities for the completed days 2026-08-05 through 2026-08-08 and priced them against the Bedrock rate card. For openai.gpt-5.6-sol the cache-aware estimate came to $1,386.46 across 3,656 requests, of which $1,182.09 was cache-write cost on 171.94M cache-write tokens. The traffic ran through the native amazon-bedrock provider against the Bedrock Mantle Responses API in us-east-1.

The report frames the numbers as usage-derived estimates rather than finalized AWS invoice amounts. CloudWatch metrics for the same window recorded no client errors, which places the token volume on successful requests rather than on failed calls retried by the client.

AWS documents explicit cache mode for GPT-5.6 on Bedrock, and Codex cannot send it

AWS documents an explicit cache mode for GPT-5.6 on Bedrock aimed at agentic workflows: a long, stable block of instructions and tool definitions followed by changing tool and user content. Using it requires the request to carry prompt_cache_options and a prompt_cache_breakpoint on input content blocks, and Codex's Responses request types include neither over HTTP or WebSocket.

Codex already emits a session-scoped prompt_cache_key, so the gap is limited to the two cache fields. The built-in amazon-bedrock provider configuration exposes transport and authentication settings rather than structured transformation of the request body, so the mechanism cannot be switched on from config.toml.

The report asks for a capability gate and per-turn cache telemetry

The report asks for four changes: serializing prompt_cache_options for Responses providers capable of GPT-5.6, adding a typed prompt_cache_breakpoint field to supported input content blocks, gating both behind a provider and model capability check, and placing the breakpoint at the end of Codex's measured stable instruction and tool prefix. It also asks for cache reads and cache writes to appear in per-turn usage telemetry so costly full-prefix rewrites become visible during a session.

The report does not claim that every cache write is a defect. Cold starts, genuinely distinct prompts, forks and compaction all require writes; the stated problem is that native Bedrock Codex has no way to reach the documented explicit-cache mechanism in the stable-prefix case.

No target release for the fields

The report names no version in which the serialization work would land, and the issue asks for behavior rather than announcing it. It sits next to an earlier report, #35300, in which Codex CLI 0.148.0 sent prompt_cache_retention to the same model on Bedrock and every turn failed. The newer report asks for a provider and model capability gate alongside the two new fields.