[BUG] HTTP 429 RESOURCE_EXHAUSTED on Ultra tier — OAuth valid but streamGenerateContent blocked (Ref: AG-859)

Google Antigravity
1

Summary

I’m experiencing persistent HTTP 429 RESOURCE_EXHAUSTED errors on every model request, despite having an active Google AI Ultra subscription and the dashboard showing available quota. This appears to be the same AG-859 tier synchronization bug reported since January 2026, but I’ve gathered precise diagnostic evidence that isolates the issue.

Environment

  • Plan: Google AI Ultra (personal Gmail account)
  • Antigravity Version: 2.8.1.0 (Windows x64)
  • OS: Windows 11
  • Network: US exit IP (Kent, Washington) — confirmed via ipinfo
  • Account region: US
  • Affected Models: All official Gemini models (gemini-pro-agent, gemini-3.6-flash-high, gemini-3.7-flash-medium, gemini-3.1-pro-low)

Error Details

Trajectory ID: 574c3399-56dd-4fef-8ae7-c8........
Error: HTTP 429 Too Many Requests
Sherlog:
TraceID: 0x423d47c4f.....
Date: Fri, 14 Aug 2026 03:43:16 GMT

{
  "error": {
    "code": 429,
    "message": "Resource has been exhausted (e.g. check quota).",
    "status": "RESOURCE_EXHAUSTED"
  }
}

The error response contains no Retry-After header and no quotaResetDelay — just a bare RESOURCE_EXHAUSTED with no indication of when access will be restored.

Key Diagnostic Evidence: OAuth is Valid, but Model Calls are Blocked

I enabled verbose network logging in Antigravity’s language server and observed a critical distinction:

Authentication endpoints are working — these return HTTP 200:

2026-08-14T03:53:19  loadCodeAssist           -> 200 ✅
2026-08-14T03:53:23  fetchUserInfo            -> 200 ✅
2026-08-14T03:53:41  loadCodeAssist           -> 200 ✅
2026-08-14T03:53:42  fetchUserInfo            -> 200 ✅
2026-08-14T03:53:55  retrieveUserQuotaSummary -> 200 (groups=2, quota available) ✅

But every model request is rejected with 429:

2026-08-14T03:54:02  streamGenerateContent    -> 429 ❌
2026-08-14T03:54:05  streamGenerateContent    -> 429 ❌
2026-08-14T03:54:09  streamGenerateContent    -> 429 ❌

This proves:

  1. My OAuth token is valid (fetchUserInfo/loadCodeAssist succeed)
  2. My quota is available (retrieveUserQuotaSummary returns groups=2 with remaining capacity)
  3. The block is specifically on model inference — the streamGenerateContent endpoint
  4. This is NOT a client-side issue — the 429 is returned by Google’s server directly

Troubleshooting Already Attempted

  • :white_check_mark: Verified OAuth token validity (fetchUserInfo returns 200)
  • :white_check_mark: Verified proxy exit IP is in US (not an IP/region issue)
  • :white_check_mark: Tried multiple official Gemini models (gemini-pro-agent, gemini-3.6-flash-high, gemini-3.7-flash-medium, gemini-3.1-pro-low) — all return 429
  • :white_check_mark: Confirmed quota shows available capacity (retrieveUserQuotaSummary groups=2)
  • :white_check_mark: Waited and retried over multiple hours — 429 persists
  • :white_check_mark: Switched network nodes (multiple US locations) — 429 persists (confirms account-level block, not IP)

What I Need

  1. Can someone from the Antigravity team check Trajectory ID 574c3399-56dd-4fef-8ae7-c85........ and TraceID 0x423d47c4fbb..... in the backend logs?
  2. Is this the same AG-859 quota sync bug? If so, is there a manual reset available for Ultra subscribers?
  3. Why does streamGenerateContent return 429 when retrieveUserQuotaSummary shows available quota? This suggests the quota sync between the dashboard and the inference endpoint is broken.

