[Ultra] Gemini 4 Argon fails in both Antigravity Desktop and CLI, but works on Gemini Web and with a Pro account

Google Antigravity
, , , ,
1

I have reproduced a consistent, account-specific issue with Gemini 4 Argon.

Test results:

  • Google AI Ultra + Gemini Web + Argon: Works normally.

  • Google AI Ultra + Antigravity Desktop + Argon: Hangs.

  • Google AI Ultra + Antigravity CLI 1.5.3 + Argon: Hangs at all effort levels.

  • Google AI Ultra + Antigravity CLI + Flash: Works normally.

  • Google AI Pro + Antigravity CLI + Argon: Works normally on the exact same machine and network.

  • Switching back to Ultra: Argon fails again.

  • Fresh conversations: The problem persists.

Observed error:
stream idle timeout (5m0s): context deadline exceeded

Previous failed trajectory ID:
1bf9169d-4d3b-4b90-a47a-6aa39648*****

This appears to be specific to Gemini Argon requests from my Ultra account through Antigravity’s serving infrastructure.

Please investigate account-specific entitlement mapping, model routing, and backend capacity allocation. Could you also confirm whether this is a known issue affecting Google AI Ultra subscribers?

2

@undowhai When Gemini 4 Argon executes successfully on Gemini Web but fails across both Antigravity Desktop and the CLI on an Ultra tier account, the failure typically stems from local daemon credential caching rather than an upstream model outage.

The Web interface evaluates your Google One / Ultra subscription tier in real time via session cookies. In contrast, Antigravity Desktop and the CLI interact with the developer gateway via an ephemeral OAuth token stored in your local configuration directory (~/.gemini/antigravity/ on macOS/Linux or %USERPROFILE%\.gemini\antigravity\ on Windows). When an account upgrades or changes tier allocations, the local daemon often retains the older token claims until explicitly purged.

To isolate this systematically:

  1. Purge the local daemon token cache: Terminate running Antigravity processes and clear the cached OAuth tokens in your configuration directory, then re-authenticate using the CLI:

    agy auth logout
agy auth login

  2. Verify active model descriptor resolution: Check that the CLI runtime maps the model identifier to the Ultra endpoint rather than the preview fallback:

    agy models list

  3. Inspect gateway payload timeout boundaries: In multi-turn execution, Gemini 4 Argon can hit client-side socket timeouts if your local environment passes unconstrained workspace file trees. If the daemon process hangs before emitting chunks, enforcing bounded turn execution and process watchdogs resolves the stall.

I documented the architectural invariants for workspace guardrails and timeout-guarded sub-millisecond tool execution in RFC-001 (Autonomous Developer Workbench Guard).

3

Same here - Ultra subscriber, and this is seriously impacting my work. The desktop app fails with server not responding while Gemini on the web works fine. An official acknowledgment and ETA would be appreciated.

4

Update – November 9, 2026: Issue Has Returned — OAuth/Cache Workaround Did Not Help

@dllhell Thank you for your suggestions and assistance.
I tested the recommended authentication and local cache troubleshooting steps. Unfortunately, none of these methods resolved the issue.

  1. Current Observations

  • Google AI Ultra + Gemini 4 Argon: Still fails across all effort levels.

  • Antigravity Desktop & CLI: Both are affected.

  • Error behavior: Requests remain stuck on “Loading” or “Working” for extended periods, sometimes displaying “Model Invalid”.

  • Gemini 3.8 Flash: Continues to work normally.

  • Gemini Web: Gemini 4 Argon works normally on gemini.google.com using the same Ultra account.

  • Google AI Pro comparison: Argon works successfully with a Pro account on the exact same machine, network, and CLI installation.

  • Fresh conversations: The issue persists even in completely new sessions.

  • OAuth/cache troubleshooting: Already tested as suggested in reply #2, without success.

2. Important Finding: Intermittent Recovery and Recurrence

Approximately 2–3 hours after my initial report on November 8, Gemini 4 Argon unexpectedly started working again on my Ultra account.

However, the exact same issue returned on November 9.

This intermittent behavior, combined with the successful Pro account comparison, suggests a possible issue involving:

  • Account-specific backend model serving or request routing.

  • Google AI Ultra subscription entitlement synchronization.

  • Backend capacity allocation for Gemini 4 Argon.

