Cowork on Vertex AI — running Claude Cowork inside your Google Cloud project

TL;DR. Cowork on Vertex AI is the deployment mode where Claude Desktop routes inference through Google Cloud Vertex AI in the customer's own GCP project. Conversation data stays inside the GCP tenant; residency is determined by the Vertex region selected for inference plus the user's device location. The route is structurally identical to Cowork on Bedrock — same desktop app, same feature subset, same rollout shape — with a different cloud provider underneath. Choose Vertex when GCP is the strategic cloud or when EU/UK residency maps better onto Vertex regions than Bedrock regions.

When Cowork on Vertex AI is the right answer#

The same three signals that justify Bedrock, with two GCP-specific additions:

• The organisation is materially committed to GCP — workloads, billing relationship, IAM model.
• A compliance program requires inference to stay inside an existing GCP boundary.
• Platform engineering has the capacity to own MDM, telemetry, IAM, and inference budget.
• GCP-specific: the strategic cloud for the customer is Google Cloud and bringing AWS into the stack just to host Cowork inference is operationally undesirable.
• GCP-specific: the customer's EU or UK residency posture maps better onto Vertex regions than onto Bedrock regions. Verify against current model-availability documentation for both providers — this is true for some sovereign deployments and not others.

If the customer is already running on AWS for everything else, Bedrock is the lower-friction route. The choice is rarely "Vertex versus Bedrock for Cowork specifically" — it's "Vertex versus Bedrock as the customer's strategic cloud," and Cowork follows that decision.

Architecture#

Identical to the Bedrock route with one substitution: inferenceProvider is set to vertex, and inferenceVertexRegion selects the GCP region where Claude inference runs. Inference requests flow from the user's machine to the configured Vertex endpoint over the customer's GCP network path; GCP IAM credentials authorise the calls. Conversation history persists on local disk. Tool execution runs in the same Cowork sandbox VM used in first-party Cowork.

The desktop app's only outbound calls to Anthropic are crash reporting, product analytics, and auto-updates — each individually disabled in managed configuration.

Data residency posture#

Two inputs, same shape as Bedrock:

• inferenceVertexRegion — the GCP region where Claude inference runs (e.g., us-central1, europe-west4, asia-southeast1). Conversations, files, and tool outputs flow to this endpoint and are subject to GCP's regional isolation.
• The user's device. Conversation history is on the user's local disk; device location is part of the residency story.

For EU-headquartered organisations under strict residency requirements, Vertex's EU regions are sometimes the more straightforward option than the equivalent Bedrock regions. Verify the specific Claude model availability in your target region before committing — model availability moves over time on both providers.

Authentication and access#

• No Anthropic account. Local device identity, same as Bedrock.
• GCP IAM authorises inference calls. Scope the IAM role used by the desktop app to the minimum Vertex AI prediction permissions on the specific Claude model resources in the chosen region.
• MDM enforces config. Same MDM tooling as Bedrock — Jamf, Kandji, Mosyle, Workspace ONE for macOS; Intune or Group Policy for Windows.
• SSO via the OS layer. User identity in the customer's IdP, surfaced through OS sign-in.

What's available, what's not#

Same feature subset as Bedrock — see the Cowork on 3P feature matrix for the full table. The headline subtractions:

• ❌ Chat tab
• ❌ Computer Use
• ❌ Skills Marketplace (skills the customer ships still run)

Preserved: full Cowork agentic loop, Code tab, projects, artifacts, memory, file upload/export, MCP connectors, plugins, customer-deployed skills, remote connectors.

Billing#

Consumption-based through the customer's existing GCP agreement: Vertex AI prediction billing at the published per-token rate for the chosen Claude model and region. No separate Anthropic seat licensing on this route.

The cost-forecasting note from the Bedrock page applies identically here: Cowork's agentic loops are token-heavier than chat, and most mid-market deployments under-estimate first-month inference spend. Build the model before pilot.

Telemetry and audit#

Same two-path posture as Bedrock:

• Anthropic-bound telemetry (off in a hardened deployment): crash reports, product analytics, auto-updates. Each disabled via a managed-configuration key.
• Customer-bound telemetry (on): full session activity exported to the customer's OpenTelemetry collector — the audit substrate for regulated deployments.

Rollout shape#

Same four-stage timeline as Bedrock — pre-flight, pilot, hardening, rollout — with GCP-specific substitutions: GCP region selection instead of AWS region, GCP IAM policy instead of AWS IAM, Vertex model availability check instead of Bedrock. Plan 60 days with help, 90 in-house.

When Vertex genuinely beats Bedrock for a Cowork deployment#

Three real cases:

• EU residency on a GCP-led architecture. When the rest of the customer's stack is on GCP-EU and the compliance program is comfortable with that posture, adding Bedrock just for Cowork inference is a procurement headache that produces no compliance benefit.
• Existing Vertex commitments and credits. Customers with material Vertex commitments will get more attractive economics on the Vertex route.
• An existing Vertex MLOps practice. If the customer's platform team already operates Vertex day-to-day (not just consumes its API), MDM rollout and observability of Cowork-on-Vertex slots into existing practice cleanly. The same is true on Bedrock for AWS-native shops.

When none of those apply, Vertex and Bedrock are equivalent from a Cowork standpoint and the choice is a strategic-cloud question, not a Cowork question.

Tinkso's take#

Cowork on Vertex AI is the right route for GCP-led customers, particularly EU or UK organisations whose residency posture is already built around Google Cloud. We treat the deployment as architecturally identical to Cowork on Bedrock — the rollout playbook, the cost-forecasting work, the telemetry wiring, the procurement objections — with provider-specific substitutions in IAM, region, and the customer's existing observability tooling.

We do not recommend choosing Vertex over Bedrock specifically for Cowork. The decision is upstream of Cowork: whatever is the customer's strategic cloud is the right route. Cowork follows.

Try this#

Run the same 30-minute working session as the Bedrock page — map each section to "we own this," "vendor-managed," or "needs decision" — but with the GCP team in the room rather than the AWS team. The output is a Vertex-shaped procurement requirement.