Was this page helpful?
Diese Funktion ist für Zero Data Retention (ZDR) qualifiziert. Wenn deine Organisation eine ZDR-Vereinbarung hat, werden Daten, die über diese Funktion gesendet werden, nicht gespeichert, nachdem die API-Antwort zurückgegeben wurde.
Mit „data residency" (Datenresidenz)-Kontrollen kannst du verwalten, wo deine Daten verarbeitet und gespeichert werden. Zwei unabhängige Einstellungen steuern dies:
inference_geo oder als Workspace-Standard festgelegt.Claude Managed Agents unterstützt den Parameter inference_geo nicht, berücksichtigt aber die in der Console konfigurierte Workspace geo. Mit selbst gehosteten Sandboxes bleiben die Tool-Ausführung und das Sandbox-Dateisystem auf von dir kontrollierter Infrastruktur.
Der Parameter inference_geo steuert, wo die Modellinferenz für eine bestimmte API-Anfrage ausgeführt wird. Füge ihn zu jedem POST /v1/messages-Aufruf hinzu.
| Wert | Beschreibung |
|---|---|
"global" | Standard. Die Inferenz kann in jeder verfügbaren Region ausgeführt werden, um optimale Leistung und Verfügbarkeit zu erzielen. |
"us" | Die Inferenz wird nur auf US-basierter Infrastruktur ausgeführt. |
Das usage-Objekt in der Antwort enthält ein inference_geo-Feld, das angibt, wo die Inferenz ausgeführt wurde:
{
"usage": {
"input_tokens": 25,
"output_tokens": 150,
"inference_geo": "us"
}
}Der Parameter inference_geo wird von Claude Opus 4.6, Claude Sonnet 4.6 und neueren Modellen unterstützt. Anfragen mit inference_geo an Claude Opus 4.5, Claude Sonnet 4.5, Claude Haiku 4.5 oder ältere Modelle geben einen 400-Fehler zurück.
Der Parameter inference_geo ist über die Claude API (First-Party) und Claude Platform on AWS verfügbar. Bei Amazon Bedrock, Vertex AI und Microsoft Foundry wird die Inferenzregion durch die Endpunkt-URL oder das Inferenzprofil bestimmt, daher ist inference_geo dort nicht anwendbar. Der Parameter inference_geo ist auch nicht über den OpenAI-SDK-Kompatibilitätsendpunkt verfügbar.
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 eine inference_geo angibt, die nicht in dieser Liste enthalten ist, gibt die API einen Fehler zurück.default_inference_geo: Legt die 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.
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:
Claude Platform on AWS: Die Workspace geo ist nicht konfigurierbar. Workspaces werden über die AWS Console bereitgestellt, und die Workspaces-Seite in der Claude Console ist schreibgeschützt. Claude Managed Agents-Sitzungen auf dieser Plattform laufen mit einer effektiven Workspace geo von "us", was derzeit die einzige verfügbare Workspace geo ist. Siehe Claude Platform on AWS für plattformspezifische Überlegungen zur Datenresidenz.
Die Preise für Datenresidenz variieren je nach Modellgeneration:
inference_geo: "us") wird mit dem 1,1-fachen des Standardtarifs über alle Token-Preiskategorien hinweg berechnet (Input-Token, Output-Token, Cache-Schreibvorgänge und Cache-Lesevorgänge).inference_geo: "global"): Es gelten die Standardpreise.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 Claude Platform on AWS. Von Partnern betriebene Plattformen (Bedrock und Vertex AI) haben ihre eigenen regionalen Preise. Siehe Preise für Datenresidenz für Details.
Wenn du Priority Tier verwendest, wirkt sich der 1,1-fache Multiplikator für Inferenz nur in den USA auch darauf aus, wie Token gegen deine Priority-Tier-Kapazität gezählt werden. Jedes mit inference_geo: "us" verbrauchte Token zieht 1,1 Token von deinen zugesagten TPM ab, konsistent damit, wie andere Preismultiplikatoren (wie Prompt-Caching) die Verbrauchsraten beeinflussen.
Der Parameter inference_geo wird von der Batch API unterstützt. Jede Anfrage in einem Batch kann ihren eigenen inference_geo-Wert angeben.
Wenn deine Organisation zuvor das globale Routing deaktiviert 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 durch die neuen Geo-Kontrollen durchgesetzt.
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:
inference_geo kannst du bei jedem API-Aufruf "us" oder "global" angeben, was dir Flexibilität auf Anfrageebene gibt.default_inference_geo und allowed_inference_geos in der Console kannst du Geo-Richtlinien für alle Keys in einem Workspace durchsetzen.Dein Workspace wurde automatisch migriert:
| Legacy-Einstellung | Neues Äquivalent |
|---|---|
| Opt-out vom globalen Routing (nur USA) | allowed_inference_geos: ["us"], default_inference_geo: "us" |
Alle API-Anfragen, die Keys aus deinem Workspace verwenden, werden weiterhin auf US-basierter Infrastruktur ausgeführt. Es ist keine Aktion erforderlich, um dein aktuelles Verhalten beizubehalten.
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.
Legacy-Modelle sind von dieser Migration nicht betroffen. Aktuelle Preise für neuere Modelle findest du unter Preise.
"us" und "global" sind verfügbar."us" verfügbar. Die Workspace geo kann nach der Workspace-Erstellung nicht mehr geändert werden.client = anthropic.Anthropic()
response = client.messages.create(
model="claude-opus-4-8",
max_tokens=1024,
inference_geo="us",
messages=[
{"role": "user", "content": "Summarize the key points of this document."}
],
)
print(response.content[0].text)
# Prüfe, wo die Inferenz tatsächlich ausgeführt wurde
print(f"Inference geo: {response.usage.inference_geo}")