Connecting a Local LLM to Antigravity — Getting the First Round Trip Working with Ollama

I once tried to fix the ad code in one of my wallpaper apps on a bullet train. Every tunnel dropped the connection, and the cloud LLM kept stopping mid-answer. Around the same time I'd also started to feel uneasy about sending fragments of code off my machine.

So I set up an LLM on the iMac at my desk and called it from Antigravity. What I'd like to say first is that a local LLM isn't a replacement for the cloud; it's something you split work with. At the start I tried to move everything local. It didn't go well: design questions got shallow answers, and I lost more time than I saved.

Here is the path I'd take again: install Ollama, get one round trip working, connect Antigravity, and know where to look when it won't connect.

Decide the split before you install anything

Deciding what stays local and what stays in the cloud saves a lot of fiddling later. My current split:

• Local: completion, drafting comments and commit messages, reading code I'd rather not send out, and working without a connection
• Cloud: design discussions across many files, long investigations, and anything where quality matters most

Keep it local when it's cheap to be wrong; use the cloud when it isn't. Once I wrote that down, I spent far less time agonizing over settings.

Choosing a runner

The software that runs the model is usually called a runner. I've used two in practice: Ollama and LM Studio. LocalAI assumes a Docker setup, which never earned a place on my desk.

For calling from Antigravity, a runner that sits quietly in the background is easiest, and that's Ollama. I use LM Studio when I just want to get a feel for a model.

Installing Ollama

Download the installer for your OS from ollama.com. On macOS, Homebrew works too.

# macOS (Homebrew)
brew install ollama
 
# Linux
curl -fsSL https://ollama.com/install.sh | sh

On Windows the official installer registers a background service that starts automatically.

Pulling a model and checking that it answers

Models come down with ollama pull. The first download takes several minutes or more, so do it somewhere with a good connection.

# Example: a small code-oriented model
ollama pull qwen2.5-coder:7b
 
# See what you have
ollama list

Model names change quickly. Check the Ollama model library for current names and sizes before pulling; the one above is just an example.

To confirm the server is up:

curl http://127.0.0.1:11434/api/generate \
  -d '{"model": "qwen2.5-coder:7b", "prompt": "Write a function that sums 1 to 5", "stream": false}'

If JSON comes back, the local side is done. Ollama listens on 127.0.0.1:11434 by default.

Antigravity will call the /v1 side that I set up in the next section, so it's worth checking that path first.

# OpenAI-compatible model list
curl http://127.0.0.1:11434/v1/models
 
# OpenAI-compatible chat
curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "qwen2.5-coder:7b", "messages": [{"role": "user", "content": "Hello"}]}'

If nothing comes back here, the cause is on the local side, not in Antigravity's settings. I once checked only /api/generate, felt reassured, skipped /v1, and lost half a day.

Calling it from Antigravity

This is where I got stuck at first. Menu names and layout in Antigravity change between versions, so please treat the steps below as a guide and compare them with your own screen.

1. Open the settings section that handles models or connections.
2. Add a custom provider (or an OpenAI-compatible endpoint).
3. Enter http://127.0.0.1:11434/v1 as the endpoint and the name shown by ollama list as the model.
4. No API key is needed, but if a field insists, an arbitrary string often works.
5. Run the connection test and confirm a reply comes back.

Pointing at the OpenAI-compatible /v1 path, rather than /api/generate, connects with more clients. It took me about half a day to notice that difference.

If you use LM Studio as the runner, start its local server inside the app and enter the address it shows (often http://localhost:1234/v1 by default) as the endpoint. Copy the model name exactly as the LM Studio screen displays it.

Choosing a model

I work backwards from what I want to hand off.

For memory, I budget the model's file size plus 2–4 GB. Without that margin, Antigravity and the model fight over RAM and both slow down.

When it won't connect

Check from the layer closest to the model outward.

1. Connection times out. Ollama probably isn't running.

ps aux | grep ollama
curl http://127.0.0.1:11434/api/tags

If api/tags doesn't answer, start it again with ollama serve.

2. "Model not found." The name in the editor differs from the one in ollama list by even one character. A forgotten tag such as :7b was the cause most of the time for me.

3. Responses are extremely slow. It may be running on CPU only, or short on memory. Run ollama ps to see which model is loaded and whether it's on CPU or GPU (the PROCESSOR column). If the CPU share is large, try a smaller model first and see whether speed returns.

4. Only the connection is refused. The OS or security software may be blocking localhost traffic. On Windows, adding ollama.exe to the exclusions sometimes fixes it.

5. Slow or crashing only after the first few runs. Previous models stay in memory when you switch. Free one with ollama stop <model>.

6. It works in a terminal but Antigravity alone can't reach it. Check whether Antigravity and Ollama are running in different places. Inside WSL, a container or a remote session, 127.0.0.1 means that environment itself, so it can't reach an Ollama running on the Windows or Mac side.

# Example: widen the listen address on the side running Ollama
OLLAMA_HOST=0.0.0.0:11434 ollama serve

Point the endpoint at a hostname or IP address that is visible from the other environment. Be aware that widening the listen address lets other devices on the same network call it too, so I keep this to my own home network and never expose it publicly. Steps differ by setup; the surest first move is to get Ollama working inside the same environment as Antigravity.

When it connects but the answers are shallow or forget things

Sometimes the connection test passes and real use still goes sideways. I noticed it one night after pasting a long file: the model had forgotten a condition I'd stated at the top by the time it reached the bottom.

The cause was usually the context length, not the model's intelligence. The default differs by Ollama version and environment, and it can be shorter than you'd expect. Anything that overflows is dropped silently, so there's no error to point at.

# Widen it temporarily in interactive mode
ollama run qwen2.5-coder:7b
>>> /set parameter num_ctx 8192

For everyday use, put PARAMETER num_ctx 8192 in a Modelfile and build it under a new name with ollama create. Depending on your version, the OLLAMA_CONTEXT_LENGTH environment variable also works. A larger window costs memory, though. If you have no headroom left from the budget above, I'd rather trim what I paste than push the number up.

When answers feel shallow, check whether the input got cut off first. Reaching for a bigger model can wait.

What I noticed after using it for a while

I once asked the same questions to a cloud LLM and a local model and compared the answers. For rewriting a simple function, there was almost no difference. For design questions spanning several files, the gap was obvious at a glance.

What helped most wasn't performance, though. It was not having to think about the connection. Even on the train, my hands stopped stalling.

One thing to try first

Install a single small model and get a reply from curl. Connect Antigravity afterward. If you already know the local side works, a failed connection has half as many places to hide.

I try to keep this one rule even on bad days: check the layer you can verify, one step at a time.

If you're ready to split models across several agents, the Antigravity multi-agent system implementation guide is a good next stop.