[Bug] Remote servers (SSH/WSL) using staging endpoint daily-cloudcode-pa instead of production — Fix included

Romualdo_Mathias_Fil · April 13, 2026, 3:12am

[BUG] Antigravity Remote Servers Using Staging Endpoint (`daily-cloudcode-pa`) Instead of Production — Causing Persistent 503 Errors

Product: Antigravity (IDE)
Version: v1.107.0 (Server component v1.22.2)
Affected: All remote connections — SSH, WSL, Remote Tunnels (Linux servers)
Not affected: Local desktop (Windows/macOS) — uses correct production endpoint
Severity: Critical — renders AI features completely unusable on remote servers
Date discovered: April 10, 2026

TL;DR

Antigravity on remote servers (SSH, WSL) is pointing to Google’s staging/daily testing endpoint (daily-cloudcode-pa.googleapis.com) instead of the production endpoint (cloudcode-pa.googleapis.com). This causes HTTP 503 MODEL_CAPACITY_EXHAUSTED errors on every model (Gemini, Claude, etc.), because the staging environment has minimal capacity. The same account, on the local machine, works perfectly.

The Problem in Detail

What happens

When using Antigravity on any remote server via SSH or WSL, all AI interactions fail with:

Error: HTTP 503 Service Unavailable

{

“error”: {

"code": 503,

"details": \[{

  "@type": "type.googleapis.com/google.rpc.ErrorInfo",

  "domain": "cloudcode-pa.googleapis.com",

  "metadata": { "model": "..." },

  "reason": "MODEL_CAPACITY_EXHAUSTED"

}\],

"message": "No capacity available for model \[any model\] on the server",

"status": "UNAVAILABLE"

}

The error occurs with every model — Gemini 3.1 Pro, Claude Opus 4.6, Gemini Flash, etc. On the local desktop, the same model, same account, same network works normally.

Root Cause: “The Test Gate” (Staging vs. Production)

Google has two gateways for the Antigravity AI API:

Endpoint	Purpose	Capacity
`cloudcode-pa.googleapis.com`	Production — massive cluster backed by thousands of GPUs, designed to handle worldwide traffic	High
`daily-cloudcode-pa.googleapis.com`	Staging (Daily Testing) — smaller internal environment used by Google engineers to test new code	Minimal

The language_server_linux_x64 binary (the Go service that makes AI calls) is being launched with the argument:

--cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com

Instead of the correct:

--cloud_code_endpoint https://cloudcode-pa.googleapis.com

The Evidence

Process on the remote server (wrong):

bash

$ ps aux | grep language_server | grep -o “cloud_code_endpoint [^ ]*”

cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com ← STAGING!

Logs confirming calls to the wrong endpoint:

URL: https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist

URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels

On the local machine (works fine):

Uses cloudcode-pa.googleapis.com (production)
Same version, same account, same network

Why does this happen?

The Antigravity extension’s extension.js sets the daily-cloudcode-pa endpoint as the default for the remote Linux component. In the IDE’s ecosystem, WSL and SSH servers are treated as Remote Servers, and it’s precisely this remote component that receives the wrong URL.

Detailed investigation:

bash

# The daily-cloudcode string is HARDCODED in the Go binary:

$ grep -rl “daily-cloudcode” /path/.antigravity-server/bin/*/extensions/antigravity/

…/extensions/antigravity/bin/language_server_linux_x64 ← In the binary!

# And is passed as an argument by extension.js:

$ grep -rl “cloud_code_endpoint” /path/.antigravity-server/bin/*/extensions/antigravity/ --include=“*.js”

…/extensions/antigravity/dist/extension.js

# Product.json says “stable” — it’s NOT a test build:

$ cat …/product.json | grep quality

“quality”: “stable”

Even though it’s a "quality": "stable" build, the endpoint points to staging.

The Solution: The Wrapper

The solution uses a classic Unix concept called a Wrapper. It’s elegant because it doesn’t try to crack the compiled executable or make dangerous modifications.

How it works:

BEFORE (with bug):

Extension.js → language_server_linux_x64

              --cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com

                                                ↓

                                      ❌ Staging (no capacity)

                                                ↓

                                      HTTP 503 UNAVAILABLE

AFTER (with wrapper):

Extension.js → wrapper.sh (our script)

              --cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com

                ↓

                replaces "daily-cloudcode-pa" → "cloudcode-pa"

                ↓

           language_server_linux_x64.orig

              --cloud_code_endpoint https://cloudcode-pa.googleapis.com

                                                ↓

                                      ✅ Production (capacity OK)

                                                ↓

                                      HTTP 200 OK

Step by step:

Finds the original Google executable (language_server_linux_x64) and renames it to .orig, keeping it safe
Creates a new file in its place that acts as an “interceptor”
Every time the IDE sends the command “Start the AI server pointing to daily-cloudcode…”, the interceptor catches it, removes the daily- prefix, and forwards the clean command to the original binary
The sed at the end acts as a double safety net, scanning the extension’s JavaScript files to replace any mention of the wrong server

Fix Script — Copy and Paste

Run this in the LINUX terminal on the remote server (SSH or WSL), NOT in Windows PowerShell.

bash

#!/bin/bash

# ============================================================

# FIX: Antigravity 503 - Switch endpoint from staging to production

# Bug: language_server uses daily-cloudcode-pa (staging)

# instead of cloudcode-pa (production)

# ============================================================

echo “ Searching for Antigravity installations…”

# Auto-detect base directory

BASE_DIR=“”

for candidate in “$HOME/.antigravity-server” “/root/.antigravity-server”; do

if [ -d “$candidate/bin” ]; then

BASE_DIR=“$candidate”

break

fi

done

if [ -z “$BASE_DIR” ]; then

echo “ Antigravity directory not found!”

echo " Searched in: ~/.antigravity-server and /root/.antigravity-server"

exit 1

fi

echo “ Base found: $BASE_DIR”

FIXED=0

SKIPPED=0

# Apply fix to ALL installed versions

for BIN_DIR in $(find “$BASE_DIR/bin/” -path “*/extensions/antigravity/bin” -type d 2>/dev/null); do

if [ ! -f “$BIN_DIR/language_server_linux_x64” ]; then

continue

fi

# Check if already applied

if [ -f “$BIN_DIR/language_server_linux_x64.orig” ]; then

echo “ Already applied: $(basename $(dirname $(dirname $(dirname $BIN_DIR))))”

SKIPPED=$((SKIPPED + 1))

continue

fi

# Check if it’s a binary (not already a wrapper)

FILE_TYPE=$(file “$BIN_DIR/language_server_linux_x64” | grep -c “ELF”)

if [ “$FILE_TYPE” -eq 0 ]; then

echo “ Not an ELF binary (may already be a wrapper): $(basename $(dirname $(dirname $(dirname $BIN_DIR))))”

SKIPPED=$((SKIPPED + 1))

continue

fi

# Rename original binary

mv “$BIN_DIR/language_server_linux_x64” “$BIN_DIR/language_server_linux_x64.orig”

# Create wrapper

printf ‘#!/bin/bash\nARGS=“${@//daily-cloudcode-pa.googleapis.com/cloudcode-pa.googleapis.com}”\nexec “$(dirname “$0”)/language_server_linux_x64.orig” $ARGS\n’ > “$BIN_DIR/language_server_linux_x64”

chmod +x “$BIN_DIR/language_server_linux_x64”

VERSION=$(basename $(dirname $(dirname $(dirname “$BIN_DIR”))))

echo “ Fix applied: $VERSION”

FIXED=$((FIXED + 1))

done

# Double safety: also fix extension.js in all versions

for EXT_JS in $(find “$BASE_DIR/bin/” -path “*/extensions/antigravity/dist/extension.js” 2>/dev/null); do

sed -i ‘s|daily-cloudcode-pa\.googleapis\.com|cloudcode-pa.googleapis.com|g’ “$EXT_JS”

done

echo “”

echo “=========================================”

echo " Results:"

echo " Fixed: $FIXED"

echo " Already applied/skipped: $SKIPPED"

echo “=========================================”

echo “”

if [ $FIXED -gt 0 ] || [ $SKIPPED -gt 0 ]; then

echo “ Killing Antigravity processes…”

pkill -f antigravity-server 2>/dev/null

pkill -f language_server_linux_x64 2>/dev/null

echo “”

echo “ FIX APPLIED!”

echo “”

echo " Next steps:"

echo " 1. Close the remote window in Antigravity (desktop)"

echo " 2. Reconnect to the server"

echo " 3. Verify with: ps aux | grep language_server | grep -o ‘cloud_code_endpoint [^ ]*’"

echo " 4. Should show: cloud_code_endpoint https://cloudcode-pa.googleapis.com"

else

echo “ No installations found to fix.”

fi

How to Revert (When Google Fixes This)

When an official Antigravity update fixes this bug, revert the wrapper:

bash

#!/bin/bash

# Revert fix: restore original binaries

BASE_DIR=“”

for candidate in “$HOME/.antigravity-server” “/root/.antigravity-server”; do

\[ -d "$candidate/bin" \] && BASE_DIR="$candidate" && break

done

[ -z “$BASE_DIR” ] && echo “ Not found” && exit 1

for BIN_DIR in $(find “$BASE_DIR/bin/” -path “*/extensions/antigravity/bin” -type d 2>/dev/null); do

if [ -f “$BIN_DIR/language_server_linux_x64.orig” ]; then

rm “$BIN_DIR/language_server_linux_x64”

mv “$BIN_DIR/language_server_linux_x64.orig” “$BIN_DIR/language_server_linux_x64”

echo “ Restored: $(basename $(dirname $(dirname $(dirname $BIN_DIR))))”

fi

done

pkill -f antigravity-server 2>/dev/null

echo “ Reconnect from the desktop to apply”

How to check if you still need the fix:

bash

# Check if the wrapper is active

file $(find ~/.antigravity-server/bin/ -name “language_server_linux_x64” ! -name “*.orig” | head -1)

# “ASCII text” → wrapper active (fix applied)

# “ELF 64-bit” → original binary (no fix)

Servers Where the Fix Was Confirmed

The fix was tested and confirmed successfully on multiple remote environments:

Server	Type	OS	User	Antigravity Path	Status
HOME	Direct SSH	Debian	`root`	`/root/.antigravity-server/`	Fixed
SANA-CORE	SSH (via Proxmox)	Debian	`contato`	`/home/contato/.antigravity-server/`	Fixed
WSL	WSL2	Ubuntu	`alexsandro`	`/home/alexsandro/.antigravity-server/`	Fixed

Note: The path varies depending on the system user. The fix script auto-detects $HOME/.antigravity-server or /root/.antigravity-server.

All servers exhibited the same behavior:

Before fix: cloud_code_endpoint https://daily-cloudcode-pa.googleapis.com → 503 on all models
After fix: cloud_code_endpoint https://cloudcode-pa.googleapis.com → working normally

Important Notes

Fix Safety

The wrapper does not alter any data or Antigravity settings
The original binary is preserved as .orig — can be restored at any time
The script only intercepts a command-line argument, without modifying the executable
Safe to apply — the logic is simple and deals exclusively with network routing

When to Reapply

The fix needs to be reapplied if Antigravity updates and installs a new server version (new directory under bin/)
Check periodically if a new directory appeared (e.g., 1.23.0-* instead of 1.22.2-*)
Tip: The fix script already applies to all versions found, so just run it again after each update

How to Detect if the Bug Returns

bash

# Run this command on the remote server:

ps aux | grep language_server | grep -o “cloud_code_endpoint [^ ]*”

# If it shows daily-cloudcode-pa → needs the fix

# If it shows cloudcode-pa → it’s OK

Test Environment

Item	Value
Desktop	Windows 11, Antigravity v1.107.0
SSH Server (HOME)	Debian, root, IP 192.168.1.200
SSH Server (SANA-CORE)	Debian (Proxmox VM), contato
WSL	Ubuntu (WSL2), alexsandro
Models tested	Gemini 3.1 Pro High, Claude Opus 4.6 Thinking
Network	Same local network, same ISP, same Google account
Server component version	v1.22.2 (commit 62335c71d4)

Final Words

We were pointing to a daily test environment at Google, not production. The endpoint daily-cloudcode-pa.googleapis.com is a smaller internal environment used by engineers to test new code — its processing capacity is minimal. Meanwhile, the local machine (Windows/macOS desktop) was using the correct endpoint cloudcode-pa.googleapis.com and working perfectly fine.

The wrapper fix is safe, non-invasive, and resolves the problem immediately. We hope Google fixes this in a future update, but until then, this workaround keeps everything running.

If you’re experiencing the same persistent 503 error on remote servers: the problem is NOT your network, NOT your account, and NOT a real lack of capacity — it’s simply the wrong endpoint being used by Antigravity’s remote component.

Tags: bug 503 MODEL_CAPACITY_EXHAUSTED remote-ssh wsl daily-cloudcode-pa staging-endpoint

Topic		Replies	Views
[FIX] 503 MODEL_CAPACITY_EXHAUSTED on remote servers (SSH / WSL / Tunnels) — Staging endpoint bug + permanent workaround Google Antigravity bug , models , gemini	0	232	April 17, 2026
[Bug] Antigravity returns HTTP 503 MODEL_CAPACITY_EXHAUSTED for all models when connected to WSL Google Antigravity bug	10	1795	April 19, 2026
[Critical Bug] Antigravity Remote Agent Crash: Command Not Found & Language Server Timeout in SSH Environment Google Antigravity bug	0	22	May 18, 2026
Bug Report: Antigravity Returns HTTP 503 MODEL_CAPACITY_EXHAUSTED for All Models When Connected to WSL Google Antigravity bug	0	129	April 13, 2026
Remote SSH + Antigravity / Google Code Assist? Google Antigravity bug , gemini	4	2191	February 24, 2026

[Bug] Remote servers (SSH/WSL) using staging endpoint daily-cloudcode-pa instead of production — Fix included

[BUG] Antigravity Remote Servers Using Staging Endpoint (daily-cloudcode-pa) Instead of Production — Causing Persistent 503 Errors

TL;DR

The Problem in Detail

What happens

Root Cause: “The Test Gate” (Staging vs. Production)

The Evidence

Why does this happen?

The Solution: The Wrapper

How it works:

Fix Script — Copy and Paste

How to Revert (When Google Fixes This)

How to check if you still need the fix:

Servers Where the Fix Was Confirmed

Important Notes

Fix Safety

When to Reapply

How to Detect if the Bug Returns

Test Environment

Final Words

Related topics

[BUG] Antigravity Remote Servers Using Staging Endpoint (`daily-cloudcode-pa`) Instead of Production — Causing Persistent 503 Errors