Ideas that connect.
Work that moves forward.

What changes

Google Cloud announced the addition of Claude Opus 5.5 and Sonnet 5.5 to Antigravity for its customers in a post dated October 20, 2026. The announcement covers Antigravity 2.0, the CLI and IDE extensions. Google Cloud announcement.

For a development team, the practical decision is which model to use, how to check its changes and how much consumption to accept. Adding more options makes it possible to address those decisions within the same environment, but their value needs to be evaluated against the team’s own tasks and criteria.

Who can access the models

The model matrix consulted distinguishes the following plans for both Claude 5.5 models. Inclusion in the matrix remains subject to the service’s conditions. Availability by plan.

For enterprise developer tools, Google lists Standard, Plus, Standard Emerging Market and Pay-as-you-go; an invoiced billing account, a license and user permissions are required. Claude is disabled until an administrator authorizes it and accepts the provider’s terms. Enterprise configuration.

Clients, versions and regional scope

The extension documentation includes VS Code, Visual Studio 2026, JetBrains, Zed and Xcode. Enterprise support for JetBrains, Zed and Xcode is listed as Preview, a relevant qualification when planning adoption. IDE extensions.

In Enterprise, Claude offers Low, Medium—the default—High and Max thinking levels. The CLI supports model switching through `/model`; adjusting effort through `/effort` requires version 1.2.11 or later. Higher levels can consume more tokens. Selecting models and thinking levels.

Inference for these models in enterprise developer tools is documented for the `global`, `us` and `eu` locations; in-country regions are unsupported. This does not establish access from every country or availability in a particular account. Regional availability.

Billing and monthly spending limits

On Standard and Plus, Claude is billed by consumption through Cloud Billing, outside the included quota, and requires overages to be enabled. Model configuration.

The billing guide clarifies that overages do not apply to the Pay-as-you-go edition, where all usage is consumption-based. A project monthly spending limit can cover overages and Pay-as-you-go usage. Stopping consumption can take a few minutes, allowing charges to exceed the limit. Overage and spending configuration.

Selecting Claude does not eliminate all Gemini consumption: Antigravity retains lightweight Google models for coordination and summaries, which can incur additional charges. Execution architecture.

On personal Pro and Ultra plans, quotas depend on capacity and the work performed. Users can allow additional credits once quotas are exhausted; the documentation provides no universal guaranteed request count. Plans and quotas.

Reference prices and an unconfirmed rate

As an API reference, Anthropic lists USD 4 per million input tokens and USD 20 per million output tokens for Opus 5.5; Sonnet 5.5 is USD 2 for input and USD 10 for output. Cache operations have separate rates. Opus specifications, Sonnet specifications.

These figures do not confirm the applicable price within Antigravity. Google directs readers to its Opus and Sonnet SKU catalogs, whose rates could not be retrieved during this check. The specific rate therefore remains unverified, preventing a reliable total cost per task from being calculated here.

Interpretation: a second review needs evidence

Google proposes using one model family to implement and another to review, and assigning auxiliary tasks to faster models. The announcement provides no controlled comparison of these patterns in Antigravity. Google’s proposed patterns.

Our interpretation is that cross-model review deserves testing when it produces specific observations the team can verify. Two agreeing responses are insufficient to establish that a change meets requirements. Evaluation should measure defects detected, false alarms, review time and full cost, retaining executable tests and human review as acceptance criteria.

Model choice should also be allowed to vary by task. A localized fix and a migration spanning several components may justify different configurations; assigning them to a model in advance would be a working hypothesis rather than a demonstrated result.

Proposed example: comparing a pagination fix

This design is a reproducible editorial proposal using synthetic data. It has not been executed and does not predict which model would perform best.

• Prepare a test repository with a pagination bug, fictional records and acceptance cases covering empty pages, boundaries and duplicates.
• Compare three conditions: Sonnet implements and reviews itself; Opus implements and reviews itself; one model implements and a different family reviews.
• Keep the starting state, tools, instructions and budget identical across conditions; record versions and effort levels and repeat the tasks.
• Measure requirements met, confirmed defects, false alarms, total time, human intervention and billed consumption across every model used.
• Accept changes through tests and code review. If cross-model review adds cost without detecting relevant defects, adjust its scope before expanding it.