Claude Models on Google Cloud (Anthropic managed) vs. Vertex AI: IAM ersetzt den API-Key, an drei Stellen greift es nicht

Am 22. Oktober hat Anthropic Claude Models on Google Cloud (Anthropic managed) gestartet. Das ist die Claude API selbst, betrieben von Anthropic, erreichbar über claude.googleapis.com, autorisiert über Google Cloud IAM und abgerechnet über den Google Cloud Marketplace. Der ältere Weg, Claude aus einem Google-Projekt aufzurufen, bisher als Vertex AI bekannt, heißt in Anthropics Doku jetzt Claude Models on Google Cloud (Google managed). Sein SDK-Client heißt weiterhin AnthropicVertex.

Beide können dasselbe Projekt, dieselben Google-Credentials und dieselbe Rechnung nutzen. Sie unterscheiden sich in der API-Oberfläche, den IAM-Rollen, den Features und darin, ob es überhaupt eine Anthropic-Organisation gibt. Das Versprechen der neuen Variante: IAM ersetzt den API-Key. Das stimmt, und an drei Stellen reicht es weniger weit, als es klingt: bei einem Gateway davor, bei der Nur-Lese-Rolle und bei Agents, die schon laufen. Ich habe den neuen AnthropicGoogleCloud-Client aus dem Python-SDK gegen einen Mock-Transport laufen lassen, mit einem Fake-Token und ohne dass irgendetwas rausging, um zu sehen, was er tatsächlich sendet. Der Befund zum Gateway stammt aus diesem Lauf, die anderen beiden direkt aus der IAM-Referenz.

Was ist Claude Models on Google Cloud (Anthropic managed), und worin unterscheidet es sich von Vertex AI?

Es ist die First-Party-Claude-API hinter einer Google-Eingangstür, während Vertex AI Googles eigenes Serving von Claude über die Prediction-Endpunkte der Agent Platform ist. Auf der Anthropic-managed-Seite sieht ein Request aus wie jeder Claude-API-Request: model im Body, anthropic-version als Header, "stream": true fürs Streaming, dieselben Modell-IDs wie bei api.anthropic.com. Auf der Google-managed-Seite steht model in der URL, anthropic_version im Body, Streaming hat einen eigenen Endpunkt :streamRawPredict, und Modelle vor Claude 4.6 setzen ein @ vor das Snapshot-Datum.

Die Form des Requests ist der kleine Unterschied. Der große sind die Features. Die Google-managed-Doku führt als nicht unterstützt: Files API, Code Execution, Web Fetch, das Advisor-Tool, Agent Skills, den MCP-Connector, Message Batches, die Models API, serverseitiges Fallback und Claude Managed Agents. Die Anthropic-managed-Seite führt all das als funktionsfähig. Ihre eigenen Ausnahmen sind MCP-Tunnels, Memory Stores auf selbst gehosteten Environments und die vorgefertigten selbst gehosteten Sandbox-Worker im ant-CLI und in den SDKs für Python, TypeScript und Go. Statt dieser Worker schreibst du einen eigenen gegen die Environments-Work-Endpunkte.

Zwei weitere Dinge kippen, wenn du Vertex verlässt. Der Datenverarbeiter: Bei Google managed ist es Google, bei Anthropic managed ist es Anthropic, wie bei api.anthropic.com, und laut Doku verarbeiten „einige unterstützende Dienste, etwa Anthropics Trust-and-Safety-Systeme, Daten außerhalb von Google Cloud“. Und die Limits: Auf der Vertex-Seite setzt Google Quotas, bei der neuen Variante setzt Anthropic Rate Limits. Die Nutzung misst Anthropic in Claude Consumption Units zu je 0,01 $, sie erscheint auf der Google-Rechnung und wird auf ein Google-Cloud-Spend-Commitment angerechnet, wie andere Marketplace-Käufe auch.

Für ein Team auf Vertex ist der Umzug also vor allem eine Feature-Freischaltung. Für ein Team, das schon auf api.anthropic.com sitzt, bleibt der Verarbeiter derselbe. Es ändern sich Zugriff, Abrechnung und die Organisation, in der du arbeitest.

Was legt die Einrichtung von Claude Models on Google Cloud (Anthropic managed) an?

