今天，我们在去年十月推出的欧盟区域路由基础上，正式上线美国区域路由，让您对 AI 工作负载的处理位置拥有确定性控制。发送至 us.openrouter.ai 的请求会在美国境内解密，并且仅路由至美国境内的服务商端点，因此您的提示词和生成结果在请求的整个生命周期内都始终留在该区域内。eu.openrouter.ai 对欧盟区域也提供同样的保障。
企业需要更强的数据驻留与处理保障。OpenRouter 的区域路由让您轻松为美国或欧盟区域完成配置。
工作原理
通过区域专属的 base URL（而非 openrouter.ai）发送 API 请求：
https://us.openrouter.ai/api/v1
https://eu.openrouter.ai/api/v1您的 API 密钥、请求体和模型 ID 均保持不变，服务商偏好、回退设置和隐私设置也会从您的账户自动沿用。您可以将某个服务指向 us.openrouter.ai，而其余流量继续使用 openrouter.ai。
发送至 us.openrouter.ai 或 eu.openrouter.ai 的请求会在该区域内完成解密和处理，并且只有运行在该区域内的服务商才能为其提供服务。如果区域内没有服务商提供该模型，请求将返回 404（No endpoints found supporting your data region.），而不会被路由到区域之外。
区域端点以相同的模型 ID 提供全球目录中的一部分模型。如果至少有一个提供商能在该区域内提供某个模型，则该模型会列入该区域。要查看实时列表，请通过区域域名调用 /api/v1/models，或在模型页面按“区域内路由”筛选（US 或 EU）。我们将继续向两个区域添加模型和提供商。在 Discord 的 #feedback 中告诉我们你希望接下来哪些模型支持区域内服务。
你还可以通过 Guardrails 为特定工作区、团队或 API key 强制启用区域内路由。将 Guardrail 的允许数据区域设置为一个区域后，OpenRouter 会拒绝任何在其他主机名上到达的、受该规则覆盖的请求。你可以在设置中的 Guardrails 下进行配置，或通过 Management API 进行配置。
区域内路由适用于 Business 和 Enterprise 套餐。
US/EU 区域内提供的模型
如果不使用区域内路由（In-Region Routing），使用总部位于美国或欧盟的实验室所开发的模型，并不能保证请求一定由该区域内的数据中心处理。在全球端点上，来自 OpenAI、Anthropic、Google、xAI、Meta、NVIDIA、Thinking Machines 或 Mistral 的模型，可以在提供请求服务的供应商所运营的任何地方运行。数据驻留审查会询问你的请求在哪里被解密、推理在哪里执行，因此一个美国团队在全球端点上使用 GPT-5.6、Claude Opus 5 或 Gemini 3.6 Flash，仍可能无法通过合规审查。OpenRouter 的区域内路由可确保请求始终停留在你指定的区域内：美国或欧盟。
区域内可用的中国开源权重模型
开源权重模型正在快速进步，将流量转向它们可以显著降低成本。在 OpenRouter 上，无论是来自美国还是欧盟的请求，流向开源权重模型的 token 占比都在稳步上升：
来自美国实验室的模型，如 NVIDIA 的 Nemotron 3 Ultra 和 Thinking Machines 的 Inkling，是这一增长的一部分。但来自中国实验室的模型仍占据大部分流量，而这些模型的采购审批可能比较困难。
区域路由（In-Region Routing）让有数据驻留要求的团队也能获得中国开源权重模型带来的价格与性能优势。当美国或欧盟的提供商托管模型时，请求会发往该提供商，模型实验室本身不参与其中。DeepSeek V4 Pro、Kimi K3 和 GLM 5.2 均可用于美国区域路由，因为 Baseten、Fireworks 和 Azure 在美国数据中心提供这些模型的服务。通过 us.openrouter.ai 向其中任何一个发送提示词，请求都会在美国境内解密并运行。GLM 5.2 也可在 eu.openrouter.ai 上使用，由 Mistral 的欧盟数据中心提供服务。
确保端到端的区域路由
当网关提供区域路由时，它可能意味着两种不同的情况。区别在于你的提示词是否会以明文形式存在于该区域之外。
- 仅推理层面的区域路由。 网关将提供商的推理服务固定在你的区域内。但请求本身会在被转发给提供商之前，先在网关运行的地方完成解密和处理。在这段路径中，你的提示词会以明文形式存在于你的区域之外。服务器工具在区域化方面常常被忽视，这可能导致你的提示词数据离开管辖范围。例如，网络搜索有时会在区域推理端点上使用全局实例。
- 端到端区域路由。 这就是 OpenRouter 的区域内部路由（In-Region Routing）的工作方式。它确保你的数据在整个路径中都留在区域内。发往
us.openrouter.ai或eu.openrouter.ai的请求会在区域内解密，并在每一步都在区域内处理。只有运行在该区域的提供商才会收到这些请求。如果没有区域内提供商能够提供该模型，请求将以 404 失败（No endpoints found supporting your data region.）。数据永远不会离开该区域。在特定司法管辖区提供服务器工具之前，我们会全面评估这些工具及其运行所在的数据司法管辖区。会将数据发送到区域之外的工具会被禁用，而不会回退到全球基础设施。
在评估任何网关的数据驻留声明时，要问两个问题：请求在哪里被解密和处理？它的工具在哪里运行？
区域内部路由在我们的 Business 和 Enterprise 套餐中可用。你可以从 套餐设置 升级到 Business，或 联系企业团队。
然后从 US 或 EU 列表中选择一个模型，并将请求发送到 https://us.openrouter.ai/api/v1 或 https://eu.openrouter.ai/api/v1。
Today we’re launching US In-Region Routing alongside the EU routing we shipped last October, to give you guaranteed control over where your AI workloads are processed. Requests to us.openrouter.ai are decrypted inside the US and routed only to US provider endpoints, so your prompts and completions stay in-region for the entire lifecycle of the request. eu.openrouter.ai does the same for the EU.
Companies need stronger guarantees around data residency and processing. OpenRouter’s In-Region Routing makes it easy to set up for the US or EU.
How it works
Send API requests through the region-specific base URL instead of openrouter.ai:
https://us.openrouter.ai/api/v1
https://eu.openrouter.ai/api/v1Your API key, request body, and model IDs are unchanged, and your provider preferences, fallbacks, and privacy settings carry over from your account. You can point one service at us.openrouter.ai while the rest of your traffic keeps using openrouter.ai.
Requests sent to us.openrouter.ai or eu.openrouter.ai are decrypted and processed inside that region, and only providers running in that region can serve them. If no in-region provider offers the model, the request fails with a 404 (No endpoints found supporting your data region.) rather than being routed outside the region.
The regional endpoints serve a subset of the global catalog under the same model IDs. A model is listed for a region if at least one provider can serve it from inside that region. For the live list, call /api/v1/models through the regional domain, or filter the models page by In-Region Routing (US or EU). We will continue to add models and providers to both regions. Tell us which models you want in-region next in #feedback on Discord.
You can also enforce In-Region Routing for a specific workspace, team, or API key with Guardrails. Set the guardrail’s allowed data regions to one region, and OpenRouter rejects any covered request that arrives on another hostname. Configure it under Guardrails in your settings or through the Management API.
In-Region Routing is available on the Business and Enterprise plans.
US/EU models served in-region
Without In-Region Routing, using a model from a lab based in the US or EU doesn’t guarantee that a data center in that region serves the request. At global endpoints, models from OpenAI, Anthropic, Google, xAI, Meta, NVIDIA, Thinking Machines, or Mistral can run anywhere the provider serving the request operates. A data residency review asks where your request was decrypted and where inference ran, so a US team using GPT-5.6, Claude Opus 5, or Gemini 3.6 Flash on a global endpoint can still fail a compliance review. OpenRouter In-Region Routing ensures the request stays within the region you specify: US or EU.
Chinese open-weight models available in-region
Open-weight models are improving rapidly, and shifting traffic to them can significantly reduce costs. On OpenRouter, the share of tokens going to open-weight models has risen steadily for requests originating in both the US and EU:
Models from US labs, like NVIDIA’s Nemotron 3 Ultra and Thinking Machines’ Inkling, are part of that growth. But models from Chinese labs are still most of the volume, and procurement approval for those models can be difficult.
In-Region Routing allows teams with data residency requirements to get the price and performance gains from Chinese open-weight models. When a US or EU provider hosts a model, requests go to that provider and the lab is not involved. DeepSeek V4 Pro, Kimi K3, and GLM 5.2 are all available for US In-Region Routing because Baseten, Fireworks, and Azure serve them from US data centers. Send a prompt to any of them through us.openrouter.ai and it is decrypted and run in the US. GLM 5.2 is also available at eu.openrouter.ai, served from Mistral’s EU data centers.
Ensuring end-to-end regional routing
When a gateway offers regional routing, it can mean one of two things. The difference is whether your prompt ever exists in plaintext outside the region.
- Inference-only regional routing. The gateway pins the provider’s inference to your region. But the request itself is decrypted and processed wherever the gateway runs before it is forwarded to the provider. For that part of the path, your prompts are in plaintext outside your region. Server tools are often overlooked for regionalization, which can lead to your prompt data leaving the jurisdiction. For example, web search sometimes uses global instances on regional inference endpoints.
- End-to-end regional routing. This is how OpenRouter’s In-Region Routing works. It keeps your data in-region for the full path. Requests to
us.openrouter.aioreu.openrouter.aiare decrypted inside the region and processed there at every step. Only providers running in that region receive them. If no in-region provider can serve the model, the request fails with a 404 (No endpoints found supporting your data region.) It never leaves the region. We comprehensively evaluate server tools and the data jurisdictions they run in before offering them in a specific jurisdiction. Tools that would send data outside the region are disabled rather than falling back to global infrastructure.
When you evaluate any gateway’s data residency claim, ask two questions. Where is the request decrypted and processed? And where do its tools run?
In-Region Routing is available on our Business and Enterprise plans. Upgrade to Business from your plan settings, or talk to the enterprise team.
Then pick a model from the US or EU list and send your requests to https://us.openrouter.ai/api/v1 or https://eu.openrouter.ai/api/v1.