Identify the route before changing credentials
Anthropic's October 22 release note introduces Claude Models on Google Cloud (Anthropic managed): Anthropic operates the Claude API, Google Cloud IAM controls access, and Google Cloud Marketplace handles billing. For developers, the immediate decision is which integration you are actually changing. A Google Cloud project name alone does not identify the API route.
The official comparison distinguishes the Anthropic-managed host, claude.googleapis.com, and client, AnthropicGoogleCloud, from the Google-managed Agent Platform prediction API and AnthropicVertex. Direct calls to api.anthropic.com with an API key are a third route. Look at a request URL and the client constructor in your application before choosing a migration task.
Write those two observations into your change record. For example, a service constructed with AnthropicVertex should receive a route migration review; a service already using AnthropicGoogleCloud may instead need an IAM or billing investigation. Keep the general integration material in the Claude API guide beside that record. This launch is a reason to reassess the access boundary, rather than a reason to replace a working integration without a measured benefit.
Project access is broader than a workspace label
The IAM reference defines three predefined roles: roles/claude.viewer covers workspace read operations; roles/claude.user adds workspace operations, including sending messages and counting tokens; roles/claude.admin adds organization permissions. Roles are granted on the Google Cloud project. A viewer cannot send a message: the documented permission is messages.create, held by the user and admin roles.
Workspace selection is not a narrower IAM grant. The setup documentation says a project role applies across that project's workspaces and recommends separate projects when teams need separate access. Use that distinction in the design review: two workspace names can organize a team's resources, but they do not establish the separate project access boundary described here.
For the pilot, choose a disposable project and name the team allowed to use it. Record the project ID, the workspace ID, the application identity and the person responsible for the subscription. Review the permissions required by your actual workload before granting an admin role as a troubleshooting shortcut. In particular, a basic Messages request should be evaluated against the documented user permission, rather than gaining organization administration simply to make an error disappear.
Pin project, workspace and authentication together
The documented workspace base URL is https://claude.googleapis.com/v1/projects/{project}/locations/global/workspaces/{workspace}/invoke; append /v1/messages for Messages. Authentication uses a Google OAuth bearer token with the cloud-platform scope. The workspace is in the URL, so omit anthropic-workspace-id; an Anthropic API key does not authenticate this route. The location value global does not establish where inference runs. These details come from the request and authentication guide.
The guide provides AnthropicGoogleCloud support in Python, TypeScript, C#, Go, Java, PHP and Ruby. For a Python pilot, install the documented anthropic[google_cloud] package and supply the intended project and workspace explicitly. Save the installed version with the test record so another developer can reproduce the same client choice. Keep the first request small and synthetic; do not use a production customer prompt to establish whether authentication works.
The search order in Google's ADC documentation shows why changing the active shell account is insufficient evidence of the application's identity. ADC checks the file named by GOOGLE_APPLICATION_CREDENTIALS, then local credentials created with gcloud auth application-default login, then an attached service account. Inspect that resolution path in each test environment. Record the credential source and principal without copying access tokens, private keys or credential JSON into the report.
Propose a permitted and denied identity test
The following is a proposed acceptance test, not an executed result. It requires your own subscription, project and identities. Use two separate test identities in isolated credential environments; leave production roles in place. Give the permitted identity the reviewed roles/claude.user grant on the pilot project. For the denied identity, verify that its effective permissions do not include messages.create, including through inherited grants. A viewer grant can support the read-versus-write comparison, but inspect the rest of the identity's access too.
| Case | Proposed action | Evidence to collect |
|---|---|---|
| Permitted caller | Send one synthetic Messages request using the pinned project, workspace and reviewed client. | Principal, client version, sanitized URL, HTTP status, model and usage fields; retain a request ID when supplied. |
| Denied caller | Send the same request under the identity without the required permission. | Principal, effective permission review and HTTP status. The IAM reference specifies HTTP 403 for a missing required permission. |
| Credential isolation | Repeat the denied case in a fresh environment with its credential source recorded. | Evidence that the permitted caller's ADC or another credential did not supply the request. |
Hold the request body, project, workspace and model constant between callers. Change the identity alone. If the denied request succeeds, stop the pilot and investigate the resolved credential and effective permissions before changing application code. If both requests fail, do not call that proof of isolation: check account activation, service setup and the actual error first. An unavailable model or an invalid request is a different failure from the missing-permission response this test intends to observe.
Close the billing check before a traffic cutover
The billing section places this route's charges on the Google Cloud bill through Marketplace. Before executing the pilot, have the billing owner confirm the subscription, billing account and project mapping. Record the expected reporting destination and compare it with the test's usage evidence when reporting becomes available. Treat an absent charge immediately after a request as an unresolved observation, rather than a zero-cost result.
Do not carry a price assumption or negotiated discount from a different integration into this change record. Ask the account owner to check the applicable offer before approving volume. The AI cost modeling guide can help estimate the workload; this access test establishes neither a discounted rate nor a production budget. Keep those decisions separate in the approval record.
Proceed to a bounded integration pilot when the permitted request, denied request, credential identity and billing destination have evidence an owner can review. Keep rollback at the application routing layer: preserve the existing configuration until the new route's behavior has been accepted. This gives you a concrete decision about the October 22 launch without claiming that a documentation review has verified your production access, data residency or bill.
FAQ
Is Claude on Google Cloud the same as the Google-managed offering?
No. The Anthropic-managed offering uses the Claude API through claude.googleapis.com and the AnthropicGoogleCloud client. The Google-managed offering uses Agent Platform prediction endpoints and the AnthropicVertex client.
Does a workspace isolate IAM access within one project?
No. IAM roles are granted on the project and apply across its workspaces. Anthropic recommends separate Google Cloud projects when teams need separate access.
Which credentials does the Anthropic-managed route use?
It uses a Google OAuth access token in the Authorization: Bearer header. The SDK can resolve credentials through Application Default Credentials. An Anthropic API key is not the credential for this route.
Where is Anthropic-managed Claude usage billed?
Usage is billed through Google Cloud Marketplace and appears on the Google Cloud bill. Check the subscription and billing account before sending a test request.