Eine neue Anthropic-Organisation, gebunden an dieses Google-Cloud-Projekt, getrennt von jeder Organisation, die deine Firma schon hat, Claude Enterprise eingeschlossen. Eine bestehende Organisation lässt sich nicht umwandeln. Die Einrichtung hat vier Schritte: das Marketplace-Listing abonnieren, zwei Services aktivieren, auf Activate klicken und das Organisationsformular über einen per E-Mail geschickten Link ausfüllen, dann die Claude Console aus der Google Cloud Console heraus öffnen.

gcloud services enable claude.googleapis.com \
  anthropic-managed-claude.cloudpartnerservices.goog \
  --project=my-project-id

claude.googleapis.com stellt die API bereit und definiert die IAM-Berechtigungen, der zweite Service ordnet die Nutzung deinem Abo zu. Das Aktivieren des ersten legt im Projekt einen Service-Agent an, und die Doku warnt: Wer dessen Rollenbindungen entfernt, stoppt den Service. Das verdient einen Kommentar in jedem Terraform-Code oder jeder Org-Policy, die unerwartete Bindings aufräumt.

Wenn du von api.anthropic.com kommst, beginnt alles bei null. API-Keys, Workspaces und Console-Einstellungen werden nicht übernommen, Files, Skills, Batches und Managed-Agents-Ressourcen bleiben in der alten Organisation. Auch eine Zero-Data-Retention-Vereinbarung (ZDR) einer anderen Organisation geht nicht mit, hier gibt es sie auf Anfrage. Einen verhandelten Rabatt musst du vor dem Start mit deinem Account-Ansprechpartner klären, denn „Rabatte lassen sich nicht rückwirkend auf vergangene Nutzung anwenden“. Die beiden Organisationen sind unabhängig und können parallel Traffic bedienen, der Umstieg kann also Workload für Workload passieren.

In die neue Console meldet sich niemand mit einer E-Mail-Adresse an. Google Cloud prüft IAM und leitet auf platform.claude.com weiter, und nur roles/claude.admin kann sie öffnen. Einmal muss das jemand tun, um die Workspace-ID zu kopieren, die jeder Aufrufer braucht.

Was sendet der SDK-Client AnthropicGoogleCloud?

Ein Google-Access-Token als Authorization: Bearer, die Standard-API-Version des SDK und eine URL, die Projekt und Workspace enthält. Mit gesetztem ANTHROPIC_API_KEY und ANTHROPIC_BASE_URL, wie auf jeder Maschine, die schon mit der First-Party-API spricht, hat der Client beide ignoriert. Diesen Request hat der Mock-Transport für messages.create aufgezeichnet:

POST https://claude.googleapis.com/v1/projects/my-project-id/locations/global/workspaces/wrkspc_01FAKE/invoke/v1/messages
user-agent: AnthropicGoogleCloud/Python 2.3.0
anthropic-version: 2026-10-21
authorization: Bearer ya29.FAKE-token

Kein x-api-key und kein Header anthropic-workspace-id, den ein Request laut Doku nicht mitschicken darf, weil der Workspace im Pfad steht. Routen auf Organisationsebene, in dieser SDK-Version /v1/organizations/ und /v1/user_profiles, gehen an eine Basis ohne Workspace:

GET https://claude.googleapis.com/v1/projects/my-project-id/locations/global/claudeOrganization/invoke/v1/organizations/me

Drei Verhaltensweisen solltest du vor dem ersten Deploy kennen.

Der Client lässt sich ohne Credentials bauen und scheitert erst beim ersten Request. Ohne Application Default Credentials auf der Maschine ließ sich AnthropicGoogleCloud(project=..., workspace_id=...) problemlos konstruieren und hat seine Basis-URL ausgegeben. Der DefaultCredentialsError kam erst bei messages.create. Ein Health-Check, der nur den Client instanziiert, besteht auf einem Host, der keinen einzigen Aufruf schafft.

Eine fehlende Workspace-ID ist ebenfalls ein Fehler zur Request-Zeit. Ohne sie ließ sich der Client bauen, und der Message-Aufruf warf das hier:

AnthropicError: No workspace ID found. Set the `workspace_id` argument or the `ANTHROPIC_GOOGLE_CLOUD_WORKSPACE_ID` environment variable.

Die Organisationsroute wurde trotzdem gebaut und an den Mock übergeben, sie braucht keinen Workspace.

