Once the Antigravity local-LLM integration had settled, I used the May break to consolidate my own setup. I had been running Ollama, LM Studio, and a direct MLX Gemma 4 server in parallel, and they were starting to fight over disk and RAM on a single Mac mini M5. These are the notes from that consolidation and the criteria I used.
I lean on local LLMs for work I do not want to send to a cloud API: draft notes that include sensitive material, and formatting AdMob-related log dumps. Keeping that internal processing off the network is the main reason I keep a local path at all.
Why I started consolidating
Carrying three paths in parallel was convenient, but the costs caught up:
- Duplicate model files were eating about 80 GB of SSD.
- The three runners fought each other on ports and RAM whenever any of them was active.
- Three different Antigravity endpoint configurations meant a higher rate of configuration mistakes.
The May break became my time to pick winners.
Three criteria
I scored the three options on:
- Boot cost and idle memory footprint.
- How clean each endpoint looks from Antigravity.
- Model-update cadence and ease of retrieval.
I then kept one path as the default.
1. Boot cost and idle memory
- Ollama: a background daemon at about 500 MB idle, 8-14 GB once a model is loaded.
- LM Studio: the API only runs while the GUI is open, and just opening it costs 1.5 GB.
- MLX direct: simplest in that you manage the process yourself, but the configuration becomes verbose.
The Mac mini's 28 GB is shared with four wallpaper-app projects, so even 1 GB of idle RAM matters.
2. Endpoint cleanliness from Antigravity
Antigravity's localModels configuration points at Ollama on http://localhost:11434 and the behavior is predictable. LM Studio requires a UI reload on every model switch, which is awkward for automation. The MLX direct route needs you to write your own serving wrapper, and that alone took an hour.
3. Model updates
As of May, the Ollama registry covers all the major models including Gemma 4. A single ollama pull gemma-4:9b lands the model. LM Studio's advantage is that MLX-optimized variants land earlier, and Apple Silicon inference can be faster there in some cases.
What to load into 28 GB: choosing a quantization
On 28 GB of unified memory, the thing that bites is rarely the model itself; it is the model competing with the dev tools you already have open. I split Gemma 4 by quantization:
- 9b / Q4_K_M: about 5.8 GB. My daily driver. It survives running alongside Xcode and Antigravity at the same time.
- 9b / Q8_0: about 9.8 GB. Only when I need the extra accuracy. Keep this resident and an Xcode build starts to swap.
- 27b / MLX 4bit: about 15 GB. LM Studio only, and only for long-form formatting. If I open it, every other model gets unloaded first.
You can see what Ollama has resident with ollama ps. If the PROCESSOR column shows CPU mixed in rather than 100% GPU, that is memory spilling to CPU, and inference slows to a crawl. On a 28 GB box, "Q4 for daily use, Q8 and up only as one-offs" turned out to be the most stable line to draw.
What I kept, what I cut
After scoring on those three axes, I kept Ollama as the default and LM Studio as an auxiliary, and dropped the MLX direct route.
The concrete configuration:
Antigravity localModels:
- name: "gemma-4-9b-instruct (default)"
endpoint: "http://localhost:11434/v1"
model: "gemma-4:9b"
- name: "gemma-4-27b-mlx (heavy)"
endpoint: "http://localhost:1234/v1"
model: "lm-studio-loaded-model"Day-to-day work runs through Ollama's 9B. Long-form work that needs more accuracy switches to LM Studio's 27B MLX variant. LM Studio is closed when not actively in use, which keeps idle memory occupied by the daemon to almost nothing.
Spotting a port conflict fast
While I was running all three, the biggest time sink was diagnosing "Antigravity can't connect." Ollama uses 11434 and LM Studio uses 1234, but an old process can still be squatting on a port. I learned to identify the culprit first with one line:
lsof -nP -iTCP:11434 -sTCP:LISTENIf the PID that comes back is anything other than ollama, that is your conflict. Running this before second-guessing the Antigravity config cut diagnosis down to a couple of minutes. To confirm the endpoint is actually alive, curl -s http://localhost:11434/api/tags returns the loadable model list as JSON.
Why I cut the MLX direct route
The MLX direct route is technically interesting. I genuinely enjoyed running mlx_lm.server myself for the first two weeks. But writing my own launcher, managing ports and logs, and rolling my own restart logic was an overhead that does not earn its keep against indie operational time.
Running several wallpaper apps and four Lab sites as one person, "infrastructure I write and I have to maintain" is something I want fewer of, not more. The performance edge of MLX direct shrank materially once Ollama started calling MLX internally, so the trade-off no longer made sense.
Tightening idle memory with OLLAMA_KEEP_ALIVE
Once Ollama was the default, the next lever was how long a model stays resident. By default Ollama keeps a model in memory for five minutes after the last call, but I only call it between writing sessions, so those five minutes were quietly holding RAM. I shortened the retention to 60 seconds:
launchctl setenv OLLAMA_KEEP_ALIVE 60s
# to unload immediately
curl http://localhost:11434/api/generate -d '{"model":"gemma-4:9b","keep_alive":0}'That made idle occupancy predictable, so when an Xcode build and local inference collide in the same window the machine is far less likely to drop into swap. "Resident or load-on-demand" has a different answer depending on how much RAM the machine has; on a 28 GB box, my conclusion is to keep it short.
May consolidation numbers
The cleanup math:
- Duplicate model file deletion: about 52 GB freed.
- LM Studio cache clear: about 8 GB.
- MLX direct files: about 18 GB.
- Total: about 78 GB.
That gave the Mac mini SSD an extra 30 GB or so, which lets me keep Xcode's derived data and Crashlytics dSYMs around without rationing.
An unexpected upside after switching
Two benefits showed up that I had not planned for. One was that Antigravity simply became more stable. With three runners I kept losing time to port-conflict detection; collapsing onto Ollama alone took that to almost zero. It is only about ten minutes a day, but over a month that is roughly five hours.
The other was that the Mac mini ran cooler. With LM Studio no longer resident, idle CPU temperature dropped by about five degrees and the fan spun up perhaps half as often. During the hours I sit down to write, that quietly improves the working environment.
When you add AI tools as an indie developer, the physical quality of your working environment deserves a place in the evaluation. Choosing a tool on benchmark numbers alone accumulates as invisible fatigue over a long relationship.
Where I am landing
The May end-state is the lean "Ollama default + LM Studio auxiliary" two-path setup, used for sensitive log formatting from the wallpaper portfolio and draft notes for the four Lab sites. I have given myself the rule that the Antigravity localModels list will not grow beyond two entries.
If you are starting to combine Antigravity with local LLMs, I would skip running three paths in parallel. Install one, live with it for a week, then add a second only when you can name what the first one cannot do. That approach saves both time and disk.
In indie operations, the harder and more valuable judgment is usually to drop a tool, not to add one. I hope this is useful as you make your own call.