Your diff should never leave your machine: the Ollama path for air-gapped repos.

There is a widely held assumption that using AI on your code means handing your code to a vendor. This assumption is false, but it’s been allowed to persist because most popular LLM tooling does in fact phone home. The Ollama path through CommitBrief is the counter-example. This post is a careful tour of how it works, who it’s for, and an honest look at the quality trade-off it implies.

What “air-gapped” actually means here

The Ollama provider talks to http://localhost:11434 — your machine, on a loopback interface. CommitBrief makes no other outbound network calls when this provider is selected. No telemetry endpoint, no auto-update check, no analytics ping, no SaaS account verification. Your diff, your COMMITBRIEF.md, and the model’s response never cross your machine’s boundary.

This is verifiable. The Ollama provider’s HTTP client targets exactly two paths:

• POST /api/chat — the actual review call
• GET /api/tags — model discovery, used by the setup wizard

No other URLs are touched. You can confirm this by setting HTTP_PROXY=http://invalid.local in your environment and watching every other provider fail while Ollama keeps working. The CLI binary doesn’t try to reach the internet for any reason.

Who needs this

The classic answer is “regulated industries.” That’s right but incomplete. The full list, from what I’ve heard from users:

• Defense contractors with strict ITAR-bound code
• Fintech teams with PCI-DSS scope on their repos
• Healthcare engineers with HIPAA-touching codebases
• Government and public-sector teams with sovereign-data requirements
• Companies in jurisdictions that legally restrict cross-border data transfer
• Open-source maintainers working on cryptographic libraries who don’t want third-party model providers seeing their unreleased work
• Anyone who simply doesn’t want to be in the business of trusting another vendor with their unreleased code

The first five categories often legally cannot use a cloud LLM provider on their codebase. The last two often choose not to, which is equally valid.

The setup

Assume Ollama is installed and a coder model is pulled:

ollama pull qwen2.5-coder:14b

Then point CommitBrief at it:

commitbrief setup --local
# In the wizard: pick ollama, pick qwen2.5-coder:14b

The --local flag saves the configuration under ./.commitbrief/config.yml and auto-adds .commitbrief/ to your .gitignore. From this point, every commitbrief --staged in this repo goes to your local Ollama instance. The same commitbrief setup (without --local) would write a user-global config under ~/.commitbrief/config.yml — useful when you want all your repos to default to Ollama.

A TestConnection step in the wizard hits /api/tags rather than spending inference time on a real completion. If Ollama isn’t running or the model isn’t pulled, you find out immediately rather than after the first review attempt.

The quality trade-off, honestly

I’m not going to tell you a local 14B model is the same as Claude Sonnet 4.6. It isn’t. Sonnet has more parameters, more training, more capability at picking up subtle context. A serious comparison across the same diff usually shows the commercial model catching one or two findings the local model misses, especially on architecture-level concerns.

But the gap that matters isn’t the gap between local and commercial. It’s the gap between local and no review. If your compliance posture means you can’t use a cloud provider, you’re not choosing between qwen and Sonnet — you’re choosing between qwen and nothing. In that frame, qwen wins decisively.

A few honest observations from running both side by side over several months:

• For mechanical findings (pattern violations, consistency drift, typical bug shapes), a good local coder model is competitive with cloud models. The hard part of these findings is consistency, not capability, and consistency is a model-architecture question more than a parameter-count question.
• For “this function answers the wrong question” findings, neither local nor cloud LLMs are reliable — those still belong to humans. So choosing local doesn’t lose you anything there.
• For nuanced architecture concerns (“this looks fine but the cross-service implications are wrong”), the cloud model is genuinely better. If your work is heavy on this kind of finding, the local path will feel thinner.

Pick a model that’s actually trained on code. The generic chat-tuned models will work but produce noisier output than a coder-tuned model of the same size. qwen2.5-coder, deepseek-coder, and codellama families are all worth trying.

What you gain beyond privacy

Two side benefits the Ollama path produces almost by accident:

• No per-token cost. A review on Ollama is paid for in electricity. The local response cache makes re-runs free anyway, but with Ollama even the first run is cost-free at the dollar level.
• No rate limits. You’re not going to hit a 429 from your own machine. For teams that run review in CI on every PR, that’s the difference between “this works reliably” and “this fails 3% of the time on a busy day.”

These aren’t reasons to switch to Ollama if you don’t need air-gapping. The commercial models will outperform a 14B local model on quality. But for teams who’d already chosen the local path for compliance reasons, these are quiet wins.

When to keep the cloud option

For everyone outside the regulated cases, my honest recommendation is to keep at least one cloud provider configured. CommitBrief lets you switch per-run with --provider, so nothing forces you to commit to one path. Run Ollama by default; reach for Anthropic or OpenAI on the rare diff where you want a second opinion from a more capable model.

If you arrived here from the CLI-vs-App post, this provider flexibility is a direct consequence of the CLI architecture — a GitHub App can’t realistically offer “switch to a local model for this one run.” And if you arrived from the solo developer post, the Ollama path is what makes review economically viable for an indie’s lowest-priority side project.

The next post turns to a configuration detail that has more impact than it sounds: the three-layer filtering pipeline, and how to keep noisy paths out of your review without losing the signal you care about.

← all posts