Plenty of guides walk through connecting Antigravity to a local model. Most of them stop at "it works." Running Antigravity against a local backend for a real workday exposes problems those guides never see — connection drops a couple of times per afternoon, sessions that go unresponsive after lunch when the model unloads, a VRAM crash the moment you open a second tool, and the soul-crushing ten-second spin every time you swap models.
This playbook is the set of patterns I arrived at after six months of Antigravity × local LLM as my daily driver. It is not "how to connect." It is "how to stay connected."
Pick your backend by task, not by loyalty
Antigravity connects to three main local backends: Ollama, LM Studio, and LM Link. The honest answer to "which should I use?" is do not pick one; pick by task type.
Ollama earns its keep when you want scripted, CLI-driven, reproducible setups; run the same model configuration across machines; or need the longest-running stability when sessions stretch into hours.
LM Studio shines when you are in exploration mode — swapping quant levels (Q4_K_M, Q5_K_M, and so on), comparing models visually, or leaning on MLX on Apple Silicon.
LM Link is what you reach for when your inference machine is not your working machine — a beefy Mac at home, a laptop on the road, and a Tailscale tunnel between them.
My own layout: Ollama as primary, LM Studio for experimentation, LM Link when I am away from the inference host. Having all three configured means the day survives any one of them misbehaving.
Five settings that make the connection layer production-grade
1. Timeouts that match your model
Default timeouts are too short for long outputs from large models. In Antigravity's custom endpoint configuration:
{
"name": "local-ollama",
"baseUrl": "http://localhost:11434/v1",
"apiKey": "none",
"timeoutMs": 600000,
"maxRetries": 1,
"streamingEnabled": true
}Three moves: ten-minute timeout; maxRetries: 1 so Antigravity does not retry on top of your agent's own retry behavior; streaming enabled so you can see tokens arriving and distinguish "slow" from "hung."
2. Keep Ollama's model warm
Ollama unloads models five minutes after the last request by default. Come back from lunch and your first prompt pays a cold-load tax. Fix at the server:
export OLLAMA_KEEP_ALIVE=3h
ollama serveIf VRAM is tight, drop to 1h. Anything is better than the default 5m for interactive work.
3. Raise LM Studio's context window
LM Studio often ships with Context Length set to 4096 for a given model. Antigravity in a long agent session will quietly truncate the head of the conversation once you pass that. Raise it to the model's native ceiling:
Model Settings → Context Length → 131072 (example for Gemma 4)
Evaluation Batch Size → 512 (if you have headroom)
4. Put LM Link behind a private mesh
Never expose LM Link to the open internet. Use Tailscale (or WireGuard, or any mesh VPN) so the endpoint is reachable only inside your private network:
tailscale up
# from the client
curl http://<tailscale-hostname>:1234/v1/modelsA public IP is a much bigger footgun than it looks.
5. Compensate with a system prompt
Local models follow instructions less reliably than frontier cloud models. Offset with an explicit system-level behavior policy in Antigravity:
## Behavior policy for this local backend
- Output is always UTF-8 in Japanese or English only.
- Propose code changes as a diff.
- For any change requiring a test, include the test file alongside.
- When writing code that calls an external API, add a "// TODO: verify endpoint" comment.
Variance in output drops noticeably — roughly by half in my experience.
Fallback design: what to do when local goes silent
The one thing every heavy user has in common is: "local stopped responding at 4pm, and I lost half an hour figuring out why." Thermal throttling, VRAM pressure from another process, a hung backend — the cause varies, the fix does not. Build a fallback path on day one.
A minimal two-endpoint config
{
"endpoints": [
{
"name": "primary-local",
"type": "ollama",
"baseUrl": "http://localhost:11434/v1",
"priority": 1,
"healthCheckPath": "/api/version"
},
{
"name": "fallback-cloud",
"type": "anthropic",
"priority": 2,
"triggerOnLocalFailure": true
}
]
}Primary goes to local, fallback goes to a cloud API, automatic switchover on local failure.
Automated health check
A dead-man's-switch script that runs every minute:
#!/usr/bin/env bash
# local_health.sh
set -uo pipefail
LOGFILE="$HOME/.antigravity/health.log"
LOCAL_URL="http://localhost:11434/api/version"
while true; do
TS=$(date -Iseconds)
if curl -fsS --max-time 5 "$LOCAL_URL" >/dev/null 2>&1; then
echo "$TS OK" >> "$LOGFILE"
else
echo "$TS FAIL" >> "$LOGFILE"
curl -s -X POST -H 'Content-Type: application/json' \
-d "{\"text\":\"Local LLM unreachable at $TS\"}" \
"$SLACK_WEBHOOK_URL" >/dev/null 2>&1
fi
sleep 60
doneSilent failures get loud within a minute.
Graceful VRAM degradation
When another heavy process claims GPU memory — video editing, a second model, a training job — Ollama can go unresponsive. Have a second, smaller model ready to take over:
AVAIL_MB=$(nvidia-smi --query-gpu=memory.free --format=csv,noheader,nounits | head -1)
if [ "$AVAIL_MB" -lt 4000 ]; then
ollama stop gemma4:27b 2>/dev/null
ollama run gemma4:9b > /dev/null 2>&1 &
fiOn Apple Silicon, watch vm_stat for swap pressure instead.
Model selection in practice
A configuration I keep coming back to:
- Agent-style code edits — Gemma 4 mid-to-large (9B or 27B), or a Qwen model of similar scale. Consistency matters; 27B is calmer, but below 24 GB VRAM the 9B at Q5 feels better day-to-day.
- Chat and writing — a well-quantized Gemma 4 9B (Q4_K_M). Good balance of speed and coherence; long-form holds up.
- Lightweight tasks — Gemma 4 2B or equivalent tiny. Instant response rewards rapid iteration.
The practical habit: register multiple models in Antigravity and switch by task, instead of forcing one model to be everything. Most "local LLM is unusable" complaints are really "I was asking a 2B model to do architecture work."
The minimum monitoring to set up
Log the response time of a canned prompt daily. When "things feel slow" becomes real, the log is the evidence:
START=$(date +%s%N)
echo "hello" | ollama run gemma4:9b > /dev/null
END=$(date +%s%N)
echo "$(date -Iseconds) gemma4:9b $((($END - $START) / 1000000))ms" \
>> ~/.antigravity/perf.logA weekly glance catches quant degradation, thermal throttling, and background-process contention early.
Start with two settings tonight
Most of this is incremental. If you adopt nothing else from the article, set timeoutMs: 600000 in Antigravity and OLLAMA_KEEP_ALIVE=3h on the Ollama side. Two changes, maybe three minutes of effort, and the first noticeable jump in stability.
Fallback, health checks, and the VRAM degradation script come later, once you know which failure mode actually pushes on your setup. The important shift in mindset: treat your local backend like a production dependency, with the same assumption that it will fail and you need a story for that moment.