These are potential causes rather than confirmed findings. The available evidence does not currently point to a simple local credential cache issue.
3. Request for Engineering Investigation
Could the Antigravity engineering team please investigate the server-side request logs using my previously provided Trajectory ID?
In particular, it would be helpful to verify whether Gemini 4 Argon requests from my Ultra account are being routed correctly and whether any account-specific entitlement or capacity issues are occurring.
I am a paying Google AI Ultra subscriber, and these recurring outages are significantly affecting my development workflow.
I would greatly appreciate an official acknowledgment, technical investigation, and update on the issue’s status.
Thank you for your time and assistance.

5

@undowhai Appreciate you testing those local steps and sharing the follow-up telemetry.

Your two new findings - that a Pro account succeeds on the identical workstation and binary, and that your Ultra account spontaneously recovered for 2 to 3 hours on November 8 before relapsing on November 9 - conclusively rule out any local client, network, or credential-cache fault.

Why there is no client-side fix from here:

  1. Gateway vs Web Routing: Unlike gemini.google.com (which uses the consumer web serving stack), both Antigravity Desktop and the agy CLI route traffic through daily-cloudcode-pa.googleapis.com by design.
  2. Server-Side Tier & Regional Sharding: On daily-cloudcode-pa.googleapis.com, Argon requests are partitioned into separate backend capacity and entitlement pools by subscription tier (AI Ultra vs AI Pro) and account region. When a specific Ultra shard experiences upstream capacity exhaustion (HTTP 503: No capacity available) or an entitlement-routing fault ("Model Invalid"), the stream stalls server-side until the client’s 5-minute (5m0s) deadline expires, whereas the Pro pool on the same host responds normally.

Because endpoint routing and tier pool assignments are enforced entirely on Google’s backend, no local configuration can bypass a degraded Ultra shard. This requires server-side investigation by the Antigravity engineering team using your Trajectory ID (1bf9169d-4d3b-4b90-a47a-6aa39648*****). Including your account’s country/region helps the team isolate the specific regional Ultra pool faster.

6

Hi @undowhai and thanks @ilaykid for confirming you see the same thing.

Thank you for the careful testing. Argon works with a Pro account on the same machine, network and CLI 1.5.3. Gemini 3.8 Flash works on your Ultra account, and Argon briefly started working again on its own. Together, that rules out your local setup, so you don’t need to repeat any sign-out or cache steps. (For anyone reading later: you sign out of the Antigravity CLI with /logout inside agy. agy auth logout and agy models list are not Antigravity CLI commands)

What’s happening

stream idle timeout (5m0s): context deadline exceeded means the client got no data from the model for five minutes and stopped waiting. We’re looking into reports of Argon requests stalling in Antigravity, including yours. The part specific to your Ultra account (Argon stalling or showing “Model Invalid” while Pro and Flash respond) needs to be investigated. I’ve passed your comparison results to the team. I can’t confirm how serving capacity is allocated between plans or regions, so please treat the explanations earlier in this thread as unconfirmed.

In the meantime

  • Switch models using the model selector under the prompt box. Gemini 3.8 Flash, Claude Sonnet 5.5 (thinking) and Claude Opus 5.5 (thinking) are all included with Google AI Ultra. If Gemini 4 Carbon appears (added for Ultra on November 10), you can try that too.
  • If you do use Argon on Ultra, start a fresh conversation and keep each request small (for example, one file per step). This may help with some timeouts, but it probably won’t help with “Model Invalid”.
  • If you use the App, update to v2.31.0. It fixes requests failing when a thinking model takes more than a minute to start responding.

To help the investigation

Please reply here with the following, with any tokens, email addresses or other sensitive details removed:

  • Approximate times, with time zone of a few failed Argon requests, including one that showed “Model Invalid” (the exact text or a screenshot helps).
  • The country each account (Ultra and Pro) is associated with.
  • The matching error lines from your newest log file:
    • App: ~/.gemini/antigravity/log/ (Windows: %USERPROFILE%\.gemini\antigravity\log\)
    • CLI: ~/.gemini/antigravity-cli/log/cli-*.log (Windows: %USERPROFILE%\.gemini\antigravity-cli\log\cli-*.log)

@ilaykid, the same details from you would help too.