AI Features Not Working on Remote Servers? Here’s the Fix (503 / MODEL_CAPACITY_EXHAUSTED)
If you use Antigravity connected to a remote Linux server via SSH, WSL, or Remote Tunnels, and your AI features suddenly stopped working, this guide explains why it happens and how to fix it in under a minute.
Symptoms
Every AI model (Gemini, Claude, etc.) fails with:
Error: HTTP 503 Service Unavailable
“message”: “No capacity available for model [any model] on the server”
“reason”: “MODEL_CAPACITY_EXHAUSTED”
And yet, the exact same account works perfectly on your local machine (Windows/macOS). Nothing changed — no updates, no quota issues, no network problems.
What’s Actually Going On?
This is a routing bug in Antigravity’s remote component.
Google has two separate API gateways for AI features:
| Endpoint | Purpose | Capacity |
|---|---|---|
cloudcode-pa.googleapis.com |
Production — handles worldwide traffic | |
daily-cloudcode-pa.googleapis.com |
Staging / Daily Testing — internal Google test environment |
When you run Antigravity on a remote Linux server, the extension’s language_server_linux_x64 binary gets launched pointing to the staging (testing) endpoint instead of production. Because thousands of users end up hammering this tiny test server, capacity is immediately exhausted — hence the 503.
It’s not your network. It’s not your account. It’s not a real capacity problem. The IDE is just knocking on the wrong door.
You can verify this yourself on the remote server:
bash
ps aux | grep language_server | grep -o “cloud_code_endpoint [^ ]*”
# If it shows: daily-cloudcode-pa.googleapis.com → you have this bug
# If it shows: cloudcode-pa.googleapis.com → you’re fine
The Fix — A Simple Wrapper Script
The solution is a wrapper: a small script that sits between the extension and the original binary. It intercepts the wrong staging URL, swaps it for the correct production URL, and passes everything else through unchanged.
WARNING
The fix must run on the Linux side — that’s where the Antigravity server files live. See below for both options: running directly on Linux, or triggering the fix from Windows PowerShell.
Paste the entire block below into your Linux terminal and press Enter:
bash
#!/bin/bash
# FIX: Redirect Antigravity remote component from Staging to Production
echo “
Looking for Antigravity installations…”
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!”
exit 1
fi
echo “
Found at: $BASE_DIR”
FIXED=0
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
if [ -f “$BIN_DIR/language_server_linux_x64.orig” ]; then continue; fi
FILE_TYPE=$(file “$BIN_DIR/language_server_linux_x64” | grep -c “ELF”)
if [ “$FILE_TYPE” -eq 0 ]; then continue; fi
# Preserve the original binary and create the wrapper
mv “$BIN_DIR/language_server_linux_x64” “$BIN_DIR/language_server_linux_x64.orig”
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”
FIXED=$((FIXED + 1))
done
# Also patch any hardcoded references in extension.js
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
if [ $FIXED -gt 0 ]; then
pkill -f antigravity-server 2>/dev/null
pkill -f language_server_linux_x64 2>/dev/null
echo “
Fix applied! Processes restarted.”
else
echo “
Nothing to fix — already patched or no installation found.”
fi
After running:
-
Close the remote window in your Antigravity desktop app
-
Reconnect to the server
-
Verify the fix worked:
bash
ps aux | grep language_server | grep -o “cloud_code_endpoint [^ ]*”
# Should now show: cloudcode-pa.googleapis.com ![]()
Running the Fix from Windows PowerShell
NOTE
PowerShell can’t directly edit files on a Linux server. But it can send the fix to Linux via SSH or WSL with one command.
Option A — SSH Server
Open PowerShell and run (replace user@your-server with your credentials):
powershell
ssh user@your-server @’
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
[ ! -f “$BIN_DIR/language_server_linux_x64” ] && continue
[ -f “$BIN_DIR/language_server_linux_x64.orig” ] && continue
file “$BIN_DIR/language_server_linux_x64” | grep -q ELF || continue
mv “$BIN_DIR/language_server_linux_x64” “$BIN_DIR/language_server_linux_x64.orig”
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”
done
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
pkill -f antigravity-server 2>/dev/null
pkill -f language_server_linux_x64 2>/dev/null
echo “Done!”
'@
Option B — WSL
If your Antigravity runs inside WSL, open PowerShell and run:
powershell
wsl bash -c ’
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
[ ! -f “$BIN_DIR/language_server_linux_x64” ] && continue
[ -f “$BIN_DIR/language_server_linux_x64.orig” ] && continue
file “$BIN_DIR/language_server_linux_x64” | grep -q ELF || continue
mv “$BIN_DIR/language_server_linux_x64” “$BIN_DIR/language_server_linux_x64.orig”
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”
done
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
pkill -f antigravity-server 2>/dev/null
pkill -f language_server_linux_x64 2>/dev/null
echo “Done!”
’
After either option, reconnect the remote window in Antigravity on your desktop.
Is This Safe?
-
The original binary is preserved as language_server_linux_x64.orig— nothing is deleted -
The wrapper only intercepts a single command-line argument (the endpoint URL) -
No Antigravity settings, credentials, or project files are modified -
Fully reversible at any time
One Thing to Know
If Antigravity updates and installs a new server version (new folder under ~/.antigravity-server/bin/), the bug may come back. Just run the script again — it’s smart enough to skip already-patched versions and only fix new ones.
Confirmed Working On
| Environment | OS | Status |
|---|---|---|
| SSH (direct) | Debian | |
| SSH (via Proxmox VM) | Debian | |
| WSL2 | Ubuntu | |
| AWS EC2 | Amazon Linux | |
| GCP Compute Engine | Ubuntu |
Models tested: Gemini 3.1 Pro, Claude Opus 4.6 Thinking, Gemini Flash
Hope this helps! Let me know in the comments if it works for you or if you need help.