Gemini 3.8 Flash in Antigravity: Severe Latency, Command Looping, Quota Drain & API 503 Billing Issues

Overview

Following recent updates, the stability and execution reliability of Gemini 3.8 Flash across all reasoning budgets (High, Med, Low) within Antigravity have deteriorated significantly. While 3.8 initially showed strong promise over 3.7, current behavior in production workflows is resulting in severe latency, context hallucinations, loop traps, and rapid quota burnout on high-tier plans.

Below is a breakdown of the specific critical issues observed:


1. Habitual Sluggishness & Unresponsive Session State

  • Latency Across All Actions: Response latency is consistently high across all tasks, regardless of whether thinking is set to Low, Med, or High.
  • Fresh Chat Resets Do Not Help: Starting new chats or refreshing sessions fails to resolve the lag.
  • Command Loops: In a single evening across 7 different sessions, the model repeatedly fell into infinite retry/execution loops over trivial, basic shell commands without progressing the task.

2. Context Amnesia & Hallucinated File Creation

  • Searching for Phantom Files: The model regularly claims required files exist, searches for non-existent paths, and when it fails to find them, automatically creates blank or incorrect files to compensate.
  • Ignoring Local Architecture Constraints: Despite clear instructions that our infrastructure operates strictly locally and via BigQuery for enterprise data security (no remote repositories), the model persistently attempts to execute git push / git pull commands against non-existent remotes.

3. Quota Drain with Low Task Completion

  • Ultra Tier Burnout: Because the agent gets trapped in hallucination cycles, file-hunting, and command loops, it burns through massive token/quota allocations with near-zero actionable output.
  • While falling back to 3.7 is a temporary workaround, regressing to older model versions undermines production workflows and halts adoption of the newer architecture.

4. Gemini API: “Servers Busy” Errors Incurring Charges

  • Capacity Failures: Running external, lightweight automated services across business departments via the Gemini API frequently results in 503 / Cloud servers are busy, try again later errors.
  • Billed Despite Failures: Despite these requests failing at the infrastructure level, quota/usage charges are still being registered.
  • Business Risk: Reliability is a requirement for enterprise automation. When internal department tools fail due to upstream model capacity and ghost billing, leadership is forced to evaluate more dependable alternative providers (Anthropic, OpenAI).

Requested Action / Clarification:

  1. Antigravity Loop Detection: Can we get an aggressive loop-breaking heuristic in Antigravity to stop agents from burning tokens on repeated command retries?
  2. Context Retention & Grounding: Are fixes incoming for 3.8 Flash’s path resolution and negative constraint adherence (e.g., respecting “no git remote” environments)?
  3. API Billing Logic: What is the engineering team’s policy on credit/quota adjustments when requests fail due to Google server capacity errors?

Looking forward to hearing from the Antigravity & Gemini engineering teams on upcoming stability patches.

You literally described all the problems I ran into; the only thing that helped was rolling back to Flash 3.7. Flash 3.8 was just destroying my project, even though it claimed everything was working. The biggest shock was that version 3.7 handled the queries I gave to 3.8 almost always on the first try with a minimum of errors and corrections, whereas 3.8 got stuck in endless loops for the same task, generating more errors than actual code—it was literally building a new architecture on top of the old one, ignoring the project that was already finished! I was simply stunned by how much the 3.8 model had regressed, as well as by the fact that so few people are writing about this; I thought it was purely my problem and that I was going crazy.