A Proxy Stripped One Header and Claude Code Paid Twice

Claude Code v2.1.239 shipped on August 21, 2026 with a one-line fix that any team running Claude Code against Amazon Bedrock through a proxy needs to read twice: the release, in Anthropic’s words, “Fixed Bedrock streaming behind proxies that strip the response Content-Type header, which silently doubled billed API calls by re-running every turn non-streaming.” A gateway that dropped one HTTP header turned every conversational turn into two billed requests, and nothing in the session told you.

The phrase that matters is “silently”. Anthropic’s own Bedrock documentation already describes a different, louder failure for the same header when a proxy rewrites it rather than strips it: Claude Code refuses the response and prints a named error. The stripped case took the other branch, fell back to a non-streaming re-run, and billed the turn twice. On Bedrock there is no Anthropic dashboard to catch that for you. Claude Code sends no metrics from your cloud back to Anthropic, so the only evidence lives in your AWS bill and your own gateway logs.

This post does three things. It explains, from AWS’s own API reference, why a single header carries so much weight on Bedrock streaming. It puts the loud and the silent failure side by side in one table, a comparison Anthropic’s own documentation does not make, because the two halves are published on different pages. And it turns the documented facts into an audit method and a gateway header checklist you can run against your own deployment today, whether or not you have upgraded yet.

v2.1.239 was the sixth Claude Code version in five days. Anthropic shipped v2.1.234 on August 17 and one or two versions every day through August 21, a cadence we covered in the Aug 18 operator-changes post for v2.1.234 and v2.1.235, so we will not restate those items here. The August 21 entry is long; counting the bulleted items under its heading in the published changelog gives roughly forty-five fixes and additions, most of them small. The Bedrock fix is one bullet among them, and it is the one that touches money.

Read it as three claims. First, the trigger: a proxy between Claude Code and Bedrock that strips the response Content-Type header. Second, the behaviour: Claude Code re-ran every turn non-streaming. Third, the consequence: billed API calls doubled, silently. The third claim is the one worth pausing on, because an entry of this kind could easily have stopped at the mechanism and left the billing effect to be inferred by the reader. This one does not. We therefore treat “doubled” as the vendor’s own characterisation, scoped to each affected turn, and not as a statement about anyone’s total spend.

What the entry does not say is as important. There is no affected version range, no date the regression was introduced, no count of affected workspaces and no dollar figure. We looked for an earlier public report of this exact symptom in the anthropics/claude-code issue tracker, dated on or before August 21, and a targeted search surfaced only unrelated Bedrock issues. That is a narrow statement about one search, not proof that nobody noticed; it does mean this post cannot attribute the discovery to a reporter or a date, and neither should anyone else.

To see why a stripped Content-Type is enough to change behaviour, start with how Bedrock streaming works at the HTTP layer. Claude Code talks to Bedrock through the Invoke API pair, InvokeModel for non-streaming and InvokeModelWithResponseStream for streaming; Anthropic’s Bedrock docs state that Claude Code does not support the Converse API. AWS’s API reference for the streaming call says the response content type is always set to application/vnd.amazon.eventstream, with a separate header, x-amzn-bedrock-content-type, carrying the actual content type of the payload inside the stream.

So the outer Content-Type is not decoration. It is the signal that the body is a binary AWS event stream rather than a JSON document, and it is the one header in the exchange that every generic proxy framework understands and feels entitled to touch. The Bedrock-specific headers, x-amzn-bedrock-accept on the request and x-amzn-bedrock-content-type on the response, are names a general-purpose gateway was never written to preserve or even recognise. A proxy config that normalises outer headers for every upstream will do to a Bedrock stream exactly what it does to everything else, and the stream is the one upstream that cannot tolerate it.

One more documented fact rules out a tempting alternative explanation. Anthropic’s IAM guidance for Claude Code on Bedrock lists bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream as two distinct permissions. Streaming and non-streaming are separate authorised actions at the AWS layer. In our reading, a role missing one of them would surface as a permission error, not a quiet fallback, which is why this bug is a proxy-transport problem rather than an IAM problem. Anthropic’s changelog does not explain why an absent header took a silent code path while a wrong header takes a loud one, and we are not going to guess at Claude Code’s internal branching. The documented behaviours are enough to work with.

