Claude Code's Data Residency Pricing Premium Explained

What changed

Claude Code's changelog entry for v2.1.239, released 21 August 2026, opens with this line:

Cost estimates (/cost, status line, --max-budget-usd) now include the 1.1x US-only-inference premium for data-residency workspaces

That's a narrower change than it might first read. Claude Code isn't introducing a new charge. The 1.1x premium already existed as an API-level pricing mechanic for data-residency workspaces. What v2.1.239 fixes is that Claude Code's own cost tooling, the /cost command, the running status line total, and the --max-budget-usd spend cap, now correctly account for that premium when it applies, instead of estimating against standard per-token rates and under-reporting what a US-pinned workspace actually spends.

If you've never configured data residency and your workspace uses the default global routing, this change is invisible to you. It matters specifically to organisations running Claude Code against a workspace pinned to US-only inference.

Two independent settings behind "data residency"

Anthropic's data residency documentation splits this into two separate controls that are easy to conflate:

• Inference geo controls where model inference actually runs, on a per-request basis, through the inference_geo API parameter or a workspace default.
• Workspace geo controls where data is stored at rest and where endpoint processing (image transcoding, code execution) happens, set once when a workspace is created and unable to change afterward. Currently "us" is the only available workspace geo.

The pricing premium this article is about is tied to inference geo, not workspace geo.

The 1.1x premium, precisely

Per Anthropic's own pricing documentation, the rule is:

• Claude 4.6 and later models: setting inference_geo: "us" is priced at 1.1x the standard rate across every token category: input tokens, output tokens, cache writes, and cache reads.
• Global routing (inference_geo: "global", the default): standard pricing applies, no premium.
• Older models: don't support the parameter at all. A request that includes inference_geo against Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5, or earlier returns a 400 error, so standard pricing is the only option there.

This pricing applies on the Claude API (first-party) and Claude Platform on AWS. On Claude in Microsoft Foundry, the same 1.1x multiplier applies specifically to Azure-hosted deployments using the US Data Zone Standard deployment type. Amazon Bedrock and Google Cloud, as partner-operated platforms, have their own separate regional pricing rather than this multiplier.

Setting inference_geo on a request

The parameter is a straightforward addition to a Messages API call:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "inference_geo": "us",
    "messages": [{"role": "user", "content": "Summarize the key points of this document."}]
  }'

The response's usage object echoes back where inference actually ran:

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 150,
    "inference_geo": "us"
  }
}

The same parameter works identically from an SDK. In Python:

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    inference_geo="us",
    messages=[{"role": "user", "content": "Summarize the key points of this document."}],
)
print(f"Inference geo: {response.usage.inference_geo}")

Claude Code itself doesn't expose a per-request flag for this. It's a workspace-level and account-level setting that Claude Code's requests inherit, which is exactly why the fix in v2.1.239 lives in cost estimation rather than in a new command-line option. If you want to confirm which geo a particular Claude Code request actually used, the underlying API response carries that in its usage.inference_geo field the same way a direct API call does, though Claude Code's own UI surfaces this as an aggregate cost figure rather than a per-request geo readout.

Workspace-level controls

Two settings, configured in the Claude Console or the Admin API's data_residency field, decide what a workspace can do here:

• allowed_inference_geos restricts which geos a workspace is permitted to use. A request specifying a geo outside that list gets an error.
• default_inference_geo sets the fallback geo applied when a request omits inference_geo entirely. An individual request can still override this explicitly.

If your organisation didn't deliberately configure either of these, you're very likely on the default global routing and none of this premium applies to you.

If you previously opted out of global routing

Anthropic's documentation addresses this directly: if your organisation had opted out of global routing under the legacy system to keep inference in the US, that workspace was migrated automatically to allowed_inference_geos: ["us"] and default_inference_geo: "us". No code changes were required to preserve the previous behaviour, but it does mean those workspaces are now exactly the ones the 1.1x premium applies to on Claude 4.6 and later models. If your data residency requirements have since changed and you'd rather use global routing, updating allowed_inference_geos to include "global" and setting default_inference_geo to "global" removes the premium going forward.

Priority Tier commitments

If your organisation has a Priority Tier capacity commitment, the multiplier reaches further than the invoice. Anthropic's documentation notes that each token consumed with inference_geo: "us" draws down 1.1 tokens against your committed tokens-per-minute capacity, the same way other multipliers, such as prompt caching, affect burndown rates. A US-pinned workload can exhaust a Priority Tier commitment faster than the same volume of requests would under global routing, independent of the dollar cost.

Claude Managed Agents and per-agent geo pinning

