Fixing Mid-Stream Cutoffs and Long-Run Freezes When Antigravity Talks to Ollama

Cause 2: The default num_ctx is smaller than you think

The second common cause of mid-stream cutoffs is Ollama's default context length. Regardless of what the model card advertises, Ollama often defaults to just 2048 tokens. If Antigravity feeds in several source files for a refactor, you can blow through that in the prompt alone, and the response comes back truncated or goes sideways partway through.

Override it cleanly with a Modelfile:

# Create a custom Modelfile with a larger context
cat << 'MODELFILE' > Modelfile.gemma4-long
FROM gemma-4:8b
PARAMETER num_ctx 16384
PARAMETER num_predict 4096
PARAMETER temperature 0.3
MODELFILE
 
# Register it under a new name
ollama create gemma-4-long -f Modelfile.gemma4-long
 
# Verify
ollama show gemma-4-long --modelfile | grep num_ctx
 
# Expected output: PARAMETER num_ctx 16384

Point Antigravity at gemma-4-long instead of the vanilla model name. VRAM usage scales with num_ctx, so rather than maxing it blindly, pick a value that fits your machine's headroom. Here's a rough guide from running the same gemma-4:8b (Q4) on an M2 24GB, changing only num_ctx. The absolute numbers shift with hardware and quantization, but the "heavier as it climbs" gradient holds.

In my own setup, everyday edits run at 16384, and I keep a separate 32768 model only for when I genuinely need to read a whole repo. num_predict caps tokens per response — set it generously (4K+) if you expect long code generations. Squeeze it too tight and you cap the output even when context is plentiful, which again looks like a "mid-stream cutoff."

Cause 3: Antigravity's client timeout is too tight

With Ollama fixed, if you still see mid-stream deaths, the next suspect is Antigravity's own request timeout. Gemma 4 at 27B on CPU-only can take upwards of 30 seconds just to produce the first token, and many HTTP clients give up before then.

In Antigravity's model settings, if you're using a custom provider endpoint, look for a "Request Timeout" field alongside the base URL. Pushing it to 300 seconds eliminates the "slow first token" class of failures. If your build doesn't expose it in the UI, edit the settings file directly (on macOS, ~/Library/Application Support/Antigravity/settings.json):

{
  "llm.providers": [
    {
      "name": "ollama-local",
      "baseURL": "http://localhost:11434/v1",
      "model": "gemma-4-long",
      "requestTimeoutMs": 300000,
      "streamReadTimeoutMs": 120000
    }
  ]
}

streamReadTimeoutMs is the one that usually matters most for mid-stream cutoffs — it's the maximum time the client will wait between tokens. If your model pauses for more than the default (often 30 seconds) during a tough generation, you get killed even though Ollama was happily still working. Two minutes is a safe floor for a loaded machine.

These two timeouts play different roles. requestTimeoutMs is your patience for the first token; streamReadTimeoutMs is your patience between tokens. Raise only the former and leave the latter at default, and you land in a half-fixed state where the run starts but dies mid-generation. Tune them as a pair.

Cause 4: Proxies, VPNs, and firewalls dropping idle streams

One underappreciated source of mid-stream deaths is the network path itself. Corporate VPNs and some security suites forcibly close TCP connections that go silent for too long. Because the connection establishes fine, you don't perceive it as "can't connect" — but after the first burst of output, a long pause triggers a middlebox to drop the socket.

The fastest way to confirm this is simple: turn off your VPN and rerun the same prompt. If it completes, you've found it. Fix it in your VPN client by raising the idle timeout or enabling TCP keep-alive. On a corporate network, your IT team may need to whitelist long-lived HTTP/1.1 connections to the Ollama host.

At home, the usual culprits are outbound firewalls like Little Snitch or LuLu. These can allow the initial connection but then trip on a different rule during a long stream. If you're running one, switch the ollama process to "allow forever" rather than "allow once."

When none of that works: collect logs that actually help

If the problem survives all four fixes above, the next step is log correlation. The fastest path is watching Ollama's server log and Antigravity's main log side by side at the same moment.

