Datenresidenz

Mit den Kontrollen zur „data residency" (Datenresidenz) kannst du verwalten, wo deine Daten verarbeitet und gespeichert werden. Zwei unabhängige Einstellungen regeln dies:

• Inference geo: Steuert, wo die Modell-Inferenz ausgeführt wird, auf Basis einzelner Anfragen. Wird über den API-Parameter inference_geo oder als Workspace-Standard festgelegt.
• Workspace geo: Steuert, wo Daten im Ruhezustand gespeichert werden und wo die Endpoint-Verarbeitung (wie Bild-Transkodierung und Code-Ausführung) stattfindet. Wird auf Workspace-Ebene in der Claude Console konfiguriert.



Inference geo

Der Parameter inference_geo steuert, wo die Modell-Inferenz für eine bestimmte API-Anfrage ausgeführt wird. Füge ihn zu jedem POST /v1/messages-Aufruf hinzu.



API-Nutzung

client = anthropic.Anthropic()

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."}
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)
# Prüfe, wo die Inferenz tatsächlich ausgeführt wurde
print(f"Inference geo: {response.usage.inference_geo}")



Antwort

Das usage-Objekt der Antwort enthält ein Feld inference_geo, das angibt, wo die Inferenz ausgeführt wurde:

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



Modellverfügbarkeit

Der Parameter inference_geo wird auf Claude 4.6 und neueren Modellen unterstützt. Anfragen mit inference_geo auf Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5 oder älteren Modellen geben einen 400-Fehler zurück.



Einschränkungen auf Workspace-Ebene

Workspace-Einstellungen unterstützen auch die Einschränkung, welche Inference geos verfügbar sind:

• allowed_inference_geos: Schränkt ein, welche Geos ein Workspace verwenden kann. Wenn eine Anfrage ein inference_geo angibt, das nicht in dieser Liste enthalten ist, gibt die API einen Fehler zurück.
• default_inference_geo: Legt das Fallback-Geo fest, wenn inference_geo in einer Anfrage weggelassen wird. Einzelne Anfragen können dies überschreiben, indem sie inference_geo explizit setzen.

Diese Einstellungen können über die Console oder die Admin API unter dem Feld data_residency konfiguriert werden.



Workspace geo

Die Workspace geo wird beim Erstellen eines Workspace festgelegt und kann danach nicht mehr geändert werden. Derzeit ist "us" die einzige verfügbare Workspace geo.

Um die Workspace geo festzulegen, erstelle einen neuen Workspace in der Console:

1. Gehe zu Settings > Workspaces.
2. Erstelle einen neuen Workspace.
3. Wähle die Workspace geo aus.



Preise

Die Preise für Datenresidenz variieren je nach Modellgeneration:

• Claude 4.6 und neuere Modelle: Nur-US-Inferenz (inference_geo: "us") wird mit dem 1,1-fachen des Standardtarifs über alle Token-Preiskategorien hinweg berechnet (input tokens, output tokens, Cache-Schreibvorgänge und Cache-Lesevorgänge).
• Globales Routing (inference_geo: "global"): Es gelten die Standardpreise.
• Ältere Modelle: Unterstützen inference_geo nicht (siehe Modellverfügbarkeit); es gelten die Standardpreise. Anfragen, die den Parameter enthalten, geben einen 400-Fehler zurück.

Diese Preise gelten für die Claude API (First-Party) und die Claude Platform on AWS. Auf Claude in Microsoft Foundry gilt derselbe 1,1-fache Multiplikator für auf Azure gehostete Deployments, die den Deployment-Typ „US Data Zone Standard" verwenden. Von Partnern betriebene Plattformen (Bedrock und Google Cloud) haben ihre eigenen regionalen Preise. Siehe Preise für Datenresidenz für Details.



Batch-API-Unterstützung

Der Parameter inference_geo wird auf der Batch API unterstützt. Jede Anfrage in einem Batch kann ihren eigenen inference_geo-Wert angeben.



Migration von Legacy-Opt-outs

Wenn deine Organisation sich zuvor vom globalen Routing abgemeldet hat, um die Inferenz in den USA zu halten, wurde dein Workspace automatisch mit allowed_inference_geos: ["us"] und default_inference_geo: "us" konfiguriert. Es sind keine Code-Änderungen erforderlich. Deine bestehenden Anforderungen an die Datenresidenz werden weiterhin über die neuen Geo-Kontrollen durchgesetzt.



Was sich geändert hat

Das Legacy-Opt-out war eine Einstellung auf Organisationsebene, die alle Anfragen auf US-basierte Infrastruktur beschränkte. Die neuen Datenresidenz-Kontrollen ersetzen dies durch zwei Mechanismen:

• Kontrolle pro Anfrage: Mit dem Parameter inference_geo kannst du bei jedem API-Aufruf "us" oder "global" angeben, was dir Flexibilität auf Anfrageebene gibt.
• Workspace-Kontrollen: Mit den Einstellungen default_inference_geo und allowed_inference_geos in der Console kannst du Geo-Richtlinien für alle Keys in einem Workspace durchsetzen.



Was mit deinem Workspace passiert ist

Dein Workspace wurde automatisch migriert:

Alle API-Anfragen, die Keys aus deinem Workspace verwenden, laufen weiterhin auf US-basierter Infrastruktur. Es ist keine Aktion erforderlich, um dein aktuelles Verhalten beizubehalten.



Wenn du globales Routing verwenden möchtest

Wenn sich deine Anforderungen an die Datenresidenz geändert haben und du globales Routing für bessere Leistung und Verfügbarkeit nutzen möchtest, aktualisiere die Inference-geo-Einstellungen deines Workspace, um "global" in die erlaubten Geos aufzunehmen, und setze default_inference_geo auf "global". Siehe Einschränkungen auf Workspace-Ebene für Details.



Auswirkungen auf die Preise

Legacy-Modelle sind von dieser Migration nicht betroffen. Aktuelle Preise für neuere Modelle findest du unter Preise.



Aktuelle Einschränkungen

• Geteilte Ratenlimits: Ratenlimits werden über alle Geos hinweg geteilt.
• Inference geo: Nur "us" und "global" sind verfügbar.
• Workspace geo: Derzeit ist nur "us" verfügbar. Die Workspace geo kann nach der Erstellung des Workspace nicht mehr geändert werden.



Nächste Schritte