Antigravity Can't Connect to Ollama or LM Studio: A Diagnostic Guide

"I selected Ollama in Antigravity's settings, but the agent run dies with connection refused." Almost every Antigravity user who tries local LLMs hits this exact problem. Ollama works on its own. LM Studio works on its own. Antigravity can't reach either. The cause is almost always one of five issues.

This guide walks through the connection failures for both Ollama and LM Studio, sorted by the error you actually see. Everything below comes from the dead ends I personally hit on macOS and Windows.

Step zero: is the local server reachable from outside?

When Antigravity calls a local LLM, it's making an HTTP request — either to the Ollama API or to an OpenAI-compatible endpoint. If the server only listens on localhost, sandboxed Antigravity execution environments may not see it.

For Ollama

Ollama defaults to listening on 127.0.0.1:11434. Depending on Antigravity's setup, this isn't always reachable. Setting OLLAMA_HOST to 0.0.0.0:11434 often resolves it.

# macOS / Linux
launchctl setenv OLLAMA_HOST "0.0.0.0:11434"
ollama serve
 
# Windows (PowerShell)
$env:OLLAMA_HOST = "0.0.0.0:11434"
ollama serve

Caveat: binding 0.0.0.0 exposes Ollama to your local network. Fine on a home LAN, dangerous on cafe Wi-Fi.

For LM Studio

You have to start the Local Server explicitly from the Developer tab. If it's not running, every Antigravity request will refuse the connection.

After starting it, paste the URL it shows you (typically http://localhost:1234) into Antigravity's settings. The port can vary by LM Studio version, so always copy from the actual UI.

Three settings mistakes Antigravity users make

1. Trailing slash on the endpoint URL

This is the single most common trap. Writing http://localhost:11434/ (with the trailing slash) makes the internal URL join produce //api/generate, which returns 404.

The right form is http://localhost:11434 — no trailing slash. Same for LM Studio: http://localhost:1234.

2. Model name typos

When pointing Antigravity at a model installed in Ollama, the name has to exactly match what ollama list shows.

$ ollama list
NAME                    ID              SIZE
gemma4:4b              abc123def       3.2 GB
llama3.2:latest        xyz789ghi       2.0 GB
qwen2.5-coder:7b       def456jkl       4.7 GB

Write gemma4:4b — not gemma4, not Gemma 4, not gemma:4b. Drop the :4b tag and Ollama silently rewrites it to :latest, possibly hitting a different model.

3. Confusing the OpenAI-compatible API with the Ollama-native API

LM Studio exposes an OpenAI-compatible API at /v1/chat/completions, so you select Antigravity's "OpenAI Compatible" provider.

Ollama also exposes /v1/chat/completions, but if you pick Antigravity's dedicated Ollama provider it routes to /api/generate or /api/chat instead. Choose the wrong provider and you'll get errors like "API key required" that don't match your config.

When in doubt:

• LM Studio: pick "OpenAI Compatible". Endpoint: http://localhost:1234/v1. API Key: any string (lm-studio works).
• Ollama: pick the dedicated "Ollama" provider. Endpoint: http://localhost:11434.

When you see CORS errors

If you're using Antigravity in a browser context, you may hit CORS: "No 'Access-Control-Allow-Origin' header" or similar.

Ollama CORS

Ollama 0.3.x and later supports OLLAMA_ORIGINS:

launchctl setenv OLLAMA_ORIGINS "https://antigravity.google.com,http://localhost:*"
ollama serve

Multiple origins go comma-separated. The wildcard * works but is not recommended.

LM Studio CORS

In LM Studio's Local Server panel, enable the "Cross-Origin Resource Sharing (CORS)" checkbox. I lost half an hour to this once.

Firewalls and antivirus

A common Windows-side issue: Windows Defender or third-party antivirus blocks the listening port.

# Run as Administrator
netstat -an | findstr ":11434"
netstat -an | findstr ":1234"

If you don't see LISTENING, suspect the firewall. Add an inbound rule in Windows Defender Firewall.

Timeouts on big models

You can clear all of the above and still get "Read timeout" mid-run. That's not a connection failure — inference simply exceeded the timeout window.

In Antigravity, raise "Request Timeout" to at least 120 seconds (default is 60). For 70B-class local models, the first response taking 90+ seconds is normal.

If memory pressure is causing inference to stall, switch to a smaller quantization (Q4_K_M etc.) or set keep_alive longer so the model stays resident between calls.

A final checklist

In the order you should walk through it:

1. Is the server actually running? (ollama serve / LM Studio Local Server toggle)
2. Endpoint URL has no trailing slash?
3. Model name matches ollama list exactly?
4. Right provider selected? (LM Studio → OpenAI Compatible, Ollama → Ollama)
5. CORS configured to allow Antigravity's origin?
6. Not blocked by Defender or third-party AV?
7. Request Timeout long enough?

What to do first

When you see an error, walk down that list. connection refused is almost always 1 or 2. 404 is 2 to 4. CORS is 5. Read timeout is 7.

Local LLMs come with the price of owning your own OS, firewall, and server config. Get this knowledge in once during your initial setup, and every subsequent model addition or machine migration becomes painless.