Claude Managed Agents, Anthropic's beta surface for server-managed stateful agents, supports its own layer of geographic control on top of the workspace-level settings above. An agent's model configuration can pin inference_geo so every session running that agent uses the same geography, with a per-session override available at session creation if a specific run needs to diverge from the agent's default. An agent without a pin simply follows the workspace's default inference geo on each request, the same fallback behaviour as an ordinary Messages API call. The same 1.1x multiplier applies here too: when an agent's configuration pins inference_geo to "us", every model request inside sessions running that agent is priced at 1.1x, same as a directly pinned Messages API call. Self-hosted sandboxes add a further wrinkle worth knowing if you're running Managed Agents this way: tool execution and the sandbox filesystem stay on infrastructure you control, but the contents of attached memory stores remain stored by Anthropic and are copied into your sandbox for the session, which is a data-location detail separate from the inference-geo pricing question.

Batch API support

The inference_geo parameter isn't limited to single, synchronous Messages API calls. Anthropic's Batch API, which already runs offline processing at 50 percent of standard cost, supports it too, and each request inside a single batch can specify its own inference_geo value independently of the others. That means a batch mixing US-pinned and globally routed requests is a legitimate configuration, not an edge case Anthropic's documentation warns against, and the 1.1x premium applies per request within that batch according to whichever geo that specific request named, layered on top of the batch discount rather than replacing it.

Current limitations

Anthropic's documentation is explicit about what this system doesn't yet do, worth knowing before you plan around it:

• Rate limits are shared across geos. Pinning inference to "us" doesn't give you a separate rate-limit pool from global routing; you're still drawing against the same shared limit either way.
• Only two inference geo values exist. "us" and "global" are the complete list. There's no finer-grained regional pinning, such as an EU-specific or APAC-specific inference geo, available through this parameter as of this documentation.
• Workspace geo has one option. "us" is currently the only available workspace geo, and it can't be changed once a workspace is created, so this isn't a setting you can revisit later the way inference_geo can be changed per request.

Who this actually affects

In practice, three groups should read the full data residency page rather than skim this summary:

1. Regulated organisations using Claude on Claude 4.6 or later models under a workspace pinned to "us" for compliance reasons.
2. Teams with a Priority Tier commitment running US-only inference, where the burndown effect matters as much as the invoice.
3. Anyone auditing a Claude Code --max-budget-usd cap set before v2.1.239, since the estimate behind that cap is now more accurate on an affected workspace, which can mean the cap triggers sooner than it used to for the same volume of work.

Everyone else, running the default global routing on a workspace with no residency restrictions, sees no change from this release beyond, arguably, a slightly more accurate /cost output in general.

A worked example

Say a compliance team runs Claude Code against a workspace migrated automatically from a legacy US-only opt-out, so default_inference_geo is "us". Before v2.1.239, a session's /cost output and status line total were computed as if every request were priced at the standard rate, understating the workspace's actual spend by roughly 10 percent on every token. After the update, those same figures multiply US-pinned usage by 1.1x to match what the API actually bills, and a --max-budget-usd cap set against that workspace now triggers at the point that reflects real spend, rather than a number that was quietly optimistic the whole time.

Troubleshooting

My /cost total looks higher after updating Claude Code, did something change with my plan? No plan or pricing change happened here specifically. If your workspace uses inference_geo: "us" on Claude 4.6 or later, v2.1.239 corrected /cost to include the 1.1x premium it was previously omitting. The underlying API cost didn't increase; the estimate became accurate.

I don't know whether my workspace is affected. Check allowed_inference_geos and default_inference_geo for your workspace in the Claude Console under Settings, or via the Admin API. If neither was ever configured, you're on the default global routing and the premium doesn't apply.

--max-budget-usd is triggering sooner than expected. If your workspace is pinned to US-only inference on Claude 4.6 or later, this is expected after v2.1.239: the cap now compares against a more accurate estimate that includes the premium. Raise the cap if the new figure reflects real, intended spend.

I set inference_geo and got a 400 error. The parameter is only supported on Claude 4.6 and later models. Requests naming it against Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5, or earlier models are rejected outright, and standard pricing is the only option on those models regardless.

I want to stop paying the premium. Update your workspace's allowed_inference_geos to include "global" and set default_inference_geo to "global" if your data residency requirements permit it. That returns future requests to standard pricing, subject to whatever compliance reason led to the US-only setting in the first place.

Where to go next

For the full mechanics, regions, and current limitations, Anthropic's own data residency documentation is the primary reference and worth reading directly rather than through a summary, since this is exactly the kind of detail that changes as the feature matures. For the wider picture of how Claude Code surfaces cost information day to day, see what Claude Code's Monitor tool does and Claude Code's usage limit auto-resume. For setting a default model per machine or workspace, ANTHROPIC_DEFAULT_MODEL explained covers a related but separate configuration surface. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code.

Verified 23 August 2026 directly against Claude Code's own changelog and Anthropic's data residency and pricing documentation at platform.claude.com.