Claude on Vertex / GCP

Before any code can reach Claude on Vertex, you do a one-time setup in your terminal: install the right library and log in to Google Cloud. These are shell commands (you run them in a terminal, not in Python).

1. pip install "anthropic[vertex]" installs Anthropic's Python library plus the extra Vertex pieces (the [vertex] part). This is what gives you the AnthropicVertex client used later.
2. gcloud auth application-default login opens your browser to sign in to Google. It saves credentials on your machine so your code can authenticate without any key in the code — that saved login is what "ADC" (Application Default Credentials) means.
3. gcloud config set project my-gcp-project tells Google which project (billing + resources bucket) to use. gcloud services enable aiplatform.googleapis.com switches on the Vertex AI service for that project — like flipping the breaker before you use the appliance.

What the output means: Nothing prints a result you keep — these commands just prepare your machine and project. After they succeed, your Python can talk to Vertex.

Try this: Run gcloud config list afterward to confirm your project is set. If a later call fails with a permissions error, it's almost always one of these four steps that was skipped.

This is the whole shape of a Claude call on Vertex — and it's deliberately almost identical to the direct-API call from earlier lessons. Only the first two lines (the client) and the model id are Vertex-specific.

1. from anthropic import AnthropicVertex imports the Vertex flavor of the client. client = AnthropicVertex(region="us-east5", project_id="my-gcp-project") builds it — you pass a Google Cloud region and your project instead of an API key, because the login you did in setup is picked up automatically.
2. client.messages.create(...) is the exact same request method as the direct API. max_tokens caps the reply length; system sets the assistant's role; messages is the conversation (here one user question).
3. model="claude-3-5-sonnet-v2@20241022" uses Vertex's naming style — note the @ and date version suffix. That naming is the main thing that differs from the direct API's model ids.
4. resp.content[0].text pulls the text out of the reply. The reply's content is a list of blocks, so [0] grabs the first block and .text its words.

What the output means: Prints Claude's one-sentence answer describing Vertex AI. (This block is marked "needs GCP creds" because a real network call to Google requires the login from step 2.)

Try this: Compare this to the first-call code in the Anthropic-API lesson: swap Anthropic() for AnthropicVertex(region=..., project_id=...) and change the model id — everything else is the same. That's the whole point of this chapter.

This tiny program (which runs offline — no cloud needed) proves the chapter's big idea: the three doors differ in only three things — the client you build, the auth you use, and the model id. Everything else about a request is identical.

1. client_config(door) is a function returning a small dictionary of facts for one door. The { ... }[door] pattern builds a lookup table of all three doors and then immediately picks the one named by door.
2. Each entry lists that door's client (Anthropic(), boto3, or AnthropicVertex()), its auth method (API key / IAM role / gcloud ADC), and its model id string. Notice the model ids differ in format but name the same models.
3. for door in ["api", "bedrock", "vertex"]: loops over all three and prints a lined-up row for each, using f-string alignment (:8, :26 pad to fixed widths so the columns line up).
4. The last print states the punchline in words: the messages shape — how you phrase the actual request — is identical across all three.

What the output means: Three aligned rows (one per door) showing client / auth / model, then the line messages shape is IDENTICAL across all three — exactly the console output shown just below the code.

Try this: Add a fourth fictional door to the dictionary and to the loop list, then re-run. The table grows automatically — because the loop, not repeated code, does the printing.

Streaming shows Claude's reply as it's typed, chunk by chunk, instead of waiting for the whole answer. The key lesson here: streaming on Vertex uses the exact same code as the direct API — only the client and model id are Vertex-specific.

1. The first two lines build the same AnthropicVertex client as before (region + project, no key).
2. with client.messages.stream(...) as stream: opens a live streaming connection. The with block guarantees it closes cleanly when finished. This is the identical method name used on the direct API.
3. for text in stream.text_stream: receives small text chunks as Claude produces them. print(text, end="", flush=True) prints each chunk immediately with no line break, so words appear to flow in real time. The final bare print() just adds a newline at the end.

What the output means: You'd watch "Count to five slowly." get answered progressively, the digits appearing one after another rather than all at once. (Marked "needs GCP creds" — a real stream requires the Vertex login.)

Try this: Put this side by side with the streaming code from the Anthropic-API lesson. Only the client = ... line and the model id changed — the streaming loop is the same, which is exactly why moving providers is easy.

This little decision function (it runs offline) encodes how a team actually picks a front door. It reads top to bottom and returns the first rule that matches — so order matters.

1. The parameters describe your situation: are you already on_aws / on_gcp, do you just want the wants_simplest path, and is there a data_residency rule (data must stay in a specific cloud).
2. Rule 1: if data must stay in AWS, or you're on AWS and not GCP, choose Bedrock. Rule 2: the mirror image for Google → Vertex. A return stops the function immediately, so a matched earlier rule wins.
3. If no cloud constraint applies, if wants_simplest: return falls back to the direct api — and so does the final line, making the direct API the default.
4. The three print(choose_door(...)) calls at the bottom test three situations: an AWS shop, a GCP shop, and someone who just wants the simplest option.

What the output means: Prints bedrock, then vertex, then api (direct) — matching the console output shown below the code, one line per test case.

Try this: Add a call with both on_aws=True and on_gcp=True and no residency rule — which door wins? Trace the rules top to bottom to predict it, then run to confirm. That's how you reason about any decision function.