Running Gemma 4 in Antigravity — Ollama Setup and a Realistic Local/Cloud Split

Gemma 4 works with Antigravity — and for development use, the combination is surprisingly effective. Running a local model means no API costs during experimentation, and your code stays on your machine.

The connection itself takes about ten minutes. What trips people up comes after: responses that feel oddly slow, a long pause on the first question after a break, agent runs that misfire. I keep this setup in daily use as an indie developer for the work I would rather not send to the cloud, and this article covers those operational lessons along with the setup steps.

What Is Gemma 4?

Gemma 4 is Google's open-weight model family, distilled from Gemini technology. It's released under a license that permits commercial use, and it runs locally without an internet connection. The trade-off vs. Gemini 2.5 Pro is reasoning depth and context length, but for many coding assistance tasks, the gap is smaller than you'd expect.

It helps to think of Gemma 4 as playing a different role than cloud Gemini rather than a cheaper stand-in. Let the cloud handle fresh information and long reasoning; keep the things you don't want to send out — your own code, logs, quick repeated experiments — local. When I'm fixing the prep scripts behind my content workflow, that exact split is where Gemma 4 earns its place.

Prerequisites

• Antigravity IDE (latest version)
• Ollama (local LLM runtime)
• RAM: 8 GB minimum for the 4B model; 16 GB recommended for 12B+

Step 1: Install Ollama and Download Gemma 4

# Install Ollama (macOS/Linux)
curl -fsSL https://ollama.ai/install.sh | sh
 
# Windows: download the installer from https://ollama.ai
 
# Download Gemma 4 (4B parameter version)
ollama pull gemma4:4b
 
# Or the 12B version for higher quality (needs 16GB RAM)
ollama pull gemma4:12b
 
# Verify download
ollama list
# Expected:
# NAME           ID              SIZE    MODIFIED
# gemma4:4b      ...             3.3 GB  ...

Picking a Model Size — Memory-Based Guidance

Before running ollama pull, decide which size is realistic on your machine:

• 8GB RAM: gemma4:4b only. Even then, heavy browser use slows it down — better for chat than completions
• 16GB RAM: gemma4:4b runs comfortably; gemma4:12b works but struggles alongside other apps
• 32GB+ RAM: gemma4:12b becomes a solid daily driver with a good quality-speed balance
• 64GB+ (Apple Silicon): quantized gemma4:27b enters the picture

When unsure, get the connection working with 4b first, then size up if quality disappoints. Switching is just a model change in config.json and a restart.

Pick a Quantization Tag to Save Memory

When you pull an unsuffixed tag like ollama pull gemma4:12b, Ollama gives you its default quantization (often around Q4_K_M). On a machine that's tight on memory, explicitly choosing one step lighter can be the difference between the same parameter count loading or not.

# Pull an explicit quantization tag
ollama pull gemma4:12b-q4_K_M   # balanced quality vs. size (close to default)
ollama pull gemma4:12b-q3_K_M   # lighter; slightly lower quality, but friendlier to 16GB

In my experience, for coding help — lots of short responses — the quality gap between Q4 and Q3 is smaller than expected. For long explanations or refactor suggestions, Q4 and up hold together better. Start with the default, and only drop a step when memory gets tight.

Step 2: Configure Antigravity to Use Gemma 4

Open Antigravity's settings and point it to Ollama's local API:

// .antigravity/config.json
{
  "ai": {
    "provider": "ollama",
    "baseUrl": "http://localhost:11434",
    "model": "gemma4:4b",
    "contextLength": 8192
  }
}

Restart Antigravity after saving. Send a test message in the chat panel — if you get a response, the connection is working.

Verifying the Connection Properly

Judging by the chat panel alone leaves you with nothing to isolate when things break. I check in three stages:

# 1. Does Ollama recognize the model?
curl http://localhost:11434/api/tags
 
# 2. Is the model loaded in memory? (shows size and how long it stays)
ollama ps
 
# 3. Does a generation request go through?
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:4b",
  "prompt": "1+1=",
  "stream": false
}'

How to read the failures:

