A large share of enterprise Claude usage is not conversational at all. It is glue: a support ticket arrives and needs a triage label; a file lands in a bucket and needs a summary; a webhook fires and needs a drafted reply. Cloud Functions — Google's function-as-a-service offering, whose current generation runs on Cloud Run infrastructure — lets you attach a few dozen lines of Python to exactly those events and call Claude on Vertex AI, with no server, container registry, or deployment pipeline of your own to maintain.
Two trigger styles, one pattern
HTTP triggers give the function a URL. Good for webhooks from SaaS tools, internal form handlers, or quick integrations where the caller waits for the answer. Keep the caller's timeout in mind: Claude responses take seconds, so either budget for that or acknowledge fast and finish asynchronously.
Pub/Sub triggers subscribe the function to a message topic. This is the better default for anything bursty or non-interactive: producers publish events, and each message invokes the function independently. Failures can be retried by the messaging layer rather than by every producer, and a traffic spike becomes a queue instead of an outage.
Either way, the Claude call inside is identical to any other Vertex usage:
import base64, functions_framework
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-project", region="global")
@functions_framework.cloud_event
def on_ticket(event):
text = base64.b64decode(event.data["message"]["data"]).decode()
msg = client.messages.create(
model="claude-haiku-4-5",
max_tokens=512,
messages=[{"role": "user", "content": f"Classify this ticket:\n{text}"}],
)
print(msg.content[0].text) # route the label onward from here
Creating the client outside the handler lets warm instances reuse it across invocations. For a one-line-out classification task like this, a fast, inexpensive model such as Claude Haiku 4.5 ($1 input / $5 output per million tokens at list) is usually the right choice; reserve Opus-class models for work that needs them.
Identity and permissions
As with Cloud Run, the function runs as a service account and the AnthropicVertex client picks up its credentials automatically through Application Default Credentials — no key material in code, environment variables, or secrets managers. Give that runtime service account the Vertex AI User role (roles/aiplatform.user), which includes the aiplatform.endpoints.predict permission needed for inference. The Claude model itself must already be enabled once, project-wide, from its Model Garden card. Use a dedicated service account per function so that Vertex AI's Data Access audit logs (once enabled) attribute each call to the specific automation that made it.
Where this pattern breaks down
- Long agentic work. Functions have bounded execution time. Multi-step tool-use loops or very long generations fit better in a Cloud Run service.
- Interactive streaming. An event-triggered function has no user waiting on tokens; if you need streamed output to a browser, you need a service.
- High-volume backfills. Fan-out of thousands of Pub/Sub messages will slam straight into your per-project Vertex quotas (requests and tokens per minute). For genuinely bulk offline work, Google's own Vertex batch prediction for Claude — input from a BigQuery table or JSONL in Cloud Storage, billed at 50% of on-demand — is the purpose-built tool. Note that this is Google's mechanism; Anthropic's Message Batches API endpoint is not available on Vertex AI.
- Duplicate events. Pub/Sub delivery is at-least-once. Make handlers idempotent — a duplicate Claude call costs real tokens and may double-post results.
Where to go next
Wire up quota awareness with 429 handling on Vertex, and compare this pattern against the batch-workload options on Vertex before building a high-volume pipeline out of single invocations.