Developers transitioning to Google’s Antigravity CLI are encountering a significant limitation: when authenticating with a paid API key and Google Cloud Project ID, only Gemini 3.x models are accessible. This creates friction for developers whose agent scaffolding and foundational tasks depend on Gemini 2.x models.
The Model Availability Problem
A developer reported that when authenticating with Antigravity CLI using a paid-tier API key and a Google Cloud Project ID, only Gemini 3.x models appear in the interface. This contrasts sharply with the legacy Gemini CLI, where a full selection of 2.x models remains available even with API key authentication.
The developer notes their agent scaffolding relies heavily on 2.x models for foundational tasks, with 3.x models reserved for more complex reasoning and planning. This architectural separation is now impossible in Antigravity CLI with paid authentication.
The discrepancy in model availability appears directly tied to authentication method. When authenticating Antigravity CLI via Google OAuth (covering free usage or Gemini Code Assist), a broader range of models becomes visible. However, switching to a paid-tier API key with a Cloud Project ID restricts selection exclusively to Gemini 3.x models.
This observation challenges the assumption that models listed on the Gemini API pricing page would be universally available across all authentication methods in Antigravity CLI.
API Key Support Remains Incomplete
A larger issue underlies this limitation: API key authentication for Antigravity CLI is not fully implemented. A feature request on the project’s GitHub shows that developers have been asking for proper GEMINI_API_KEY environment variable support to enable headless, automated, and CI/CD workflows.
Currently, Antigravity CLI relies primarily on OAuth for user authentication. While this works for interactive desktop use, it creates bottlenecks for server-side or automated workflows. Without proper API key integration, developers cannot run the CLI programmatically with custom quotas or in unattended environments.
Google explicitly acknowledged that there won’t be 1:1 feature parity right out of the gate
between Gemini CLI and Antigravity CLI. The transition from Gemini CLI to Antigravity CLI is critical, with Gemini CLI scheduled for deprecation on for individual users (enterprise access remains unchanged).
This impending deadline creates pressure for comprehensive model support in the new interface, but the current limitations suggest developers may face a difficult choice: continue using the soon-to-be-deprecated Gemini CLI until Antigravity CLI achieves feature parity, or migrate early and accept restricted model availability.
The Cost Consideration
There’s another layer to this issue: billing. Developers report that Antigravity CLI charges significantly higher token costs because it’s billed through Vertex API instead of the Gemini API. One developer noted that performing similar tasks resulted in substantially different billing between the two CLIs, with Antigravity consuming more tokens for equivalent work.
This means migrating to Antigravity CLI earlier than necessary could result in both reduced functionality (2.x model access) and increased costs.
What Developers Need to Know
For now, developers with agent scaffolding dependent on 2.x models face limited options:
- Continue using Gemini CLI with OAuth authentication until June 18, 2026
- Request access to paid Gemini API keys through your Google Cloud organization (enterprise tier users maintain full access)
- Monitor the Antigravity CLI GitHub repository for updates on model availability and API key support
- File feature requests if your use case isn’t covered by current 3.x models
Clarity from Google on expected timelines for full model support and API key implementation in Antigravity CLI would help developers plan their migration strategies more effectively.
Follow Hashlytics on Bluesky, LinkedIn , Telegram and X to Get Instant Updates