Das Projekt fällt auf GOOGLE_CLOUD_PROJECT zurück. Ohne gesetztes ANTHROPIC_GOOGLE_CLOUD_PROJECT hat der Client GOOGLE_CLOUD_PROJECT genommen und die URL für dieses Projekt gebaut. Steht in der Variable ein anderes Projekt, landen die Aufrufe dort. Setz die Anthropic-spezifische Variable explizit.

Wie ziehst du Code von AnthropicVertex auf AnthropicGoogleCloud um?

Zuerst Account und Zugriff, dann ein einzeiliger Client-Tausch, dann zwei Änderungen, die das Verhalten verändern. Der neue SDK-Client ist in Beta. Nach der Einrichtung oben vergibst du roles/claude.user auf dem Projekt an jede Identität, die die API aufruft (Agent-Platform-Rollen wie roles/aiplatform.user gelten hier nicht), setzt ANTHROPIC_GOOGLE_CLOUD_PROJECT und ANTHROPIC_GOOGLE_CLOUD_WORKSPACE_ID und tauschst den Client. In Python:

pip install -U "anthropic[google_cloud]"

# before: Google managed (Vertex AI)
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project-id", region="global")
 
# after: Anthropic managed, project and workspace from the environment
from anthropic import AnthropicGoogleCloud
client = AnthropicGoogleCloud()

In TypeScript heißt das Paket @anthropic-ai/google-cloud-sdk, in Go ersetzt googlecloud.NewClient() das vertex.WithGoogleAuth(), und in Java ersetzt GoogleCloudBackend das VertexBackend.

Die beiden Änderungen, die es in sich haben:

• Modell-IDs. Bei Modellen vor Claude 4.6 ersetzt du das @ durch einen Bindestrich: Aus claude-haiku-4-5@20251001 wird claude-haiku-4-5-20251001.
• Datenresidenz. Wenn du für die Residenz einen regionalen oder Multi-Region-Endpunkt von Vertex gewählt hast, gibt es hier keine passende URL, die Location ist global. Die Doku bietet inference_geo: "us" pro Request für Inferenz nur in den USA an, nur bei Claude 4.6 und neueren Modellen und zum 1,1-fachen Standardpreis. Eine EU- oder Einzelregion-Anforderung braucht vor dem Umzug eine eigene Prüfung, und ein Workload auf Haiku 4.5 kann den Parameter gar nicht nutzen.

Die API-Version verdient einen Satz, auch wenn sie nicht durch den Abschied von Vertex entsteht. SDK 2.3.0 schickt aus beiden Clients standardmäßig 2026-10-21, also bringt dich das Upgrade, das du für den Tausch machst, dorthin. Unter dieser Version liefern temperature, top_p und top_k einen 400er, und das SDK nimmt sie nicht mehr als Argumente an. Streich sie, oder lass einen Request auf der alten Version, wie im Walkthrough zur API-Version 2026-10-21.

Das ant-CLI braucht mehr Sorgfalt als das SDK. Aktualisiere es zuerst: Laut Doku ignoriert eine Version ohne Unterstützung die Variablen ANTHROPIC_GOOGLE_CLOUD_* und schickt den Request entweder mit irgendeinem anderen gefundenen Credential an die Claude API oder scheitert. Selbst ein aktuelles CLI bevorzugt ein First-Party-Credential, wenn eins vorhanden ist. Entferne also API-Keys, Auth-Tokens, ANTHROPIC_PROFILE und die Federation-Variablen, und lass ANTHROPIC_WORKSPACE_ID ungesetzt, sonst schickt es den verbotenen Workspace-Header. Mach dann vor dem Produktions-Traffic einen kleinen echten Request im Zielprojekt und Ziel-Workspace und prüf die Rate Limits. Die kommen jetzt von Anthropic, nicht aus deiner Google-Quota.

Kann ein LLM-Gateway vor Claude Models on Google Cloud sitzen?

Ja, und es erbt mit dem Token auch das Routing. Die Client-Option dafür heißt skip_auth, gedacht für „einen Proxy, der das Token für dich anhängt“: Der Client erzeugt dann kein Google-Token. Ein Header, den du selbst setzt, etwa ein Token fürs Gateway, geht weiterhin raus. Mit einem Token-Provider oder einem Credentials-Objekt lässt sich die Option nicht kombinieren:

ValueError: `skip_auth` is mutually exclusive with `token_provider` and `credentials`; `skip_auth` disables authentication entirely.

Was die Doku nicht ausdrücklich sagt, ist die URL. Den Client auf ein Gateway zu richten heißt, base_url (oder ANTHROPIC_GOOGLE_CLOUD_BASE_URL) zu setzen, und eine explizite Basis-URL schaltet das eigene Routing des Clients ab. Mit skip_auth=True, gesetzter Workspace-ID und base_url="http://gw.internal/claude" hat der Mock-Transport aufgezeichnet:

POST http://gw.internal/claude/v1/messages
GET  http://gw.internal/claude/v1/organizations/me

Kein Projekt, kein Workspace, und beide Routentypen auf einer Basis. Die an den Client übergebene Workspace-ID ging nirgendwohin. Ein Gateway mit einer kurzen Basis wie dieser muss die URL von claude.googleapis.com selbst neu aufbauen: Projekt und Workspace pro Aufrufer wählen und Organisationsrouten stattdessen an die Basis claudeOrganization schicken. Für ein Gateway mit nur einem Workspace kannst du ein vollständiges Präfix aus Projekt und Workspace in base_url einbauen, dann landen Organisationsrouten aber unter dem Workspace-Pfad und brauchen eine eigene Einstellung. So oder so ist das Gateway kein Header-Rewrite mehr. Es ist jetzt eine Routing-Tabelle.

Das Token, das es anhängt, hat noch eine zweite Wirkung. Ruft das Gateway upstream mit seinem eigenen Service-Account auf, ist dieser Account die Identität, die IAM prüft, und die Identität in allen Audit-Einträgen, die du aktiviert hast. Welcher Entwickler einen Request geschickt hat, weiß nur das Gateway. Es muss seine Aufrufer also mit einem eigenen Mechanismus authentifizieren, entscheiden, welchen Workspace jeder erreichen darf, und das protokollieren, bevor es das Google-Token einsetzt.

Vergleich das mit dem Header-Wechsel in API-Version 2026-10-21, bei dem ein Gateway das Credential in X-Api-Key oder Authorization finden musste. Upstream fällt diese Frage hier weg: Es gibt keinen Key, und x-api-key darf nicht mitgeschickt werden. Downstream gehört sie wieder dir. Wenn dasselbe Gateway auch api.anthropic.com bedient oder ältere Clients versorgt, nimmt es weiterhin an, was die schicken, und muss es entfernen, bevor es das Google-Token anhängt. Was sonst noch unverändert durchgehen muss, steht im Walkthrough zum Claude-Code-Gateway. Laut Doku funktionieren anthropic-version und anthropic-beta hier wie bei der Claude API.

Wer kann mit den IAM-Rollen von Claude Models on Google Cloud was lesen?

Mehr, als „nur lesen“ vermuten lässt. Es gibt drei vordefinierte Rollen, vergeben auf dem Projekt: roles/claude.viewer für jedes get und list auf Workspace-Ressourcen, roles/claude.user für alles auf Workspace-Ressourcen einschließlich Nachrichten senden, und roles/claude.admin für Routen auf Organisationsebene und die Console.

Ein Workspace ist keine Zugriffsgrenze. Rollen werden auf dem Projekt vergeben, also gilt eine Rolle für jeden Workspace darin. Die Antwort der Doku für Teams, die getrennten Zugriff brauchen: ein Google-Cloud-Projekt pro Team, jedes mit eigener Anthropic-Organisation und eigenem Marketplace-Setup.

Der Viewer liest Inhalte, nicht nur Metadaten. Die IAM-Referenz ist eindeutig: files.get deckt das Herunterladen eines Dateiinhalts ab, messageBatches.get das Herunterladen von Batch-Ergebnissen, und sessions.get die Event-Historie und den Stream einer Session. Also kann „roles/claude.viewer die vollständige Event-Historie jeder Session lesen“. Memory-Inhalte und Inhalte von Skill-Versionen sind genauso lesbar. Vault-Credentials lassen sich auflisten, ihre geheimen Felder werden aber nie zurückgegeben. Ein Viewer kann keine Nachricht senden, aber er kann die gespeicherte Historie jeder Managed-Agents-Session im Projekt lesen.