• connection refused → Ollama itself isn't running. Start it with ollama serve
• model not found → either a typo in the model name or the pull never happened. Compare the NAME column of ollama list against model in config.json character by character — mixing up gemma4:4b and gemma-4:4b is the classic
• Step 3 works but Antigravity still won't connect → re-check baseUrl and restart the IDE. The config file is only read at startup, a behavior that has fooled me more than once

Step 3: Optimize for Coding Assistance

Adding a system prompt makes Gemma 4 significantly more useful as a coding assistant. In Antigravity's system prompt settings:

You are an experienced software engineer assistant.
When explaining code, start with a 1-2 sentence summary of what it does,
then explain the key implementation details concretely.
When generating code, include explanatory comments.
Be concise and direct. Prefer working code examples over abstract descriptions.

Keep the system prompt short, and describe policy rather than prohibitions. Local models prioritize instructions less reliably than large cloud models — a ten-line bullet list will have items silently ignored. Keep it about as long as the example above and specify the rest conversationally.

A Caveat on Agent Workflows

Temper expectations when pairing Antigravity's agent features (autonomous, tool-calling runs) with a local Gemma 4. One-shot code generation, explanation, and refactoring suggestions are genuinely usable; multi-step tool calling fails more often than with cloud models. If tool calls misfire or JSON comes back malformed, the fixes are collected in the Gemma 4 tool-call error guide.

My own split: conversation and code snippets stay local, long agent-driven tasks go to the cloud. Settling on that line removed most of my frustration with both.

A Slow First Question After Idle — Tuning keep_alive

By default, Ollama unloads the model from memory about five minutes after the last request. The next time you ask something, the model has to reload first — so the first question after a break feels like a multi-second stall. While coding, gaps between questions are normal, which makes the default far too short for development use in my experience.

# Keep the model in memory for one hour (set before starting serve)
export OLLAMA_KEEP_ALIVE=1h
ollama serve &

After setting it, ollama ps shows the loaded model and how much longer it will be retained.

The trade-off is that the model occupies RAM the whole time. Holding 12b on a 16GB machine while running builds or simulators squeezes everything else. My routine: 1h on days I use 4b, dialed down to 30m on 12b days.

Gemma 4 vs Gemini 2.5 Pro: When to Use Each

Use Gemma 4 (local) when:

• Prototyping and experimenting where you'd burn through API credits
• Working with proprietary or sensitive code you don't want in the cloud
• Developing offline or in a restricted network environment

Use Gemini 2.5 Pro (cloud API) when:

• Tasks require deep reasoning or very long context windows
• You need access to current documentation or recent framework updates
• Production-quality responses are required

Troubleshooting

Antigravity can't connect to the model

# Check if Ollama is running
ollama list
 
# Start the service if needed
ollama serve &
 
# Test the connection directly
curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:4b",
  "prompt": "Hello"
}'

Responses are very slow

First decide whether it's always slow or only slow on the first question after idle. The latter is the model reloading — fix it with the keep_alive tuning above.

If it's always slow, swapping is the prime suspect. Even the 4B model becomes unusably slow once the machine starts paging to disk. Check memory usage in Activity Monitor (macOS) or Task Manager (Windows). If RAM is constrained, try a smaller variant like gemma4:2b.

Out of memory crashes

Resizing the model is the primary fix, but lowering contextLength from 8192 to 4096 sometimes gets you through. Context length costs memory through the KV cache that holds conversation history, so a longer context raises the RAM requirement even for the same model. Detailed triage lives in the Gemma 4 out-of-memory fix guide.

Prefer LM Studio?

Ollama can be swapped for LM Studio as the runtime — friendlier if you want GUI model management. Steps are in the Ollama / LM Studio integration guide.

Try One Full Day Local-Only

Once setup is done, spend a single day routing every code question to the local Gemma 4. You will learn exactly where local is enough and where you miss the cloud — calibrated to your own workflow rather than someone else's benchmark. For me, that one day showed that everything except long agent tasks works fine locally, and my API costs dropped visibly.

If you want to go deeper on the connection side, the detailed local LLM setup walkthrough is the natural next step.