Impact

As an Ultra subscriber paying $249.99/month, I’m unable to use any official Gemini model for development. This has been recurring and makes Antigravity effectively unusable.

Thank you for your help.

@Abhijit_Pramanik @Thatipamula_Namratha

2

Hi @Jay_xuange, Welcome to the Forum!

Could you please try these workaround steps:

  • Close the Antigravity IDE completely.

  • Delete the local configuration/cache directories on Windows 11 to purge the bad tokens. Open your File Explorer and delete the following folders:

    • %APPDATA%\Antigravity
    • %USERPROFILE%\.antigravity
    • %USERPROFILE%\.gemini

  • 3. Set default browser to a clean profile or an Incognito/Private window logged in exclusively to the personal Google account with the AI Ultra subscription. Ensure no workspace or secondary accounts are logged into that session.

  • 4. Relaunch Antigravity and log in.

If the issue still persists, please submit a report through the built-in “Provide Feedback” feature found in the top-right corner of the interface.

3

Regarding the HTTP 429 RESOURCE_EXHAUSTED error on old conversations with full quota remaining, I’ve done extensive investigation and here’s what I found:

Root Cause

After re-authenticating my Google account (clearing %APPDATA%\Antigravity, revoking OAuth, and re-logging in), all old conversations started returning 429 errors when sending new messages. Creating a new conversation works fine, but old ones are permanently rate-limited.

Key Observations

  1. Quota is not the issue — fetchAvailableModels shows 100% quota remaining, but streamGenerateContent on old trajectories returns 429
  2. Trajectory ID binding — Old conversations are bound to the previous OAuth session/trajectory. After re-authentication, the server rejects requests on old trajectories with 429, even though the account has full quota
  3. Not model-specific — All models (Gemini Pro, Flash, Claude) fail with 429 on old conversations
  4. Not IP-related — Tested with different VPN nodes, same 429 on old conversations
  5. Clearing conversation cache — If I delete the old conversation .db files, new conversations work normally. This confirms the issue is tied to old trajectory/session binding, not account-level rate limiting

What I’ve Tried

  • :white_check_mark: Cleared %APPDATA%\Antigravity, %USERPROFILE%\.antigravity, %USERPROFILE%\.gemini and re-authenticated
  • :white_check_mark: Revoked OAuth access and re-authorized
  • :white_check_mark: Switched proxy nodes (residential IP, US-based)
  • :white_check_mark: Tested on multiple Google accounts — same behavior
  • :cross_mark: Cannot recover old conversations — the 429 persists on any old trajectory ID regardless of quota

Questions

  1. Is there a way to “rebind” old trajectory IDs to the new OAuth session? The conversation data is intact (SQLite .db files), but the server rejects them.
  2. Is this the known AG-859 bug? If so, is there a timeline for a fix, or should affected conversations be considered permanently lost?
  3. Would the in-app Feedback tool with TraceID help diagnose this? I have TraceIDs from the 429 responses.

My TraceIDs

  • Trajectory ID: 0823d797-3d39-4d76-855e-be82844b17..
  • TraceID: 0x (empty in response headers)

Business Impact

This issue is critically affecting our team’s productivity. We have over 60 conversations across 30+ projects accumulated over months of work, all containing critical context, code decisions, and architectural discussions. Losing access to these conversations means:

  • Months of accumulated context is locked behind 429 errors
  • Team members cannot resume work on existing projects — they must start over from scratch
  • Critical decision history and code reasoning is inaccessible
  • Project continuity is broken — ongoing work cannot continue on existing conversation threads

If this cannot be resolved, our team will be unable to maintain continuity on active projects, and we will be forced to evaluate whether we can continue using Antigravity as our primary development tool. The ability to resume and continue conversations is fundamental to our workflow, and losing access to all historical context after a routine re-authentication is a significant blocker for team collaboration.

We would greatly appreciate any guidance on how to restore access to these conversations, or confirmation that a fix is forthcoming.