Problem Description
I’m using Antigravity 1.107.0 on Windows with WSL2 (Ubuntu). When running Antigravity directly on Windows (local workspace), everything works perfectly — all models respond normally. However, when I connect to WSL via the Remote extension, every single model fails with the following error:
HTTP 503 Service Unavailable
{
“error”: {
"code": 503,
"details": \[
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"domain": "cloudcode-pa.googleapis.com",
"metadata": {
"model": "gemini-3.1-pro-high"
},
"reason": "MODEL_CAPACITY_EXHAUSTED"
}
\],
"message": "No capacity available for model gemini-3.1-pro-high on the server",
"status": "UNAVAILABLE"
}
}
This error occurs for all models (Gemini, Claude, etc.), not just a specific one. Switching models does not help.
Environment
-
OS: Windows 11 + WSL2 (Ubuntu)
-
Antigravity Version: 1.107.0 (commit
62335c71d47037adf0a8de54e25) -
Connection: Antigravity on Windows → Remote WSL extension → WSL2 Ubuntu
Root Cause Analysis
After extensive debugging, I found that the issue is not related to actual model capacity — it is caused by the WSL remote session hitting the wrong API endpoint.
When Antigravity connects to WSL, the language server process on the WSL side is launched with:
--cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com
This is the daily/staging endpoint, which has very limited (or no) capacity for regular users. In contrast, when running locally on Windows, the correct production endpoint is used:
--cloud_code_endpoint https://cloudcode-pa.googleapis.com
The root cause lies in the URL selection logic inside main.js (the Tws function in the cloudCode.js module):
javascript
function Tws({isDevMode, isGoogleInternal, isGcpTos, isTierGCPTos, cloudCodeUrlOverride}) {
return cloudCodeUrlOverride ||
(isGoogleInternal && isDevMode ? AUTOPUSH_URL :
isGcpTos || isTierGCPTos === true || isTierGCPTos === undefined
? PRODUCTION_URL // “https://cloudcode-pa.googleapis.com”
: DAILY_URL) // “https://daily-cloudcode-pa.googleapis.com” ← BUG
}
When connected to WSL remote, the isGcpTos and isTierGCPTos conditions evaluate differently compared to the local Windows context (possibly due to OAuth token state sync issues in the remote scenario), causing the function to fall through to the DAILY_URL instead of PRODUCTION_URL.
Workaround
Add the following setting to your Windows-side Antigravity user settings file (%APPDATA%\Antigravity\User\settings.json):
json
{
“jetski.cloudCodeUrl”: “https://cloudcode-pa.googleapis.com”
}
This setting is read as cloudCodeUrlOverride in the URL selection function and takes the highest priority, bypassing the faulty conditional logic entirely.
Important: After adding this setting, you must fully restart Antigravity (not just reconnect to WSL) for the change to take effect, since the setting is read by the Windows main process.
Summary
| Scenario | Endpoint Used | Result |
|---|---|---|
| Windows local | cloudcode-pa.googleapis.com (production) |
 Works |
| WSL remote (before fix) | daily-cloudcode-pa.googleapis.com (staging) |
 503 for all models |
| WSL remote (after fix) | cloudcode-pa.googleapis.com (production) |
Works |
This appears to be a bug in the endpoint selection logic when Antigravity operates in a remote (WSL/SSH) context. The isTierGCPTos / isGcpTos state does not propagate correctly to the remote session, causing the daily endpoint fallback to trigger for non-Google-internal users.