An unconfirmed single-user report alleges roughly 10x expected charges when Codex routes through AWS Bedrock, and neither OpenAI nor AWS has said anything public about it. The claim lives in a Hacker News thread; as of 2026-08-21, no vendor statement and no public metered-token export corroborates the number. Until client-side token counts are reconciled against Bedrock’s metering, 10x is a discrepancy, not a diagnosis, and the reconciliation is the part with lasting value.
What does the 10x report claim, and what is actually confirmed?
What is confirmed fits in one sentence: a Hacker News thread titled “Codex on AWS bedrock bug causing 10x charges” alleges roughly 10x expected charges when Codex routes through Bedrock. Everything that would make it a confirmed defect is absent. No vendor statement addresses it, and no public Bedrock metered-token export, CloudWatch data, or prompt-caching price sheet accompanies the claim as of 2026-08-21.
The thread does contain two observations worth separating from the headline, because each points at a different layer of the stack. First, a commenter reports that starting with model version 5.6, editing the last prompt inside the VS Code Codex plugin causes the model’s thinking to respond to the edit, polluting the prompt cache; cycling through different situations during a planning session did not do this in earlier versions. Second, another commenter speculates that versions 5.5 and below used a conventional attention scheme, where a cached KV sequence can restore a prefix of itself, while 5.6 may use linear attention, an LSTM, or another recurrent scheme whose state cannot be rewound by truncation. The commenter offers this as a guess, not as knowledge of OpenAI’s implementation.
Neither observation comes with a number attached to metering. That is the gap this article is built around.
Why do client-side token counts diverge from provider metering?
Client-side accounting and provider metering answer different questions: Codex counts the requests it knows it made and the tokens it derives from them, while Bedrock meters what arrived, in which region, under which model, and at which cache state, then prices each of those dimensions separately. Four things drive the wedge between the two ledgers. Cache accounting differs, because the provider prices cache state and the client typically reports raw context. Retries differ, because the client may log an attempt or a task while the provider meters every request the attempts generated. Routing differs, because the client addresses a region while the path a request actually takes is a provider-side fact. And visibility differs, because traffic the client cannot read never enters its ledger at all.
The practical consequence is uncomfortable for anyone building agent unit economics. Any cost-per-task figure computed from client-side token counts is unverifiable until it is reconciled against provider metering, which means the number most teams quote internally is an estimate wearing the costume of a measurement. In normal operation the two ledgers roughly agree, which is exactly why nobody reconciles them. A 10x report is what the failure of that habit looks like when it finally surfaces.
A 10x gap is a measurement problem before it is a bug.
Could prompt-cache pollution explain a 10x bill?
Cache pollution is the only suspect with a directly reported mechanism in the thread, and it remains two steps short of confirmed: the behavior report is anecdotal, and the architectural explanation for it is speculation.
The economics are straightforward. Prefix caching rewards session stability: when consecutive requests share a context prefix, the provider can reuse previously computed state instead of processing the full context as fresh input. When the prefix changes mid-session, that reuse collapses. A coding agent is close to the worst case for this, because it re-sends a long session context on every turn, and an agent whose workflow edits the recent context every few turns converts the cheapest traffic pattern available into the most expensive one. What a cache miss costs relative to a hit on Bedrock depends on the model’s current prompt-caching price sheet, which is not in evidence here, so the magnitude of this effect on the reported bill cannot be computed from the thread alone.
The architectural speculation is at least mechanically coherent. Under conventional attention, the cache holds key-value state per position, and a cached sequence can serve any prefix of itself, so truncating a session rewinds cleanly to an earlier state. Under a recurrent scheme, whether linear attention or LSTM-style state, history is compressed into a running state with no per-position record, and cutting the sequence does not restore where the model was before. Commenters note that Nemotron has shipped a hybrid architecture with recurrence via Mamba layers since around April 2025, which establishes that recurrent hybrids are in production models today. That makes the hypothesis plausible. It does not make it true of 5.6, and nothing from OpenAI says either way.
Can retry loops produce a 10x bill with no bug anywhere?
Yes, and this is the null hypothesis the thread under-weights. Peer-reviewable research formalizes retry overhead as “token inflation” and shows it can create multi-fold gaps between per-token price and actual workflow cost without any metering defect existing at all.
arXiv:2608.13571 defines token inflation as the ratio of true workflow cost to single-call cost. When a model fails on the first attempt, an agentic system retries, and each retry consumes additional tokens. The list price per token describes the single call. The invoice describes the workflow. The ratio between them is the inflation the pricing page never mentions, and it is a property of the model-plus-task combination, not of the billing system.
For coding agents the arithmetic is unforgiving. Where session context dominates the per-turn increment, an agent that needs several attempts at a task pays the dominant cost on every attempt, and the multiple compounds per task, per session, per day. Nothing has to be broken for this to produce the kind of gap in the report. This is also why the research frames inflation-aware routing as a systems problem: per-token price is the wrong denominator for agentic workloads, and cost per completed task is the right one. Before anyone blames Bedrock’s metering, they need to know how many attempts their agents actually took, because that number alone can account for a large share of any apparent multiplier.
What about region effects and traffic the client cannot see?
Two structural realities can leave a client-side ledger incomplete as a billing record: charges are metered across a regional footprint the client does not control, and traffic the client cannot read never enters its ledger at all.
On the first: AWS’s own infrastructure overview counts, for North America alone, 31 Availability Zones across 9 geographic regions, plus 31 Edge Network Locations and 3 Edge Cache Locations. That footprint makes region a real variable in any reconciliation rather than a theoretical one. Metered volume split by region is a required column in the diff, not an optional refinement, because without it you cannot attribute a charge to the workload that produced it.
On the second: invisible traffic. If any metered request never appears in the client’s logs, whether it originates from a sub-agent, a background task, or anything else issued below the client’s abstraction, the two ledgers diverge by exactly that volume. Your client accounting can be internally correct, pass every sanity check you have, and still undercount the provider’s metered total. That failure mode produces precisely the signature in the report, a bill that exceeds anything your own tooling says happened, with nothing defective anywhere in the path.
Which suspect should you rank first, pending evidence?
Rank retry-loop inflation first, cache pollution second, and region effects or invisible traffic third. The first is formalized in peer-reviewable research and requires no defect; the second has a direct anecdote but rests on unverified architecture claims; the third is documented infrastructure plus a hypothesis about ledger visibility, with no numbers attached.
| Suspect | Mechanism | Evidence status | What would confirm it |
|---|---|---|---|
| Retry-loop inflation | Failed attempts retry with full context; workflow cost exceeds single-call price by the token-inflation ratio | Formalized in arXiv:2608.13571; requires no billing defect | Attempt counts per task from agent logs, compared against single-call cost estimates |
| Cache-read misses | Mid-session prompt edits invalidate the prefix cache, converting reusable context into freshly processed input | Direct behavior report for 5.6 in the thread; architecture explanation is commenter speculation | Cache hit/miss counts for the window, plus the model’s current pricing page |
| Region effects or invisible traffic | Charges metered under a region or request source the client did not itemize, so its ledger undercounts by construction | Multi-region footprint documented by AWS; the visibility mechanism is hypothesis with no numbers attached | Per-region metered breakdown; diff of client-known requests against metered invocations |
The ranking is a prior, not a finding. The point of the runbook below is to replace it with a measurement.
How do you reconcile Codex usage logs against Bedrock metering?
The reconciliation is a three-way diff: Codex’s client-side session totals, Bedrock’s metered token counts, and CloudWatch metrics, compared over the same frozen time window and split by model and region.
Freeze the window first. Pick a bounded period with a known workload, note the timestamp boundaries, and resist the urge to reconcile “the whole month,” which mixes too many variables to isolate anything. Export Codex’s client-side usage for that window, per session and per model, including the token counts the client itself derived. Then pull Bedrock’s metered token totals for the identical window, split by model and by region, so the region axis survives into the comparison. Pull the corresponding CloudWatch metrics as the third corner of the triangle: invocation counts and token volumes that let you cross-check the metered numbers against an independent monitoring surface, all reviewable from the AWS Management Console.
Compute the ratio and classify the result into one of three outcomes. If metered tokens match client counts and the charge matches expectation, the report was a miscount and the incident is closed. If metered tokens match client counts but the charge runs far above expectation, the problem lives in pricing or configuration: cache-read pricing, region, or model selection. If metered tokens exceed client counts by a wide multiple, the gap is retries, region effects, or traffic the client never saw, and the residual gets decomposed along whichever axis moved. That decomposition, per-region splits, per-request histograms, attempt counts per task, is where the answer actually is; the headline ratio only tells you which door to walk through.
One caveat belongs inside the runbook rather than under it: these steps are hypothesis-ranked, not validated against a real export, because no public metered-token export or CloudWatch dataset for this incident exists as of 2026-08-21. The structure is sound; the confirmation is still yours to produce.
What spend controls catch runaway agents before the invoice?
Rate-based alerts and per-task retry ceilings catch runaway agents; cumulative budget totals catch them after the money is spent. A control that only trips on a cumulative threshold can fire comfortably after a retry storm has completed, which is the difference between a control and a receipt.
The instruments that matter for agent workloads are the ones that fire on shape, not just volume. Alert on the rate of token consumption, because acceleration is the signature of a loop while steady state is the signature of work. Cap attempts per task in the agent’s own configuration, because the cheapest place to stop a retry loop is before the request leaves. Treat the usage-log-to-invoice reconciliation above as a standing control run on a schedule, not an artifact assembled when a bill spikes, since a reconciliation performed only during incidents tells you about incidents and nothing about baseline drift.
The cost consequence is real and mostly unpriced. Running coding agents on Bedrock now carries the operating overhead of metering you previously ignored: reconciliation, per-region visibility, cache-state accounting, alert tuning. That is the second-order effect of a report like this one, independent of whether the 10x figure survives scrutiny. Agent unit economics on Bedrock were always dependent on provider metering; what changes is that the dependency is now visible, and visible dependencies get staffed.
Does model choice change the arithmetic on Bedrock?
Yes, materially. A case study running the same Bedrock workload across four instruction-tuned models found different accuracy and cost outcomes, with Claude 3.7 Sonnet the most favourable balance of the set.
arXiv:2604.01615 compared Claude 3.7 Sonnet, Claude 4 Sonnet, Mixtral 8x7B Instruct, and Mistral 7B Instruct on a receipt-item categorisation workload served through Bedrock, and found that model choice alone moved the accuracy-per-cost outcome substantially, with Claude 3.7 Sonnet leading on the balance between the two. The generalizable point survives the specific workload: per-task cost on Bedrock is an empirical quantity, and list token prices do not predict it, because accuracy differences change how many retries each model needs, which is token inflation again, arriving through the side door.
This connects the billing audit to the model selection decision more tightly than most teams treat them. A model that is cheaper per token but fails more often can cost more per completed task, which means the team choosing models and the team auditing invoices are optimizing the same number from opposite ends. Cost per completed task, measured on your own workload, is the only denominator that serves both.
What evidence would confirm or kill the 10x claim?
The claim resolves with three artifacts from a single billing window: a side-by-side of Codex client-side totals against Bedrock metered tokens, the cache hit and miss counts for that window, and a per-region breakdown of metered requests.
The runbook’s classification then does the deciding. A pricing outcome, metered tokens matching client counts while the charge runs far above expectation, converts into an AWS support case with the exports attached, which is a materially stronger support case than a screenshot of an invoice. An accounting gap, metered tokens exceeding client counts by a wide multiple, points the decomposition at retries, region, or traffic the client cannot see, and the incident stops being about billing. A reproduction from a second account on a clean configuration would be the strongest single signal in either direction. Absent that, one user’s ratio is one user’s ratio.
What would kill it: a reconciliation showing metered tokens, client counts, and expected charges in rough agreement. None of these artifacts exists publicly as of 2026-08-21, which is worth stating plainly, because the thread is reaching for explanations without producing any of them.
Should you change how you run agents on Bedrock today?
Treat the 10x report as an unreconciled discrepancy until proven otherwise. Diff Codex’s client-side token accounting against Bedrock’s metered tokens and CloudWatch metrics before assigning cause, then rank the three suspects: cache-read misses from prompt-edit cache pollution, retry-loop token inflation, and region effects or invisible traffic. Budget coding agents on workflow cost rather than per-token list price, and enforce spend caps that trip on runaway retry loops before the invoice lands rather than after.
The limitation is symmetrical with the advice. As of 2026-08-21 no public source contains a Bedrock metered-token export, CloudWatch data, or a prompt-caching price sheet for the model in question. Every causal claim circulating in the thread, cache invalidation and attention architecture chief among them, is community speculation or analogy drawn from adjacent research. The runbook above is hypothesis-ranked, not confirmed against vendor metering evidence, and it will stay that way until someone publishes the three artifacts.
An invoice is an assertion, not an explanation. Until the metering shows up, the 10x figure is one user’s bill and everyone else’s priors.
Frequently Asked Questions
How does the token inflation ratio from arXiv:2608.13571 differ from a standard billing error?
Token inflation is a property of the model-task combination where workflow cost exceeds single-call cost due to retries, whereas a billing error is a metering defect. The former requires no bug in the provider’s system and can be mitigated by capping attempts per task, while the latter requires vendor intervention to correct the invoice.
Why is per-region metering data required for the reconciliation runbook?
AWS North America spans 31 Availability Zones across 9 regions, making region a variable that can split charges across different pricing tiers or latency profiles. Without per-region splits, a team cannot attribute a charge to the specific workload that produced it, leaving the reconciliation unable to isolate whether the gap stems from routing or volume.
What operational change does the encrypted sub-agent traffic in Codex issue #28058 force on audit teams?
Encrypted sub-agent traffic is invisible to client-side token reconciliation, meaning the client ledger will undercount the provider’s metered total by exactly that volume. Teams must treat the client-side log as a lower bound rather than a complete record and rely on provider-side CloudWatch metrics to capture the full scope of agent activity.
How does the Nemotron Mamba architecture precedent affect the plausibility of the 5.6 cache pollution theory?
Nemotron has shipped hybrid architectures with recurrence via Mamba layers since April 2025, proving that recurrent schemes are in production. This makes the hypothesis that model 5.6 uses a recurrent scheme where state cannot be rewound by truncation mechanically coherent, though it remains unconfirmed by OpenAI as the specific cause of the cache pollution.
