Loading...
    • Developer Guide
    • API Reference
    • MCP
    • Resources
    • Release Notes
    Search...
    ⌘K
    First steps
    Intro to ClaudeQuickstart
    Models & pricing
    Models overviewChoosing a modelWhat's new in Claude 4.6Migration guideModel deprecationsPricing
    Build with Claude
    Features overviewUsing the Messages APIHandling stop reasonsPrompting best practices
    Context management
    Context windowsCompactionContext editing
    Capabilities
    Prompt cachingExtended thinkingAdaptive thinkingEffortStreaming MessagesBatch processingCitationsMultilingual supportToken countingEmbeddingsVisionPDF supportFiles APISearch resultsStructured outputs
    Tools
    OverviewHow to implement tool useFine-grained tool streamingBash toolCode execution toolProgrammatic tool callingComputer use toolText editor toolWeb fetch toolWeb search toolMemory toolTool search tool
    Agent Skills
    OverviewQuickstartBest practicesSkills for enterpriseUsing Skills with the API
    Agent SDK
    OverviewQuickstartTypeScript SDKTypeScript V2 (preview)Python SDKMigration Guide
    MCP in the API
    MCP connectorRemote MCP servers
    Claude on 3rd-party platforms
    Amazon BedrockMicrosoft FoundryVertex AI
    Prompt engineering
    OverviewPrompt generatorUse prompt templatesPrompt improverBe clear and directUse examples (multishot prompting)Let Claude think (CoT)Use XML tagsGive Claude a role (system prompts)Chain complex promptsLong context tipsExtended thinking tips
    Test & evaluate
    Define success criteriaDevelop test casesUsing the Evaluation ToolReducing latency
    Strengthen guardrails
    Reduce hallucinationsIncrease output consistencyMitigate jailbreaksStreaming refusalsReduce prompt leakKeep Claude in character
    Administration and monitoring
    Admin API overviewData residencyWorkspacesUsage and Cost APIClaude Code Analytics APIZero Data Retention
    Console
    Log in
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...
    Loading...

    Solutions

    • AI agents
    • Code modernization
    • Coding
    • Customer support
    • Education
    • Financial services
    • Government
    • Life sciences

    Partners

    • Amazon Bedrock
    • Google Cloud's Vertex AI

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Company

    • Anthropic
    • Careers
    • Economic Futures
    • Research
    • News
    • Responsible Scaling Policy
    • Security and compliance
    • Transparency

    Learn

    • Blog
    • Catalog
    • Courses
    • Use cases
    • Connectors
    • Customer stories
    • Engineering at Anthropic
    • Events
    • Powered by Claude
    • Service partners
    • Startups program

    Help and security

    • Availability
    • Status
    • Support
    • Discord

    Terms and policies

    • Privacy policy
    • Responsible disclosure policy
    • Terms of service: Commercial
    • Terms of service: Consumer
    • Usage policy
    Administration and monitoring

    Data residency

    Manage where model inference runs and where data is stored with geographic controls.

    Data residency controls let you manage where your data is processed and stored. Two independent settings govern this:

    • Inference geo: Controls where model inference runs, on a per-request basis. Set via the inference_geo API parameter or as a workspace default.
    • Workspace geo: Controls where data is stored at rest and where endpoint processing (image transcoding, code execution, etc.) happens. Configured at the workspace level in the Console.

    Inference geo

    The inference_geo parameter controls where model inference runs for a specific API request. Add it to any POST /v1/messages call.

    ValueDescription
    "global"Default. Inference may run in any available geography for optimal performance and availability.
    "us"Inference runs only in US-based infrastructure.

    API usage

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

    Response

    The response usage object includes an inference_geo field indicating where inference ran:

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

    Model availability

    The inference_geo parameter is supported on Claude Opus 4.6 and all subsequent models. Older models released before Opus 4.6 do not support the parameter. Requests with inference_geo on legacy models return a 400 error.

    The inference_geo parameter is only available on the Claude API (1P). On third-party platforms (AWS Bedrock, Google Vertex AI), the inference region is determined by the endpoint URL or inference profile, so inference_geo is not applicable. The inference_geo parameter is also not available via the OpenAI SDK compatibility endpoint.

    Workspace-level restrictions

    Workspace settings also support restricting which inference geos are available:

    • allowed_inference_geos: Restricts which geos a workspace can use. If a request specifies an inference_geo not in this list, the API returns an error.
    • default_inference_geo: Sets the fallback geo when inference_geo is omitted from a request. Individual requests can override this by setting inference_geo explicitly.

    These settings can be configured through the Console or the Admin API under the data_residency field.

    Workspace geo

    Workspace geo is set when you create a workspace and can't be changed afterwards. Currently, "us" is the only available workspace geo.

    To set workspace geo, create a new workspace in the Console:

    1. Go to Settings > Workspaces.
    2. Create a new workspace.
    3. Select the workspace geo.

    Pricing

    Data residency pricing varies by model generation:

    • Claude Opus 4.6 and newer: 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).
    • Global routing (inference_geo: "global" or omitted): Standard pricing applies.
    • Older models: Existing pricing is unchanged regardless of inference_geo settings.

    This pricing applies to the Claude API (1P) only. Third-party platforms (AWS Bedrock, Google Vertex AI, Microsoft Foundry) have their own regional pricing. See the pricing page for details.

    If you use Priority Tier, the 1.1x multiplier for US-only inference also affects how tokens are counted against your Priority Tier capacity. Each token consumed with inference_geo: "us" draws down 1.1 tokens from your committed TPM, consistent with how other pricing multipliers (prompt caching, long context) affect burndown rates.

    Batch API support

    The inference_geo parameter is supported on the Batch API. Each request in a batch can specify its own inference_geo value.

    Migration from legacy opt-outs

    If your organization previously opted out of global routing to keep inference in the US, your workspace has been automatically configured with allowed_inference_geos: ["us"] and default_inference_geo: "us". No code changes are required. Your existing data residency requirements continue to be enforced through the new geo controls.

    What changed

    The legacy opt-out was an organization-level setting that restricted all requests to US-based infrastructure. The new data residency controls replace this with two mechanisms:

    • Per-request control: The inference_geo parameter lets you specify "us" or "global" on each API call, giving you request-level flexibility.
    • Workspace controls: The default_inference_geo and allowed_inference_geos settings in the Console let you enforce geo policies across all keys in a workspace.

    What happened to your workspace

    Your workspace was migrated automatically:

    Legacy settingNew equivalent
    Global routing opt-out (US only)allowed_inference_geos: ["us"], default_inference_geo: "us"

    All API requests using keys from your workspace continue to run on US-based infrastructure. No action is needed to maintain your current behavior.

    If you want to use global routing

    If your data residency requirements have changed and you want to take advantage of global routing for better performance and availability, update your workspace's inference geo settings to include "global" in the allowed geos and set default_inference_geo to "global". See Workspace-level restrictions for details.

    Pricing impact

    Legacy models are unaffected by this migration. For current pricing on newer models, see Pricing.

    Current limitations

    • Shared rate limits: Rate limits are shared across all geos.
    • Inference geo: Only "us" and "global" are available at launch. Additional regions will be added over time.
    • Workspace geo: Only "us" is currently available. Workspace geo can't be changed after workspace creation.

    Next steps

    Pricing

    View data residency pricing details.

    Workspaces

    Learn about workspace configuration.

    Usage and Cost API

    Track usage and costs by data residency.

    Was this page helpful?

    • Inference geo
    • API usage
    • Response
    • Model availability
    • Workspace-level restrictions
    • Workspace geo
    • Pricing
    • Batch API support
    • Migration from legacy opt-outs
    • What changed
    • What happened to your workspace
    • If you want to use global routing
    • Pricing impact
    • Current limitations
    • Next steps