Dann der Logging-Standard. Cloud Audit Logs erfasst diesen Service unter claude.googleapis.com. Die meisten Routen sind Data-Access-Logs, und die sind laut Doku standardmäßig aus: darunter Messages, Files, Batches und die meisten Managed-Agents-Ressourcen. Routen für Encryption Keys und die meisten Vault-Routen sind Admin-Activity-Logs, die immer an sind. Solange Data-Access-Logging für das Projekt nicht aktiviert ist, direkt oder geerbt von einer Ordner- oder Organisations-Policy, hinterlässt ein Viewer, der einen Monat Session-Transkripte liest, keinen Audit-Eintrag. Schalte es ein, bevor du die Viewer-Rolle an jemanden vergibst, den du je auditieren müsstest.

Was passiert mit Claude Managed Agents, wenn du IAM-Zugriff auf Google Cloud entziehst?

Mit allem, was schon läuft, passiert nichts. Der Zugriff wird geprüft, wenn eine Session oder ein Deployment erstellt wird, nicht während es läuft. Eine Session, die eine Identität gestartet hat, der du den Zugriff entziehst, läuft weiter, und ein geplantes Deployment prüft seinen Ersteller nicht bei jedem Lauf neu. Die Anweisung der Doku: Prüf die Sessions und Deployments, die eine Identität erstellt hat, jedes Mal, wenn du einen Nutzer entfernst oder einen Service-Account rotierst.

Die Doku liefert die Regel, nicht das Verfahren. Die Reihenfolge, die ich nehmen würde, damit die Identität während des Aufräumens keine neue Arbeit starten kann:

• Zuerst ihre IAM-Bindung entfernen, und ihren Zugang zu jedem Gateway, das in ihrem Namen aufruft.
• Dann als Admin, der noch Zugriff hat, die geplanten Deployments pausieren, ändern oder archivieren, die sie erstellt hat.
• Jeder ihrer laufenden Sessions ein einzelnes user.interrupt-Event ohne weitere Events schicken, dann die Session archivieren oder löschen, sobald sie idle ist.
• Erneut auflisten und bestätigen, dass nichts, was sie gestartet hat, noch läuft.

Das setzt voraus, dass du weißt, was sie erstellt hat. Bei einer gemeinsamen Gateway-Identität ist „erstellt von“ für alle der Service-Account des Gateways. Führ also selbst Buch darüber, wer welche Session und welches Deployment gestartet hat.

Budgets sind die Ausnahme von „nur bei der Erstellung geprüft“. Ein Session-Budget wird vor jedem Modell-Request durchgesetzt, während die Session läuft, und lässt sich später ändern oder entfernen. Anhängen lässt es sich allerdings nur bei der Erstellung der Session, eine Session ohne Budget bekommt also nachträglich keins. Wenn deine Agents sich selbst verzweigen, wie bei dynamischen Workflows in Managed Agents, setz das Budget bei der Erstellung.

Sollte ein Team auf Vertex AI oder api.anthropic.com zu Claude Models on Google Cloud wechseln?

Wechsel pro Workload, nicht alles auf einmal. Von Vertex AI aus spricht viel dafür bei allem, was ein Feature braucht, das Vertex fehlt: Batches, Files, Skills, der MCP-Connector, Managed Agents. Wenig spricht dafür bei einem schlichten Messages-Workload, der heute funktioniert und von einem regionalen Endpunkt oder von Google als Datenverarbeiter abhängt, denn beides ändert sich.

Von api.anthropic.com aus bekommst du IAM statt Keys und Nutzung, die auf ein Google-Commitment angerechnet wird. Du zahlst mit einer Organisation, die leer startet, einer ZDR-Vereinbarung, die du neu beantragen musst, gespeicherten Ressourcen, die neu angelegt werden müssen, und neuen Rate Limits. Ein Team, das statische Keys schon durch Workload Identity Federation ersetzt hat, gewinnt durch die IAM-Hälfte weniger.

Meine Einschätzung: neue Workloads auf die Anthropic-managed-Seite, die mit Historie bleiben, wo sie sind, und die IAM-Arbeit vor dem Traffic. Data-Access-Logs einschalten, entscheiden, wer wirklich Viewer braucht, und den Offboarding-Schritt für Managed Agents aufschreiben, bevor die erste Person geht.