Short version: Claude data residency is two knobs, not one. inference_geo is a per-request API parameter that pins where the model runs — "us" keeps inference on US infrastructure, "global" (the default) runs it anywhere for availability. Workspace geo is a separate, create-time, currently-US-only setting that pins where your data is stored at rest and where endpoint processing happens. Flipping inference_geo to "us" costs you 1.1x on every token and satisfies the compute half of a residency requirement — but it does not, by itself, cover storage. If you set only the flag to pass an audit, you've paid the 10% and still left at-rest storage governed by your workspace default.

The one thing founders get wrong#

The pattern is common: a customer contract has a data-residency clause, an engineer finds inference_geo, sets it to "us", and marks the ticket done. That covers where inference runs — genuinely useful — but residency reviewers usually care about where data is stored and processed, and that is a different setting entirely.

Anthropic splits it deliberately into two independent controls:

A complete US-only posture needs both. The flag alone moves the compute; the workspace setting moves the storage. Reach for one when you mean the other and you've either overpaid or under-delivered.

Setting inference_geo, in code#

It's one field. Pass inference_geo on the request and read usage.inference_geo on the response to confirm where it actually ran:

import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    inference_geo="us",  # or "global" (default)
    messages=[{"role": "user", "content": "Summarize the key points of this document."}],
)

# Verify where inference ran — don't assume, check
print(response.usage.inference_geo)  # -> "us"
const response = await client.messages.create({
  model: "claude-opus-5",
  max_tokens: 1024,
  inference_geo: "us",
  messages: [{ role: "user", content: "Summarize the key points of this document." }],
});
console.log(response.usage.inference_geo); // "us"

The response's usage.inference_geo is the receipt: it tells you where inference actually ran, which is what you want in your logs when someone asks you to prove it.

What it costs#

On Claude 4.6 and later, inference_geo: "us" is priced at 1.1x the standard rate across every token category — input, output, cache writes, and cache reads. "global" is standard price. So the cost isn't just on the tokens you generate; your prompt-cache reads get the 10% too, which matters for cache-heavy agent loops.

Two second-order effects worth knowing:

The platform and model fine print#

Two constraints will bite if you don't check first:

For agent workloads there's one more: Claude Managed Agents don't support inference_geo, but they do respect the workspace geo. So for a Managed Agent, the residency lever is the workspace setting, not the per-request flag. If you run self-hosted sandboxes, tool execution and the sandbox filesystem stay on infrastructure you already control.

Enforcing it across a team#

Setting the flag per request is fine for one service; it doesn't scale to an org where any engineer can forget it. Two workspace-level controls close that gap, configurable in the Console or via the Admin API under data_residency:

If your organization opted out of global routing in the past, this already happened to you: your workspace was auto-migrated to allowed_inference_geos: ["us"] and default_inference_geo: "us", and every request keeps running on US infrastructure with no code change. Want the availability of global routing back? Add "global" to the allowed geos and set the default. Just remember the current limits: rate limits are shared across geos, only "us" and "global" exist, and workspace geo is US-only and permanent once set.

The founder read#

Treat inference_geo as what it is: a per-request switch for where the model runs, priced at a flat 10% on Claude 4.6+. Use it to route the specific traffic a contract requires onto US infrastructure — and log usage.inference_geo so you can prove it. But don't mistake it for a data-residency solution. Where your data lives at rest is workspace geo, a separate knob you pick once at workspace creation and can't change later. Get both right, pay the 10% only on the requests that need it, and you have a residency story that survives a compliance review — which, in the post–August 2 EU-transparency world, more of your enterprise customers are going to ask for.