Critical Usability Issue: Antigravity CLI (agy) massive token overhead exhausts individual Pro quotas in minutes

[RogerPenna]

The Antigravity CLI (agy) features an incredibly heavy initialization and tool-calling architecture that completely exhausts Google AI Pro individual quotas within a very short window of usage. In just 2 hours of development, I hit a strict 5-hour rate limit lock. Worse, even after waiting hours, initiating a brand-new session and asking a single basic text question immediately triggered a quota refusal before a single response could be generated.

Running the /context command reveals a massive, unacceptable structural overhead. The CLI consumes nearly 23k–25k tokens out of the box per request just to maintain its own internal system prompt and system tools, regardless of the complexity of the user's input.

To Reproduce

Open a fresh terminal session using agy on a local repository.

Ask a simple conceptual or history question (e.g., "where did we stop?").

Observe the CLI executing background workspace tools (e.g., ListDir on internal .gemini paths) before responding.

Receive a hard quota error: ⚠ Individual quota reached. Resets in XhYmZs.

Inspect usage with /context.

Context Overhead Breakdown (from /context output):

Total Session Usage: 24.3k / 1.0M tokens (2.3% of the window gone on turn one)

User messages: 2 tokens (0.0%)

System prompt: 7.8k tokens (0.7%)

System tools: 15.1k tokens (1.4%)

Expected behavior
A developer CLI tool should be lightweight and highly optimized for frequent, rapid-fire iterative commands. System tools, automated file indexers, and bloated prompt wrappers should not aggressively burn through a paying user's individual API/Pro limits.

Desktop environment:

OS: Windows (PowerShell)

CLI Version: Antigravity CLI 1.0.0

Model: Gemini 3.5 Flash (High)

Account Type: Google AI Pro Subscription

Additional context/Feedback:
The older Gemini CLI did not suffer from this issue and allowed seamless, continuous development. If this heavy, background tool-calling architecture is going to remain mandatory for agy, individual Pro account limits need to be drastically adjusted to account for the tool's internal token footprint. Leaving developers stranded mid-session with a broken codebase for 4 to 5 hours makes the CLI completely unviable for production work. Many developers—including myself—will be forced to cancel their Google AI subscriptions and return to alternative developer environments (like ChatGPT Codex) if this remains unaddressed.

[elithubb]

Antigravity Models Burn Through Credits in Hours, Not Weeks

Real-World Test Results:

$30 USD = 2,500 credits
Actual usage time: 2-3 hours before quota exhausted
That's roughly $10-15 per hour of actual work

Why Credits Burn So Fast:

• Models loop endlessly (60-70% wasted compute)
• Hallucinations consume tokens without producing output
• "Compute effort" metric is opaque — can't see what's burning quota

The Scam:

• Google advertises "generous limits"
• Reality: $30 = 2-3 hours max
• Weekly lockouts after minimal tasks
• No refunds for wasted compute on infinite loops
• Other private IDEs: Transparent pricing, no hidden quota games

Either:

1. Fix the models so they don't waste 70% on loops
2. Refund credits for non-productive compute
3. Stop charging for hallucinations & infinite loops

Stop asking users to pay until this is fixed.

[sanjeev23oct]

If you're looking for an alternative with a different approach —
ZAP is a Rust terminal agent, single binary, provider-agnostic
(works with Gemini API, OpenAI, local models). Skill injection is
lazy, MCP lazy-loads on first use. Much lower baseline overhead.

https://github.com/zap-coding-agent/zap-coding-agent

[aniruddhaadak80]

Hey there. Thanks for bringing this up. We understand it is frustrating to burn through your Pro quota so quickly.

The token overhead issue is actively being worked on. We are investigating ways to optimize how prompts handle history.

For now, limiting your context window will help. We hope to ship a fix in an upcoming release. You can track our progress in the modelRouterService.ts module where routing logic is handled.