# Stream Ollama's server log on macOS
tail -f ~/.ollama/logs/server.log
 
# On Linux with systemd
journalctl -u ollama -f
 
# Antigravity's log on macOS
tail -f ~/Library/Logs/Antigravity/main.log
 
# What to look for:
# - Ollama log shows "model stopped: timeout"  → keep-alive problem
# - Ollama log shows "context length exceeded" → num_ctx problem
# - Antigravity log shows "stream aborted"     → client-side timeout or network

If Ollama's log shows a clean completion but Antigravity reports a cutoff, you're almost certainly looking at a client-side timeout or a dropped socket on the way back. If Ollama itself logs an error partway through generation, the fix is on the model side (context, VRAM, or model parameters). That simple dichotomy will save you from swapping settings blindly.

Hardening recipe: settings that survive a reboot

Once you've found the cause, you want to guarantee you can get back to the same stable state after a reboot, or after touching a different model. Volatile settings mean the same symptom returns days later. I pin three things so I can restore a clean environment in minutes.

First, consolidate the Modelfile into a single version-controlled file. Rather than leaning on environment variables for behavior, bake num_ctx and num_predict into the model definition itself, so naming the model is enough to get the right behavior.

# One hardened Modelfile, kept under version control
cat << 'MODELFILE' > Modelfile.gemma4-agent
FROM gemma-4:8b
PARAMETER num_ctx 16384
PARAMETER num_predict 4096
PARAMETER temperature 0.3
# Favor output consistency for agent use
PARAMETER repeat_penalty 1.1
MODELFILE
 
ollama create gemma-4-agent -f Modelfile.gemma4-agent

Second, put keep-alive and the loaded-model cap on the service side, not in a shell profile. If they only live in your login shell, an Ollama launched from the GUI never sees them. macOS launchctl setenv, Linux systemctl edit ollama, Windows system environment variables — the point in every case is "where the service reads."

Third, keep Antigravity's settings.json under version control with your dotfiles. Leave one provider block with requestTimeoutMs and streamReadTimeoutMs spelled out, and rebuilding an environment becomes a paste-back. With this trio — Modelfile, service env vars, and settings.json — mid-stream cutoffs effectively stopped recurring for me.

The verification loop: mechanically confirm it's fixed

Stopping at "probably fixed" risks celebrating a lucky short prompt. Every time I change a setting, I deliberately re-run a heavy prompt to reproduce the original conditions — long context and long generation — so I'm actually exercising the layer that was failing.

# 1. Force long context + long output; confirm on Ollama alone first.
time ollama run gemma-4-agent "Implement a TypeScript CLI from scratch for the \
following requirements, add JSDoc to every function, and finish with usage \
examples and tests: (paste ~300 lines of requirements here)"
 
# Expected: runs to completion without stalling. Use time to see the split
# between first-token wait and generation.
 
# 2. If Ollama completes, send the same prompt from Antigravity. If only one
#    side cuts off, you've isolated the client/network path (Cause 3/4).

If Ollama alone completes but Antigravity cuts off, the model settings are innocent and the client or network is guilty. If Ollama itself breaks partway, suspect num_ctx or VRAM. This two-stage test ends the finger-pointing. Raise your bar for "fixed" to "the same heavy prompt completes three times in a row" and you won't get fooled by a coincidental success.

Once you've confirmed the fix, it's worth baking num_ctx and your keep-alive defaults into a Modelfile so the behavior survives machine reboots. The Antigravity × Ollama × LM Studio local LLM integration guide walks through the full setup from scratch with those settings included. For a broader view of local LLM troubleshooting — including the connection-layer problems this article deliberately skipped — see the local LLM setup and connection troubleshooting guide.

The one thing I'd try first, before anything else in this article: run ollama show <model-name> --modelfile on whatever model you're currently using and look at the num_ctx line. If it's 2048, half your "random" cutoff symptoms are already explained. A local setup you can push hard through long trial-and-error is a real advantage for solo development — and it only earns its keep once you can run it without bracing for the stream to die.