This is the comparison Anthropic’s own pages do not make, because the two halves live on different pages. The loud failure is in the troubleshooting section of Claude Code’s Amazon Bedrock documentation. The silent one is in the changelog. Put side by side, they describe two branches of the same fragility: Claude Code checks that a Bedrock streaming response carries the event-stream content type, and what happens next depends on whether the header is wrong or missing.

Two details from the loud branch are worth carrying forward. The docs name the common real-world shape of the rewrite, an Amazon API Gateway and Lambda integration that re-emits the stream as server-sent events, which turns the content type into text/event-stream. That example is documented for the rewrite case only; Anthropic does not say what produced the stripped header in the silent case, and we will not extend the example to cover it. And the docs provide a deliberate escape hatch for the rewrite case, covered in the callout below, which has no documented counterpart for the stripped case because the fix for that one is simply the upgrade.

The reason a doubled call could stay silent is structural, and Anthropic documents it plainly in its cost-management guide. On cloud-provider deployments, Claude Code sends no metrics back to Anthropic. The analytics dashboards and the Claude Code Analytics API that first-party customers use to watch spend do not cover Bedrock usage at all. There was no vendor-side counter that could have flagged a two-to-one ratio of requests to turns, because the vendor never saw the requests.

The same guide lists what you do have. For per-user attribution on a cloud provider it names three paths: OpenTelemetry export from Claude Code itself, a self-hosted Claude apps gateway, or a third-party LLM gateway. It names LiteLLM as an example of the third, describing it as an open-source tool that tracks spend by key, and in the same breath states that the project is unaffiliated with Anthropic and has not been audited for security. Add the AWS bill itself and you have the surfaces on which double execution could ever have been visible. The grid below sets them beside the one place it never showed at all.

This is the same shape of problem we described in the GitHub Copilot credit-billing audit: the vendor’s own meter is the wrong instrument when the metered thing happens somewhere the vendor cannot see. On Bedrock that is by design. Anthropic’s position is that cloud-provider usage is yours to observe, and the documentation hands you the three tools and steps back.

Because no affected-version range is published, the only honest way to know whether your deployment paid twice is to look. The method below is our synthesis of the documented facts: Claude Code uses exactly two Bedrock operations, those operations are distinct actions at the AWS layer, the bug re-ran each turn non-streaming, and Anthropic has no view of any of it. Everything else is ordinary log analysis.

Step 1: scope the search to the Invoke pair

Claude Code does not use the Converse API, so you are only looking for InvokeModelWithResponseStream and InvokeModel. If your gateway logs the operation name or the target path, filter to those two. Anything else in the Bedrock log is not Claude Code traffic, or at least not this bug.

Step 2: look for the streaming and non-streaming mix

A healthy Claude Code session on Bedrock is overwhelmingly streaming. The signature of the bug is a streaming request followed closely by a non-streaming request for the same model, from the same client, with a near-identical payload size. If your gateway assigns request IDs and records the client or session identity, pair them: one turn should map to one upstream call. Two upstream calls per turn, one of each kind, is the pattern the changelog describes.

Step 3: confirm the trigger at the proxy edge

Capture a Bedrock streaming response on the client side of your proxy. Per AWS, the upstream always sets Content-Type: application/vnd.amazon.eventstream. If the header reaches Claude Code rewritten, you are in the loud branch and would already have seen the error. If it reaches Claude Code absent, you were in the configuration the fix describes, and every pre-upgrade session through that proxy is in scope.

Step 4: reconcile with the client-side view

If you export OpenTelemetry from Claude Code, count turns there and compare with upstream requests at the gateway over the same window. A ratio near two on the streaming paths is the finding. A ratio near one means the proxy was passing the header, or the sessions predate whatever introduced the fallback, which, again, Anthropic has not dated.

A note on what this audit cannot do. It can show that double execution happened on your deployment and bound the window to when the proxy was stripping the header. It cannot tell you which Claude Code version introduced the fallback, because that is unpublished, and it cannot distinguish a pre-fix doubled turn from an ordinary client retry without the pairing in Signal A. Treat the numbers it produces as evidence for a conversation with your AWS account team, not as a settled figure.

Anthropic’s documentation scatters the header requirements for a gateway-fronted Claude Code across three pages: the Bedrock guide, the environment-variable reference and the LLM gateway guide. The table below gathers them into one checklist. Where Anthropic does not document what happens when a header is dropped, the cell says so, because an undocumented failure is a risk to test rather than a fact to cite.

