Gemini 4 Argon frequently takes several minutes to answer a simple “hi”, or fails with a stream timeout, despite being on the Google AI Ultra 20x subscription tier with abundant quota. This affects Antigravity App, Antigravity IDE, and the agy CLI, including Low reasoning mode.
Environment
Subscription Tier: Google AI Ultra (20x plan, abundant quota remaining)
Antigravity App: 2.29.1
Antigravity IDE: 2.6.0 stable
agy CLI: 1.5.3
OS: Rocky Linux 9.8, x86_64
Observed Behavior on November 8, 2026 (all times UTC+08:00)
App, Gemini 4 Argon Medium: Sent "hi" at 21:37:07. A subsequent generation response was logged at 21:39:42, about 156 seconds later. The completed answer was only "Hi! How can I help you today?"
CLI, Gemini 4 Argon Low: Sent "hi" at 21:31:14. At 21:36:14, the client logged: stream idle timeout (5m0s): context deadline exceeded
It then retried.
Control Test (Gemini 3.8 Flash Low): A separate control request returned "OK" in 2.431 seconds on the exact same machine and network connection. However, earlier Flash requests also intermittently returned: INTERNAL (code 500): Internal error encountered.
Steps to Reproduce
Open Antigravity App and start a new conversation.
Select Gemini 4 Argon (Medium).
Send only "hi", without requesting tools or file operations.
Observe the time until the assistant’s text appears. In my test, this took approximately 2–3 minutes.
Repeat in the agy CLI with Gemini 4 Argon (Low). In my test, no answer arrived before the client’s five-minute stream idle timeout.
Compare with Gemini 3.8 Flash (Low), which completed a separate simple control request in about 2.4 seconds.
Expected Behavior
A simple greeting on an AI Ultra 20x account should receive a prompt response without multi-minute stalls or repeated timeouts.
Server Logs: I have already submitted the full Antigravity server logs via the in-app Give Feedback (Bug Report) tool under my account email.
The root cause has not been isolated. Short connectivity tests succeeded, but intermittent issues cannot be ruled out. Please trace these requests and investigate whether the delay occurs in client handling, backend queuing, model processing, or streaming delivery.
Same pattern here, with a few additional data points that may help narrow the routing question.
On my account (same machine, same network, Windows 10, App 2.29.0):
Gemini 4 Argon (Low and Medium): every turn hangs. The client aborts at exactly 5m00s after send with zero bytes received — stream idle timeout (5m0s): context deadline exceeded. Occasional wsarecv: ... forcibly closed by the remote host or EOF around the 2-minute mark.
Gemini 3.8 Flash, same minute, same account: completes normally.
One Argon (Low) turn did eventually complete: 43 seconds for 49 output tokens.
Network is not the variable. Through the same tunnel, in the same window: a 13.1 MB file from a Google host downloads in 1.58 s (≈5.1 MB/s); a 524 KB POST to daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent completes in 0.60 s (≈875 KB/s); TLS handshake 0.23 s; 112 ms RTT.
I also tried the app.asar workaround (spawn --cloud_code_endpoint ``https://cloudcode-pa.googleapis.com). The running process command line confirmed the production URL, yet the language server still issued requests to daily-cloudcode-pa.googleapis.com/v1internal:streamGenerateContent, so it appears that flag is ignored for v1internal:* calls and the host is fixed inside language_server.exe.
Further inspection of the backend logs on both Antigravity Desktop App (2.29.1) and Antigravity IDE (2.6.0) confirms the exact root cause of the current failures:
HTTP 503 (No capacity available) on gemini-3.8-flash-high:
Both the Desktop App and IDE backends explicitly logged HTTP 503 indicating no available capacity for gemini-3.8-flash-high. All subsequent client retries failed with the same error.
HTTP 500 (Internal Error):
Prior to the continuous 503 capacity errors, the IDE backend also recorded HTTP 500 internal server errors from the upstream service.
This confirms that the issue is not isolated to Gemini 4 Argon stream timeouts, but is a broader upstream capacity exhaustion / cluster degradation affecting multiple reasoning models (Argon and gemini-3.8-flash-high) for AI Ultra 20x accounts. Please escalate this to the backend infrastructure / SRE team for capacity reallocation.
Passing --cloud_code_endpoint with cloudcode-pa.googleapis.com in app.asar still routes to daily-cloudcode-pa.googleapis.com because (*HostAuthProvider).UpdateEndpointURL (and (*CLIAuthProvider).UpdateEndpointURL) inside the language_server binary overwrites configCloudCodeURL after OAuth tier resolution.
Specifically, UpdateEndpointURL only preserves --cloud_code_endpoint as a custom override when the string matches neither the 41-byte daily-cloudcode-pa.googleapis.com URL nor the 35-byte cloudcode-pa.googleapis.com URL. Because the standard production URL matches the built-in 35-byte constant, UpdateEndpointURL treats it as a non-custom default; as soon as LoadCodeAssist resolves a consumer Google One AI Ultra token (usesGcpTos == false), it resets the active endpoint back to daily-cloudcode-pa.googleapis.com.
However, at the entry of UpdateEndpointURL (before checking configCloudCodeURL or usesGcpTos), the Go binary checks os.Getenv("CLOUD_CODE_URL") and logs [AuthProvider] UpdateEndpointURL called with CLOUD_CODE_URL. Setting that environment variable before launching the app or CLI locks v1internal:streamGenerateContent onto the production front-end without modifying app.asar:
# Windows (PowerShell) - Launch Antigravity App or agy CLI locked to production cloudcode-pa
$env:CLOUD_CODE_URL = "https://cloudcode-pa.googleapis.com"
& "$env:LOCALAPPDATA\Programs\Antigravity\Antigravity.exe"
# Linux (Rocky Linux / bash) - Launch Antigravity App or agy CLI locked to production cloudcode-pa
export CLOUD_CODE_URL="https://cloudcode-pa.googleapis.com"
agy
Alternatively, if passing --cloud_code_endpoint on the command line, appending the explicit port (:443, making the URL 39 bytes instead of 35 bytes) bypasses the 35-byte equality check and triggers [AuthProvider] UpdateEndpointURL skipping update for custom configCloudCodeURL.
Note the boundary condition: locking the endpoint to cloudcode-pa.googleapis.com eliminates daily-cloudcode-pa preprod gateway stalls, but when the upstream Gemini 4 Argon or gemini-3.8-flash-high serving cluster itself returns HTTP 503 (No capacity available), that is server-side TPU pool exhaustion requiring upstream capacity allocation rather than a client transport fix.
We tried to reproduce the multi-minute stalls and timeouts you saw on November 8 with Gemini 4 Argon, but the behavior didn’t reproduce on our end.
That said, waiting over two minutes for a simple “Hi! How can I help you today?” on Gemini 4 Argon (Medium) or hitting the 5-minute stream idle timeout (5m0s): context deadline exceeded on Gemini 4 Argon (Low) definitely isn’t expected behavior on an AI Ultra plan. That five-minute timeout is just the client’s safety cutoff when no response chunks arrive in time, and your 2.4-second Gemini 3.8 Flash control test on the exact same Rocky Linux setup confirms your local machine, network, and account access are healthy. Both the Argon stalls and the earlier intermittent INTERNAL (code 500) errors on Flash point to transient server-side hiccups at the time rather than anything wrong locally—so reinstalling or resetting your account won’t change that state.
Here are a few practical workarounds you can use right away if you run into this again:
Update Antigravity App from 2.29.1 to the latest release (v2.31.0) and update agy CLI from 1.5.3 to v1.5.5 (your Antigravity IDE 2.6.0 is already on the latest version).
When Gemini 4 Argon stalls or hits a 500 error, switch models in the model selector—on Google AI Ultra you can use Gemini 3.8 Flash for fast turnarounds, or switch to Gemini 4 Carbon, Claude Sonnet 5.5 (thinking), or Claude Opus 5.5 (thinking).
Keep reasoning effort on Low for quick prompts and start a fresh conversation if a stream hangs past the timeout, since retrying on a stuck stream often clears transient backend stalls.
If the multi-minute delays or timeouts start reproducing consistently after updating to App v2.31.0 and agy CLI v1.5.5, please share fresh terminal reproduction logs and the exact error output so we can take another look.
Over a 3-day period, I ran heavy multi-agent workflows and consumed roughly 2 billion tokens. Shortly afterward, I noticed a drastic spike in TTFT (initial prefill / waiting time before the first token arrives)—even on brand-new chats with simple prompts. However, once the first token finally arrives, the streaming/decode speed (TPS) is completely normal.
Why This Doesn’t Look Like Temporary Peak Load:
This issue has persisted for over 24 hours now without recovering, even after pausing my heavy workflows.