Running a local LLM inside Antigravity is increasingly popular — privacy-sensitive work and solo developers watching their API spend both end up here. LM Studio's UI is friendlier than Ollama's, so more people are choosing it, and more people are hitting the same three symptoms: "model list is empty", "connection times out", "stream cuts mid-response."
I've done this dance enough times in my own projects to recognize the underlying pattern: almost all of these failures come from not identifying the right layer before changing settings. Port? CORS? Model-load state? They look similar from the outside, and twiddling settings randomly tends to move you further from a fix. This guide walks the three layers in order with the exact commands to verify each one.
Start with "is LM Studio's server actually healthy?"
Before touching any Antigravity setting, confirm LM Studio is running as an OpenAI-compatible server.
In LM Studio, open the Developer tab on the left. The "OpenAI Compatible Server" toggle should be Started. Default port is 1234, default endpoint is http://localhost:1234/v1.
The fastest health check is hitting it directly from the terminal:
curl http://localhost:1234/v1/modelsA healthy server returns a JSON list of currently loaded models. If data is empty ({"data": []}), the server is up but has no model loaded — jump to "model visibility." If the connection itself is refused, it's a port/firewall issue.
Symptom 1: Antigravity's model list is empty
You've set the LM Studio endpoint in Antigravity, but the model dropdown stays empty. Three likely causes:
A. No model is loaded in LM Studio
LM Studio distinguishes "downloaded models" from "currently loaded models." The server returns only what's currently in memory.
In LM Studio's "My Models", pick a model and click Load. Once loaded, trigger "Refresh models" in Antigravity's settings (or reload the model list).
B. The endpoint URL is missing /v1
http://localhost:1234 won't work — you need the OpenAI-compatible suffix: http://localhost:1234/v1. Easy to miss on first setup.
C. Loopback address mismatch
localhost, 127.0.0.1, 0.0.0.0 — whichever LM Studio is bound to must match what Antigravity uses. Check LM Studio's "Server Host" and use exactly that in Antigravity. If LM Studio is on 127.0.0.1, write http://127.0.0.1:1234/v1, not localhost. Hostname resolution adds a layer that sometimes breaks depending on OS and network stack.
Symptom 2: Connected, but streams cut mid-response
The model list resolves, the first few tokens arrive, then the stream dies partway through a long response. This is almost always either LM Studio's context length or Antigravity's stream timeout.
In LM Studio's Server tab, check the model's Context Length setting. If the loaded context is smaller than what the model supports, long conversations or whole codebases can wedge mid-response. Raise it to what the model can handle.
On Antigravity's side, local LLM endpoints have a stream read timeout. If long generation is cutting frequently, extend it in .antigravity/config.toml or the Advanced settings UI.
Symptom 3: CORS errors from the Web version of Antigravity
If you're on web-based Antigravity and see CORS preflight errors in DevTools, LM Studio's server has CORS disabled by default.
Enable the CORS toggle in LM Studio's Server settings and restart the server.
Security note: shipping direct browser → local LLM calls in production is a bad idea. Prefer Antigravity desktop or a server-side proxy. CORS-open is reasonable for local dev only.
Symptom 4: Works everywhere except Windows
Windows Defender Firewall silently blocks LM Studio's port. First launch normally prompts you to allow access — if you dismissed or denied it, nothing after works.
Windows Security → Firewall & network protection → "Allow an app through firewall" — verify LM Studio is enabled and, crucially, that "Private" is checked. Restart.
If you run Antigravity inside WSL and LM Studio on the Windows host, localhost won't reach it. Use host.docker.internal or the Windows host's actual IP. This trips up people coming from Linux / macOS.
Symptom 5: Metal acceleration isn't kicking in on Mac
Apple Silicon should be fast, but if inference is crawling, check LM Studio's Settings → Hardware. Metal should be enabled, and n_gpu_layers should be at or near max (-1 means all layers). Leaving it near 0 runs inference on CPU only — that's your culprit.
Recovery checklist
Walk this in order the next time LM Studio and Antigravity won't talk:
- Is LM Studio's server in the Started state?
- Does
curl http://localhost:1234/v1/modelsreturn a list? - Is a model actually loaded in memory?
- Does your endpoint URL end with
/v1? - Does the loopback address (
localhost/127.0.0.1/0.0.0.0) match on both sides? - On Windows, is LM Studio allowed through the firewall?
- On Web Antigravity, is CORS enabled in LM Studio?
- For cut streams, are Context Length and stream timeout both generous enough?
Run through these before you touch anything else. The fix is almost always one specific layer — don't change all of them at once, because you'll lose track of what worked.