Where does a stripped header come from in practice? The honest answer is that Anthropic does not say, and we are not going to name a product. What the primary documentation does let us rule out is the defaults of the two most common layers. nginx’s proxy_set_header documentation lists only Host and Connection as the headers it rewrites by default, plus a set of caching-conditional headers when caching is enabled; Content-Type is not among them, so an nginx strip implies an explicit override or a body-rewriting module. AWS’s Application Load Balancer header documentation concerns the X-Forwarded-* family and documents no default Content-Type rewriting. The one concrete example Anthropic gives, the API Gateway and Lambda re-emit, is for the rewrite branch. Anything more specific is a guess.

The Bedrock fix is the most expensive-sounding entry, but it is not the first time in 2026 that the changelog has recorded a fix to cost-relevant behaviour for sessions running through a gateway or a custom base URL. Two prompt-caching fixes for such sessions sit earlier in the same changelog, sixty-four days apart, one with a documented cause and one with no cause stated at all. Those are the entries we can name rather than a tally: we have not audited every 2026 release for cost-relevant gateway fixes, so read three as a floor. Laid out in order, they make the case that header and request fidelity through an intermediary is a standing operational requirement rather than a one-off bug.

Anthropic’s gateway guide is candid about why this keeps happening. It states that gateways passing traffic on to Anthropic must forward the OAuth capability in the anthropic-beta header, and it warns that a gateway which does not forward the new capabilities Claude Code adds with each release breaks the corresponding features. It also disclaims the whole category: Anthropic does not endorse, maintain or audit third-party gateway products. Responsibility for fidelity sits with whoever operates the intermediary. That is a reasonable position, and it is also exactly why the audit in section 05 has to be yours.

One adjacent cost vector belongs in the same conversation. The cost guide notes that prompt caching defaults to a five-minute TTL on an API key or cloud provider, against one hour on a subscription. A gateway that buffers or delays requests can therefore cause cache misses on Bedrock independently of any header bug. If your gateway audit is already open, check cache-read rates while you are in there. We wrote up the design side of this, how a gateway is supposed to preserve request fidelity in the first place, in our LLM gateway architecture reference, and the generic double-execution discipline in the webhook idempotency reference. A fallback path that re-runs work without an idempotency key is the same bug whether it lives in a webhook consumer or inside an agent’s own HTTP client.

The same v2.1.239 release carries a second cost line that is easy to misread: “Cost estimates (/cost, status line, --max-budget-usd) now include the 1.1× US-only-inference premium for data-residency workspaces.” That is the complete entry. It changes what three estimate surfaces show. It does not change what anyone is charged, and it applies to a different deployment surface from the Bedrock bug.

The premium itself predates the release and is documented independently on Anthropic’s data-residency page: US-only inference, selected with inference_geo: "us", is priced at 1.1× the standard rate across input tokens, output tokens, cache writes and cache reads. It applies to Claude 4.6 and later models; earlier models return a 400 on the parameter. The page says the same multiplier applies to Microsoft Foundry deployments using the US Data Zone Standard type, and that Amazon Bedrock and Google Cloud have their own regional pricing, which puts Bedrock outside this multiplier entirely.

Two cautions on how to describe this. The changelog says the estimates “now include” the premium; it does not say the prior estimates were wrong, and no second source characterises the previous display, so we write it the way Anthropic does. And the premium has a capacity side as well as a price side: the data-residency page states that under a Priority Tier commitment each token consumed with inference_geo: "us" draws down 1.1 tokens from the committed throughput. If the estimates previously excluded the premium, which is the natural reading of “now include” though not something Anthropic states outright, a --max-budget-usd cap tuned against them on a data-residency workspace would trip after about nine percent fewer tokens once upgraded, since a fixed dollar cap divided by a 1.1× estimate buys 1/1.1 of the tokens. What is actually spent does not change.

The right response depends on where Claude Code sits in your stack. The upgrade is the same for everyone; the audit and the follow-through are not.

Beyond this one bug, the durable lesson is the one we keep coming back to in our AI cost-optimisation discipline: the meter you trust has to be on the side of the boundary where the money leaves. For Bedrock that is your gateway and your AWS account, and it needs to be instrumented before the next silent fallback, not after. Teams that already run Claude Code’s auto mode on Bedrock, which we covered when the classifier defaults reached Bedrock, Vertex and Foundry, have the most turns per session and the most to gain from pairing OpenTelemetry with gateway logs. If you want that instrumentation designed rather than improvised, our AI transformation engagements start from the billing boundary, and our analytics practice builds the reconciliation that keeps the two counts honest.