On this page · 12 sections
- What changed on 21 August 2026
- What the 1.1x multiplier costs
- Why your workspace may already be pinned to us
- Where the number was right and where it was not
- What stacks on top of the multiplier
- How to tell whether this is you
- What to do this week
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. Claude Code 2.1.239, dated 21 August 2026, changed how the CLI counts money. The /cost command, the status line and the --max-budget-usd cap now include the 1.1x premium Anthropic charges for US-only inference. On Claude Opus 5 that moves the effective rate from $5 to $5.50 per million input tokens and from $25 to $27.50 per million output tokens. Anthropic has documented the multiplier for Claude 4.6 and later models on both its pricing page and its data residency page, yet the Claude Code cost documentation still does not mention data residency anywhere. Workspaces that were auto-migrated from the legacy global-routing opt-out default to inference_geo: "us", so the 10% applies to them whether or not anyone chose it in code.
What changed on 21 August 2026
The Claude Code changelog entry for version 2.1.239 is one line: "Cost estimates (/cost, status line, --max-budget-usd) now include the 1.1× US-only-inference premium for data-residency workspaces."
That is the whole announcement. It does not say what the premium is, which models it applies to, or what the previous numbers were. The answers are on two other pages.
Anthropic's data residency documentation states that on Claude 4.6 and later models, "US-only inference (inference_geo: "us") is priced at 1.1x the standard rate across all token pricing categories (input tokens, output tokens, cache writes, and cache reads)." The pricing page repeats the multiplier and adds that requests carrying inference_geo against Claude Opus 4.5, Sonnet 4.5, Haiku 4.5 or earlier return a 400 error rather than falling back to standard pricing.
So the bug was never in the billing. It was in the number the CLI showed you, and in the number the cap enforced against.
What the 1.1x multiplier costs
All rates below are Anthropic's published per-million-token prices as of 23 August 2026. The US-only column is the published rate multiplied by 1.1.
| Model | Standard input | US-only input | Standard output | US-only output |
|---|---|---|---|---|
| Claude Fable 5 | $10 / MTok | $11 / MTok | $50 / MTok | $55 / MTok |
| Claude Opus 5 | $5 / MTok | $5.50 / MTok | $25 / MTok | $27.50 / MTok |
| Claude Opus 4.6 | $5 / MTok | $5.50 / MTok | $25 / MTok | $27.50 / MTok |
| Claude Sonnet 5 | $2 / MTok | $2.20 / MTok | $10 / MTok | $11 / MTok |
| Claude Haiku 4.5 | $1 / MTok | Not supported (400) | $5 / MTok | Not supported (400) |
A team spending 200 million input and 20 million output tokens a month on Claude Opus 5 pays $1,500 at standard rates and $1,650 pinned to us. The gap is $150 a month, $1,800 a year, on one model for one team.
The --max-budget-usd case is sharper because the flag stops work. Run claude -p --max-budget-usd 5.00 on a residency-pinned workspace with a build older than 2.1.239 and the estimator reaches its $5.00 ceiling at roughly $5.50 of billable spend. Thirty nightly CI runs budgeted at $150 invoice at about $165. The cap-enforcement behaviour itself, including stopping background subagents, requires v2.1.217 or later, so a team on an older build has two separate gaps in the same flag. This is the second billing defect to surface in the same release line, after the Bedrock streaming double-billing fix that preceded it.
Note also that Claude Sonnet 5 sits at $2 and $10 per million tokens permanently. Anthropic confirmed on its pricing page that the increase to $3 and $15 previously scheduled for 1 September 2026 will not happen, which changes the arithmetic of routing cheap traffic to Sonnet under a residency pin.
Why your workspace may already be pinned to us
This is the part most teams will not have tracked. Anthropic's migration notes say that if an organisation previously opted out of global routing, "your workspace has been automatically configured with allowed_inference_geos: ["us"] and default_inference_geo: "us". No code changes are required."
That is true for behaviour and incomplete for cost. The same page's pricing-impact note says only that legacy models are unaffected by the migration. A migrated workspace still running Claude Opus 4.5 pays standard rates, because 4.5 does not support inference_geo at all. The moment that workspace upgrades to Opus 4.6, Opus 5 or Sonnet 5, the default geo it inherited starts applying 1.1x to every input token, output token, cache write and cache read. Nobody has to change a line of code for the bill to move 10%.
Two workspace settings decide this, both configurable in the Console or through the Admin API under the data_residency field. default_inference_geo sets the geo used when a request omits the parameter. allowed_inference_geos rejects requests that ask for a geo outside the list.
Where the number was right and where it was not
| Surface | Included the 1.1x before 2.1.239 | What it is |
|---|---|---|
/cost in Claude Code |
No | Estimate |
| Claude Code status line | No | Estimate |
--max-budget-usd cap |
No | Estimate that halts the run |
OpenTelemetry claude_code.cost.usage |
Not stated in the docs | Estimate, per the monitoring reference |
Usage and Cost API inference_geo dimension |
Yes | Billing record |
| Monthly invoice | Yes | Billing record |
The Claude Code monitoring reference describes the exported field as "Estimated cost in USD" and does not mention data residency. The manage costs page does not mention it either. Neither does the --max-budget-usd row in the CLI reference. Three separate cost-facing Claude Code pages omit a documented 10% multiplier that applies to the workspaces most likely to be running under a compliance mandate. The fix shipped in the binary before it reached the docs.
What stacks on top of the multiplier
Anthropic is explicit that the residency multiplier is not exclusive of the others.
| Modifier | Published rate | Stacks with US-only inference |
|---|---|---|
| 5-minute cache write | 1.25x base input price | Yes |
| 1-hour cache write | 2x base input price | Yes |
| Cache read hit | 0.1x base input price | Yes |
| Batch API | 50% discount on input and output | Yes |
| Fast mode, Opus 5 and Opus 4.8 | $10 in, $50 out per MTok | Yes |
| Priority Tier burndown | 1.1 tokens counted per token | Yes |
The Priority Tier line is the one that surprises capacity planners. Anthropic's service tiers documentation states that each token consumed with inference_geo: "us" draws down 1.1 tokens from committed throughput, "consistent with how other pricing multipliers (such as prompt caching) affect burndown rates." A residency pin therefore shortens a Priority Tier commitment by the same 10% it adds to the invoice. Capacity and spend move together, which is the same trap that shows up in enterprise inference cost planning whenever a routing decision is priced per token but constrained per commitment.
Fast mode compounds hardest. Opus 5 at $50 per million output tokens becomes $55 under a US pin, and fast mode is unavailable with the Batch API, so the usual 50% offset is not available to absorb it.
How to tell whether this is you
Read the response, not the dashboard. Every Messages API response returns usage.inference_geo showing where inference actually ran, so a single call answers the question for a given key.
For the fleet view, the Usage and Cost API accepts inference_geo as both a filter and a group_by dimension. Group a month of usage by inference_geo and the split between global, us and not_available falls out directly. Models released before February 2026, meaning anything earlier than Opus 4.6 and Sonnet 4.6, report not_available because they never accepted the parameter. That third bucket is a useful migration signal: it tells you exactly how much of your traffic is one model upgrade away from becoming 1.1x traffic.
Then check the binary. Run claude --version. Anything below 2.1.239 is showing you a /cost figure that is 10% light on a residency-pinned workspace.
What to do this week
Pin the version floor first. Set the organisation's minimum Claude Code build to 2.1.239 or later so /cost, the status line and budget caps agree with the invoice. If you rely on --max-budget-usd in CI, treat 2.1.217 as the absolute floor and 2.1.239 as the working one.
Second, reconcile one month. Pull the Usage and Cost API grouped by inference_geo and compare it against whatever internal figure your team has been quoting from /cost. A 10% delta on the us slice is the expected result, not an anomaly.
Third, decide whether the pin is a requirement or an inheritance. If the workspace was auto-migrated from the legacy opt-out and no current policy demands US-only processing, adding "global" to allowed_inference_geos and switching default_inference_geo removes the multiplier. If the pin is a genuine control, budget for it explicitly rather than discovering it in a quarterly review.
The real cost here is rarely the 10%. It is the forecast that was built on a number three documentation pages never corrected.
India-specific considerations
Indian teams should read the workspace geo section carefully before treating this as a residency solution. Anthropic states that workspace geo, which governs where data is stored at rest and where endpoint processing such as image transcoding and code execution happens, currently offers "us" as its only value and cannot be changed after a workspace is created. Inference geo likewise offers only "us" and "global".
There is no India inference geo and no India workspace geo. A team pinning inference_geo: "us" under the Digital Personal Data Protection Act 2023 is buying US-only processing at a 10% premium, not local processing. That distinction matters when a DPDP data-transfer position is being written down for an auditor, and it mirrors the storage-versus-processing split that has already caught teams out on other model platforms. Where an Indian entity's obligation is genuinely about localisation rather than about avoiding unspecified routing, the control has to sit in the architecture around the model call, not in a single API parameter. Our note on data residency and DPDP cloud architecture covers how that boundary is usually drawn.
What is still unknown
Anthropic has not said whether historical /cost output will be restated; the changelog describes a change to the estimator, not a correction of past sessions. The monitoring documentation does not state whether claude_code.cost.usage carried the multiplier before 2.1.239, so teams exporting OpenTelemetry metrics to a cost dashboard should validate that series against the Usage and Cost API rather than assume it. No date has been published for additional workspace geos or inference geos beyond us and global.
Bedrock and Google Cloud are governed separately. Anthropic's pricing page says partner-operated platforms carry independent regional pricing, and for those the endpoint or inference profile, not inference_geo, decides the geography. Teams comparing routes should read Amazon Bedrock pricing directly rather than applying the first-party multiplier by analogy. The same caution applies when weighing hosted access against direct API access in a broader enterprise LLM cost comparison.
FAQ
How eCorpIT can help
We work with engineering and finance teams that need a defensible answer to where model inference runs and what that choice costs. That work usually spans three things at once: the residency control itself, the FinOps reporting that has to reconcile against a vendor invoice, and the DPDP position an auditor will read. eCorpIT is ISO 27001:2022 certified and designs applications aligned with DPDP requirements. If your Claude Code or Claude API spend is pinned to a geo nobody on the current team selected, book a model-spend and residency review and we will reconcile a month of usage against your invoice.
References
Last updated: 23 August 2026.
