What Happened
Google Cloud has made an Anthropic-managed deployment option for Claude generally available alongside its existing Google-managed option. Both provide the latest Claude models on day zero, with the same pricing, Google Cloud billing, and drawdown of eligible commitments. The important differences are who processes the data, which controls apply, and when platform features become available. [1]
- Anthropic-managed: Anthropic acts as the data processor. New Claude Platform features are available immediately, including Managed Agents, currently in beta, skills, and code execution. [1]
- Google-managed: Google Cloud acts as the data processor. New features arrive after integration, with controls including customer-managed encryption keys, VPC Service Controls, and data residency in the U.S., EU, and APAC. [1]
Separately, Claude Opus 5.5 and Sonnet 5.5 are now available in Google Antigravity. Administrators must authorize partner models and configure pay-as-you-go billing. Developers can switch models between turns without losing workspace context across supported development interfaces. [2]
Why It Matters to Businesses
Model availability and platform capability are now separate procurement decisions. Day-zero access to a model does not mean day-zero access to every agent feature. Conversely, immediate feature access does not establish equivalence with the controls documented for Google-managed deployments. [1]
For enterprises, this changes how platform teams should evaluate deployment options. A workload requiring a particular processor relationship, residency configuration, or network boundary may favor Google-managed deployment. A team testing new agent capabilities may prefer Anthropic-managed deployment, subject to its security and contractual review.
Unified billing simplifies purchasing, but it does not make total operating cost identical. Agent workflows can introduce additional model calls, tool execution, retries, and operational overhead. Antigravity’s background Gemini subagents also consume tokens and may incur charges. [2]
Kimbodo Engineering Perspective
We would treat deployment selection as a workload policy decision, not a developer preference. Approve routes according to data classification, required capabilities, processor terms, and control requirements. Avoid automatic fallback between deployments unless both routes are approved for the same data and execution context.
A shared model gateway can centralize authentication, budgets, telemetry, and routing. It should not conceal meaningful differences between platforms. Maintain an explicit capability registry so applications can determine whether an approved route supports a required feature rather than discovering incompatibility during execution.
For software delivery, cross-model review is useful as an additional check—not an independent guarantee. Google recommends using one model family to implement a change and another to check the final diff against requirements and tests. Keep deterministic tests, security scanning, and human approval for consequential changes. [2]
How We Would Implement It
- Define approved deployment profiles. Record processor, permitted data classes, residency requirements, available controls, supported features, and allowed tools. Verify the configuration and contractual scope rather than relying on a service label.
- Route through a policy-enforcing gateway. Authenticate the calling service, select an approved deployment profile, enforce token and concurrency limits, and reject incompatible requests. Keep provider-specific feature handling in separate adapters.
- Separate inference from execution. Place code execution and external tool access behind a controlled execution layer with scoped credentials, restricted network access, timeouts, and approval gates for consequential actions.
- Evaluate before promoting. Test each model-and-deployment combination against representative workloads for correctness, latency, tool behavior, and cost per successful task. Repeat evaluation when changing models, prompts, or platform features.
- Instrument the complete workflow. Track model calls, tool calls, retries, failures, and spend by application and tenant. Redact sensitive content before logging and define retention explicitly.
- Configure development agents separately. In Antigravity, keep complex decisions with the primary reasoning model and delegate bounded searches or test-failure classification to faster subagents. Configure tiers in the documented agent files and monitor background usage. [2]
Risks, Costs and Security
The largest governance risk is assuming that the same model and billing channel imply the same processing arrangement. The two deployment options identify different data processors; security and legal teams should assess each intended route. Controls documented for Google-managed deployment should not be presumed to apply identically to Anthropic-managed deployment. [1]
Managed Agents remains in beta, so production adoption should account for support expectations, change management, and an exit path. Code execution also expands the attack surface: model-generated instructions must not inherit unrestricted credentials or network access. [1]
Finally, optimize for cost per validated outcome, not token price alone. A faster subagent can reduce expense on bounded tasks, but unnecessary delegation, repeated reviews, and retry loops can erase those savings. Establish budgets and termination conditions before increasing agent autonomy.
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Infrastructure & MLOps practice, or Estimate My Infrastructure.
