The Problem: Rapid Cloud Quota Depletion in Agentic Loops
Antigravity’s agentic workflows are powerful, but background operations—such as multi-file state checks, terminal trace reads, linter error parsing, and AST traversals—inject massive context payloads into the primary cloud model (Gemini Pro/Flash).
Even when selecting lightweight models (e.g., Gemini Flash / Low), active coding sessions quickly compound input tokens across repetitive agent loops. On a Google AI Pro plan (CA$26.99/mo / $19.99 USD), heavy daily agentic usage can deplete the rolling weekly baseline in 2–3 days, forcing developers onto high-cost pay-as-you-go credit overages or $100+/mo Ultra tiers for tasks that don’t strictly require cloud-scale compute.
Proof of Concept: My Real-World MCP Workaround
To test if local offloading could solve this, I built a hybrid local pipeline across my local network:
-
Local Graph Indexing: Configured
codebase-memory-mcpto parse Tree-Sitter ASTs and manage code graph memory locally, replacing raw cloud-side file exploration. -
Local Model Inference: Connected an
ollama-bridge-mcpto route repetitive execution steps and draft edits to a locally hosted Gemma 4 12B instance on a network machine.
The Impact:
-
Massive Token Savings: Offloading background context parsing extended my cloud subscription allocation from burning out in ~1 day to lasting ~3.5–4 days during heavy usage.
-
The Limitation: Because this relies on external MCP translation layers, every return payload gets injected back into the top-level agent’s system prompt as raw text. This creates extra translation overhead and unnecessary token inflation compared to what a native integration could achieve.
Proposed Solution: First-Party Native Hybrid Execution
We request that the Antigravity product team introduce native local execution capabilities directly inside the IDE:
1. Native On-Device Gemma 4 Packaging (inside the IDE)
-
Add a Local Model Manager in Antigravity settings where developers can download quantized Gemma 4 variants (e.g., Gemma 4 E4B or Gemma 4 12B Unified).
-
Run the model locally using Google’s native AI Edge / LiteRT runtime or whatever is the best, ensuring a zero-config, 100% first-party experience that leverages on-device GPUs/NPUs on developer laptops.
-
(Optional Fallback): Allow users to bind custom local endpoints (e.g., Ollama / local network endpoints) for custom hardware setups. Though I dont think Google would support this but native gemma 4 would make sense coz it’s google own model.
2. Native Codebase Memory & AST Graphing
- Bake a local, low-footprint Tree-Sitter / vector index directly into Antigravity’s core engine (similar to
codebase-memory-mcp) so file relationships are queried on-device rather than re-sent to the cloud on every agent turn. Maybe antigravity is already doing this with the local memory but just wanted to put this here.
3. Intelligent Workload Delegation
-
Local Gemma Worker: Automatically handles AST parsing, draft file diffs, linter error fixes, and terminal log filtering 100% on-device or even some light feature building
-
Cloud Gemini Orchestrator: Receives only concise, high-signal summaries from the local worker to handle high-level architectural planning, multi-file refactoring, and complex reasoning.
Why This Benefits Google and Developers
-
For Google Cloud Infrastructure: Drastically slashes incoming token bandwidth and server compute loads on Gemini endpoints by offloading background loops to user hardware.
-
For Developers: Eliminates frustrating weekly quota walls on Google AI Pro, speeds up local feedback loops, and provides an end-to-end privacy/offline option for local file processing.
-
For the Ecosystem: Creates the ultimate real-world showcase of Gemma 4 open weights operating in tandem with Gemini cloud AI.
-
Current Environment: Google AI Pro Subscription | Antigravity IDE | Gemma 4 12B via Ollama &
codebase-memory-mcpbridge
Looking forward to feedback from the Antigravity engineering team!