Hey everyone, is anyone else experiencing absurd token burn with Google Antigravity? A single 28-minute agent run for minor file edits just wiped out 91% of my entire weekly Gemini quota before crashing with an internal error. I just logged in with that email account and there was 100% quota tho!!!
Seriously how does a multi billion dollar tech giant like Google ship an AI platform that penalizes us for its own internal background glitches?
From a developer standpoint, it’s completely absurd that basic execution caps and token safeguards aren’t in place to stop a runaway agent loop from burning 91% of a weekly limit on minor file tweaks.
It’s just terrible design you step away for 28 minutes expecting a simple edit, only to get hit with an unhandled platform crash and get locked out of your tools for an entire week.
How do we trust this IDE anymore? A single unhandled background loop wipes out our whole weekly quota before we can even catch it.
That is a genuinely brutal experience @SuneraX . Losing 91% of a weekly allowance on minor tweaks while away from your desk is understandably frustrating.
What you encountered is almost certainly the O(N2)O(N^2)O(N2) quadratic context accumulation trap—one of the harshest failure modes in autonomous agentic coding.
Why This Happens Under the Hood
When an agent gets stuck on a minor edit (e.g. an ambiguous lint failure, an unexpected terminal return code, or a regex mismatch), it enters an unprompted self-healing retry loop:
- Turn 1: The agent reads the file and instructions (~15k tokens).
- Turn 10: The agent has retried 9 times. Every single retry re-transmits the full cumulative conversation history, including prior diffs, failed tool outputs, and terminal traces (~80k tokens per turn).
- Turn 25: A single turn now costs 150k–200k tokens.
If the agent runs 20–30 rapid retry cycles over 28 minutes, the cumulative payload easily exceeds 3 to 4 million input tokens, incinerating a weekly quota tier before an internal context ceiling or timeout finally terminates the loop.
Three Immediate Safeguards You Can Use Today
Until the platform introduces native hard circuit-breakers, here are three operational habits to prevent runaway burns:
- Avoid Unattended Multi-File Tasks: If you step away from your desk, leave the agent in Planning mode (
/plan) or require human confirmation for tool execution rather than allowing autonomous auto-runs.
- Check Session Health Frequently: In long-running tasks, keep an eye on conversation depth. Once a session exceeds 25–30 turns, the token cost per turn increases dramatically. Splitting large refactors across fresh sessions preserves your quota window.
- Use Conversation-Only Undo: In the latest Antigravity v2.19.1 release, the undo dialogue now allows reverting only the conversation context without touching files on disk, letting you clear bloated retry histories if an agent begins looping.
This exact problem is why many of us in the community have been advocating for native session lifecycle governance and hard turn-limit watchdogs (circuit-breakers that pause the agent after 15–20 continuous turns if human feedback hasn’t intervened).
Hopefully, the Antigravity engineering team can introduce native loop detection and quota circuit-breakers soon to protect developers from runaway context spirals.
You are on the free plan. Please upgrade to “Pro” plan which should provide higher quota
Also, there’s no such thing as “basic execution caps” or “token safeguards”, in any of the available coding harnesses (like Open Code, Claude Code, Antigravity, or Qwen Code). There is a safeguard, which is called monitoring your agent and stopping it when needed
@Faheem_Anis1 actually your response is factually and logically incorrect 
-
Execution caps exist across the industry: Claiming no harness has safeguards is false. Frameworks like LangChain/LangGraph enforce recursion_limit (default 25 steps), AutoGen uses max_consecutive_auto_reply, and CLI harnesses use max tool-step limits specifically to stop infinite loops.
-
Upgrading doesn’t fix a runaway loop: Telling users to buy a higher tier when an agent gets stuck in a retry loop just burns through a paid quota faster instead of fixing the platform issue.
-
Manual babysitting isn’t a safeguard: If a user must watch a screen for 28 minutes to manually kill a stuck loop, it isn’t an autonomous agent—it’s just a high-latency CLI wrapper.
Circuit breakers and step limits are standard software safety features, not optional luxuries
@dllhell While your O(N²) token math is accurate, explaining the mechanism doesn’t excuse a total lack of platform governance. An agent running unprompted retries over 28 minutes for a minor edit without hitting an iteration cap or auto-pruning context is a clear system defect, not normal operation. Expecting developers to manually prune history or babysit background runs completely invalidates the purpose of autonomous agentic workflows, which is why native loop detection and hard turn-limit watchdogs must be standard on Antigravity.
@SuneraX You are 100% spot on.
Diagnosing the O(N^2) math was strictly a technical post-mortem of how the tokens burn, not an excuse for the lack of harness-level safeguards.
You hit the nail on the head on autonomous agents: if a developer has to sit and watch a terminal for 28 minutes to manually kill a runaway retry loop, the tool stops being an autonomous agent and becomes a high-latency liability. Manual history pruning is an operational workaround, not acceptable platform architecture.
Industry frameworks have proven that hard iteration caps and circuit breakers are standard engineering:
- Max-Turn Circuit Breakers: Hard-pausing execution after N unattended turns without a successful compiler pass or git commit.
- Repetitive Loop Interception: Catching when an agent repeats the same failing shell command or edit twice with identical exit codes.
- Context Budget Guards: Preventing unbounded transcript re-ingestion when background retries spiral.
This is exactly why several of us have been building external MCP watchdog gates (like session-guard and pre-commit compiler checks) to enforce local turn limits client-side. But you are completely right: developers shouldn’t have to build custom MCP guardrails just to stop their weekly quota from evaporating.
Hard execution caps and automatic loop detection must be native, first-class primitives in the Antigravity core runtime.
Ok. Then keep posting below. There can be several solutions starting from improving your context and leading to repeated tool detection, but I don’t believe you are interested in learning any of them
