Claude's Two Regions, Neither Is Europe

§1The setting everyone assumes exists

If you build on Claude from the UK or the EU, sooner or later someone in the room asks the obvious question: can we keep the data in our region? The reasonable assumption is that there is a setting for it, the same way there is for a storage bucket or a database. There is a setting. It just does not do what most people assume.

Anthropic shipped region controls for the Claude API, and on 7 August they extended the same pinning to their Managed Agents product. We read the docs properly, because "we pin it to our region" is the kind of sentence that ends up in a client's compliance pack, and it is worth being right. The short version: the first-party Claude API can pin where inference runs to exactly two places, and neither of them is Europe.

§2Two knobs, not one

There are two independent controls, and treating them as one is where the trouble starts.

The first is inference_geo, a per-request parameter on the messages endpoint. It controls where the model actually runs your prompt. The second is workspace geo, set once when you create a workspace, which controls where data is stored at rest and where the side processing happens, things like image transcoding and code execution.

People hear "region" and assume both move together to wherever they like. They do not. They are separate settings with separate, and much shorter, option lists.

§3The option list is short

inference_geo accepts two values. "global", the default, means inference may run in any available geography. "us" means it runs only on US infrastructure. That is the entire menu. There is no "eu", no "uk", no "europe".

Workspace geo is tighter still for a European team: "us" is the only value available, and it cannot be changed after the workspace is created. So even the data-at-rest question has exactly one answer today, and it is the United States.

Three details worth knowing before you build on this:

• Model floor. It only works on Claude 4.6 and later. Pass inference_geo to Opus 4.5, Sonnet 4.5, Haiku 4.5 or anything older and you get a 400.
• It costs. Pinning to "us" is priced at 1.1x the standard token rate, across input, output and cache. "global" is standard price. If you are on a committed tier, US-only also burns 1.1 tokens of capacity per token.
• API only. It is a first-party-API feature (and Claude Platform on AWS). Through the OpenAI-compatible endpoint it is not available at all.

So the honest state of play: first-party Claude gives you US-or-global for inference and US-only for storage. If your requirement is "keep it in the US", it is a one-line parameter. If your requirement is "keep it in Europe", the API cannot do it.

§4So where does EU residency actually come from

Not from Anthropic's API. It comes from renting Claude through a cloud provider that already runs in your region.

Run Claude through Amazon Bedrock in an EU region, or Google Vertex in an EU region, and the data stays in that region, because AWS or Google keeps it there. The region is decided by the endpoint you call, not by an inference_geo flag; on those platforms the flag does not even apply. Microsoft's Foundry has EU support listed as coming in 2026, with no firmer date than that.

That is the actual mechanism, and it is worth saying plainly, because "Claude is available in Europe" quietly means "available to rent from a hyperscaler who keeps it in Europe", not "Anthropic will keep your data in Europe". Same model, completely different data path, and only one of them satisfies a European residency requirement.

§5The decision map

Here is the whole thing as a map you can hand to anyone asking "can we use Claude with our data":

• Do you actually need residency? A lot of teams do not. If not, use global, pay standard price, move on.
• Need inference kept in the US? First-party API, inference_geo: "us", model 4.6 or later, 1.1x price. Storage is US anyway.
• Need the data in the EU or UK? The first-party API cannot do it. Use Bedrock or Vertex in an EU region and let the provider hold the line. Watch Foundry EU for 2026.
• Care about retention, not location? That is a third, separate lever (zero data retention). Don't confuse it with geography.

We turned that into a one-page decision map you can keep on file: download the PDF. The lesson under it is the general one, and it is not specific to Claude: a "region" setting from a model vendor is not the same thing as data residency, and the two knobs, where it runs and where it rests, rarely move together. Read the option list before you write the sentence into a compliance document. We nearly wrote the wrong one.