Codex on AWS Bedrock 10x Charges

The Codex on AWS Bedrock 10x charges issue is an open GitHub issue in OpenAI Codex CLI, OpenAI’s terminal coding agent. It deals with a nasty cost shape: native Amazon Bedrock, Amazon Web Services’ managed model platform, appeared to write far more cache tokens than it reused for a GPT-5.6 Sol workload. The takeaway is simple: before you let a Codex agent run long on Bedrock, prove the cache economics with a tiny run and a real bill check.

Codex CLI is a local coding agent that can inspect, edit, and run code from your terminal. This bug report matters because Codex CLI workflows are often designed to be boring and repeatable: open a repo, give the agent scoped instructions, let it work, then verify. A caching mismatch breaks that calm little loop by making a normal-looking agent session quietly expensive.

Read the issue as a billing signal, not a drama

The report was opened on August 9, 2026, against openai/codex, an Apache-2.0 Rust-heavy repository that, as of August 21, 2026, had more than 110,000 GitHub stars. The reported environment was Codex CLI 0.147.0, the native amazon-bedrock provider, a Bedrock Mantle Responses API endpoint in us-east-1, and the openai.gpt-5.6-sol model.

The claim was not “Codex is always 10x more expensive.” It was narrower and more useful: this Bedrock path did not expose explicit prompt cache controls for that model path, and one production agentic coding workload showed a very poor cache read/write ratio. Expensive cache writes piled up, while cache reads did not pay them back.

Prompt caching is a model-provider feature that lets repeated prompt prefixes be stored and reused so later requests can be cheaper or faster. The trap is assuming the word “cache” always means savings. If your agent keeps writing cache entries that it rarely reuses, caching becomes a cost center.

A real repo example makes this easier to picture. Imagine Codex is working through a monorepo with a long root AGENTS.md, package-specific instructions, failing test logs, and repeated tool context. If each turn sends a large, slightly different prompt prefix, the provider may charge for cache writes without getting enough stable reuse on later calls.

Follow the cache ratio, not the vibe

The important number in the discussion was the read/write shape. One developer reported a cache read/write ratio below 5%, meaning the workload was paying for lots of cache creation without much cache benefit. That is the sort of number you want to discover with a 10-minute experiment, not after several days of agent runs.

There is also a fair objection here: the public thread around an issue like this can become messy fast. Some comments questioned whether a router would have caught it. Others argued the issue text was hard to follow, or that defaults should not create surprising bills. The useful engineering move is to ignore the temperature and inspect the billable units.

For Codex users, the practical trap is treating a successful edit as a successful run. The agent may pass tests, produce a clean diff, and still have used an ugly request pattern. A good Codex verification loop checks both code correctness and run economics when a new provider path is involved.

A small loop is enough:

# Start with one constrained Codex task, not a day of agent work.
codex

# Ask for a tiny change, then stop after the first complete result.
# Afterward, inspect provider usage and cost in AWS Cost Explorer.

That is deliberately low-tech. You do not need a new platform to learn whether one provider/model/config path is safe enough for longer work.

Treat web search as a cost boundary

One workaround reported by a developer was disabling web search for the affected Bedrock setup: web_search = "disabled". Do not cargo-cult that into every project. Do test it if your Codex task does not need current external information.

Why might that help? Agentic coding runs get expensive when context changes across turns. Web search can add fresh, variable context, which may reduce cache reuse or increase token volume depending on the provider path and model behavior.

The trap is turning off a capability and then forgetting you did it. If the task is “upgrade this SDK using the latest migration guide,” web search may be part of the work. If the task is “fix this failing unit test in a repo with pinned dependencies,” web search is usually easier to remove.

A lightweight AGENTS.md note can make that boundary visible:

# AGENTS.md

## Provider cost boundary

When running Codex through Amazon Bedrock, prefer repo-local evidence first.
Do not use web search unless the task explicitly needs current external docs.
For any long-running task, stop after the first completed change and check AWS usage before continuing.

That instruction is not a permanent policy monument. It is a sharp repo-local reminder, scoped to the expensive path that surprised people.

Keep MCP and repo context boring

MCP is the integration layer many coding-agent workflows use to reach tools like GitHub, Slack, issue trackers, document stores, databases, and design systems. The Bedrock issue was not primarily about MCP, but MCP can amplify the same failure mode: more tools, more context, more variable prompts.

If Codex can read your issue tracker and your docs store, make the first pass read-only. A simple boundary note helps:

