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

Google Antigravity
,
1

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.

2

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.

3

Google, you have broken the entire development experience.

At this point, I genuinely see no reason to continue serious development on Google AI Studio until Google itself decides what exactly it is building, which models it intends to support, and what kind of development platform it wants AI Studio to become.

I run my own AI lab and have been actively testing, researching, and working with Google’s AI models and coding environments for almost two years. I know this platform extremely well. I notice every small behavioral change, every model transition, every regression, every improvement, and every change in agent behavior.

What is happening now is not a minor quality fluctuation.

It is a regression.

The current development experience feels dramatically less stable, less predictable, and less intelligent than what we had before.

Agents repeat the same operations. They reread files unnecessarily. They enter loops. They lose context. They make changes that were never requested. They consume excessive quota. They take far longer to complete simple tasks. They sometimes break code that previously working models handled correctly. And, worst of all, developers can no longer trust that the same workflow will behave consistently from one week to the next.

That destroys productivity.

A development platform cannot constantly change the model, agent layer, tool behavior, quota system, and available model lineup while expecting developers to build serious software on top of it.

Developers need stability.

We need predictable model behavior. We need reliable tool execution. We need consistent access to capable models. We need clear communication when models are removed or replaced. We need backward compatibility. And we need to know whether a workflow that works today will still work tomorrow.

Right now, it feels like developers are being used as beta testers for a platform that is being redesigned underneath us in real time.

I have invested enormous amounts of time studying Google’s models, understanding their strengths and weaknesses, adapting workflows, building systems around them, and learning how to get the best results from AI Studio.

But there is a limit.

When a platform becomes unstable enough that experienced users start questioning whether the model has suddenly become less capable, something is seriously wrong.

The problem is no longer just model quality.

The problem is trust.

Until Google stabilizes AI Studio, clarifies its model strategy, fixes the current agent regressions, and stops constantly changing the ground underneath developers, I see very little value in continuing serious development there.

Google has extraordinary AI technology.

But extraordinary models are not enough.

A serious development platform also needs consistency, reliability, transparency, and respect for the developers who build on it.

Right now, Google AI Studio is failing on those fundamentals.