# AGENTS.md

## MCP boundary

Use MCP tools in read-only mode until the failing test is reproduced locally.
Summarize any external evidence in the final handoff.
Do not fetch unrelated tickets, docs, or chat threads to pad context.

This matters because a coding agent’s cheapest context is often already in the repo: tests, types, docs, fixtures, and commit history. The trap is letting the agent browse half the company before it has run npm test, cargo test, or the project’s actual verification command.

If you want more examples of comparing local coding agents in real workflows, neal Runs Claude and Codex Together is a useful adjacent read. For broader Codex CLI patterns, keep the main path under Codex CLI workflows, where the shape is task, context, verification, handoff.

Before you run this agent

Use this checklist before a long Codex run on Amazon Bedrock or any new provider path. It is intentionally small enough to do before lunch.

• Pin the path. Record Codex CLI version, provider, region, endpoint style, and model name before the run.
• Start with one repo-local task. Pick a small bug fix or test repair that does not need web search.
• Disable web search when it is not needed. Try web_search = "disabled" for the test run if your setup supports that setting.
• Keep MCP read-only. Let Codex read external systems only after it has inspected the repo and reproduced the issue.
• Stop after one completed change. Do not chain tasks until you have checked usage.
• Check cache reads and writes. Look for whether cache writes are being reused enough to justify their cost.
• Save a handoff receipt. Keep the prompt, model path, diff, tests run, and cost observation in the PR or issue comment.

A short handoff receipt can look like this:

## Codex run receipt

Codex CLI: 0.147.0
Provider path: amazon-bedrock / us-east-1 / openai.gpt-5.6-sol
Repo task: Fix failing auth timeout test
External context: web search disabled; MCP read-only
Verification: cargo test auth_timeout -- --nocapture
Cost check: reviewed AWS usage after first completed change
Decision: continue / stop / switch provider path

The limitation is obvious: this does not fix provider behavior. It only prevents surprise. That is still worth doing, because cost surprises are easiest to debug while the run is small.

Common questions

• Did Codex on AWS Bedrock definitely have a 10x billing bug?

  The public issue reports a roughly 10x cost impact for one production workload, not a universal Codex multiplier. The concrete report names Codex CLI 0.147.0, native amazon-bedrock, us-east-1, and openai.gpt-5.6-sol; treat that combination as the starting point for verification, not proof about every Codex run.

• Would OpenRouter or another routing layer have caught this?

  Maybe, but routing alone is not the safety check. A gateway can expose usage metrics or normalize provider behavior, but it cannot guarantee that your agent’s prompt shape has a healthy cache read/write ratio. The reliable check is still a small run followed by provider-billed token inspection.

• Why are cache writes expensive if caching is supposed to save money?

  Caching saves money only when later requests reuse what was written. If an agent keeps sending large, changing prompt prefixes, it may pay cache-write charges repeatedly while getting few cache reads back. In the reported discussion, a read/write ratio below 5% was the warning sign.

• Should I disable web search in Codex CLI?

  Disable web search only when the task can be solved from repo-local evidence. It was reported as a useful workaround for the affected Bedrock path, but it can make Codex worse at tasks that require current docs, migration notes, or live API behavior. Add the choice to AGENTS.md so future runs do not forget it.

• Is this only an Amazon Bedrock problem?

  The linked issue is specifically about the native Amazon Bedrock provider path for Codex CLI. The broader lesson applies anywhere a coding agent uses provider-side caching: measure cache reads, cache writes, and total billable tokens before trusting a new model path for long agent sessions.

Best ways to use this research

• Best for: Codex users testing Amazon Bedrock provider paths before longer agentic coding sessions.
• Best first artifact: Add a short AGENTS.md cost boundary that says when web search is allowed, when MCP stays read-only, and when to stop for a usage check.
• Best comparison angle: Compare provider paths by cache read/write ratio after the same small repo task, not by whether the agent produced a passing diff once.
• Best verification loop: Run one constrained Codex task, check tests, inspect AWS usage, then decide whether to continue, change config, or switch paths.

Further reading

• OpenAI Developers — Codex quickstart
• OpenAI Developers — Codex CLI
• Codex on AWS bedrock bug causing 10x charges — source

Next step

Before your next long Codex-on-Bedrock run, do one tiny repo-local task and check the cache read/write ratio afterward. If the first receipt looks strange, stop while the bill is still small.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.