The free model
was good enough.
A blind comparison: one local open-weight model on a single RTX 5090, one budget API, one frontier API. Same code. Same structured output. Same scoring. April 2026.
TL;DR
Key takeaways
A free local model matched 80%+ of frontier. Gemma 4 26B Q8 with thinking mode, on a single RTX 5090, produced structured code analysis at 80%+ of Opus 4.6 depth, for $0 per chunk.
Zero parse failures across 30 outputs. Every model returned valid JSON on every chunk. Reliable structured output from a local 26B model is no longer a coin flip.
The gap is depth, not correctness. On the hardest chunk Opus surfaced more cross-references than the local model, but nothing Gemma said was wrong. It just said less.
At scale, price beats polish. Ten thousand chunks cost $0 locally versus $330 on a frontier API: about 20% less depth for 100% less spend.
The model is commoditized; the scaffold is the product. What turns a good-enough model into a better coding agent is machine-wide retrieval that feeds it the right context. That's where Interlinked Files lives.
Local model
80%+ of Opus quality · zero parse failures
Frontier API
Opus 4.6 at 10K chunks · 20% deeper, not 20% more correct
The test
Three models. Same 10 code chunks from a Rust agent framework. Gemma 4 26B MoE Q8 with thinking mode running locally on Ollama, plus Claude Haiku 4.5 and Opus 4.6 via API. Each model received identical source code and instructions: produce structured JSON with semantic labels, cross-references, and Q&A pairs.
#1 Best value
#2 Best quality
#3 Best restraint
Zero parse failures across all 30 outputs. Every model produced valid JSON on every chunk.
Structured output reliability from a local 26B model is no longer a coin flip.Head-to-head
Same task, three price points.
| Model | Provider | Cost / chunk | Time / chunk | Parse failures | Avg output fields |
|---|---|---|---|---|---|
| Gemma 4 26B MoE Q8 + Think | Local (RTX 5090) | $0 | 9.2s | 0 | ~3.1 |
| Claude Haiku 4.5 | API ($0.25 / $1.25 MTok) | $0.0024 | 3.5s | 0 | ~4.0 |
| Claude Opus 4.6 | API ($15 / $75 MTok) | $0.033 | 7.1s | 0 | ~3.7 |
All three models produced valid JSON on every single chunk. Zero parse failures. That alone is notable: structured output reliability from a local 26B model used to be a coin flip. Gemma 4 with thinking mode has apparently solved this.
Hard test
50-line function, 4 trait dependencies.
The hardest chunk: a Rust Runner struct that sets up Handlebars templates, spawns tokio tasks with mpsc channels, and mocks service responses with Mutex-guarded VecDeques. Opus named specific patterns like mpsc channel capacity and Mutex-guarded dequeue ordering.
The depth gap is real: about 20-30% less detail from Gemma on complex chunks. But nothing Gemma said was wrong. It just said less.
Opus cross-refs
Most specific pattern identification
Haiku cross-refs
Surprisingly close to Opus
Gemma cross-refs
Correct but surface-level -- $0
Deep dive
Complex chunk breakdown.
Side-by-side comparison on the hardest file in the test set.
| Criterion | Gemma Q8 Think | Haiku 4.5 | Opus 4.6 |
|---|---|---|---|
| Reads neighbor code? | Yes | Yes | Yes, most specific |
| Explains mechanism? | Correct but surface-level | Detailed | Most detailed |
| Cross-references found | 3 | 5 | 6 |
| Q&A pairs generated | 3 | 4 | 4 |
| Hallucinations | 0 | 0 | 0 |
Easy test
A 4-line struct. The right answer is silence.
| Model | Output | Assessment |
|---|---|---|
| Gemma Q8 Think | 2 labels, 1 Q&A | Minor over-description but acceptable |
| Haiku 4.5 | 0 labels, 0 Q&A | Perfect restraint: said nothing about a trivial struct |
| Opus 4.6 | 2 labels, 1 Q&A, 1 cross-ref | Correctly identified the struct as a return type of a related service |
Haiku showed the most restraint: perfect silence on a trivial struct. Opus found a real connection even on trivial code (identified the struct as a return type of a related service). For batch processing thousands of chunks, Gemma’s slight over-description is acceptable noise.
Cost at scale
What 100K chunks actually costs.
The per-chunk difference is small. At scale it’s the difference between free and a car payment.
| Model | 1K chunks | 10K chunks | 100K chunks | Wall time (10K) |
|---|---|---|---|---|
| Gemma Q8 Think (local) | $0 | $0 | $0 | ~25 hours |
| Haiku 4.5 (API) | $2.40 | $24 | $240 | ~10 hours |
| Opus 4.6 (API) | $33 | $330 | $3,300 | ~20 hours |
The quality tradeoff
The gap is depth, not correctness.
All three models are production-quality. Zero hallucinations, zero parse failures, correct grounding on every chunk. For batch code analysis at scale (the kind of work that runs overnight on thousands of files) the free local model is the clear winner. Not because it’s the best, but because it’s good enough.
"Good enough at $0" beats "slightly better at $330" every time.
The era of paying per-token for code understanding is ending.The bigger picture
The quality plateau is real.
Local open-weight models have hit production quality for structured code analysis. The remaining gap is depth, not correctness. If you have a GPU, the model is free.
What matters now is what you build on top of it. The retrieval infrastructure, the context management, the tool orchestration: these matter more than the model weights. That’s where Interlinked Files lives.
Machine-wide retrieval that turns any model into a better coding agent. The model is commoditized. The scaffold is the product.
FAQ
Common questions.
Is a free local model really good enough for production code analysis?
For batch structured analysis, yes. Across all 30 outputs there were zero hallucinations and zero parse failures, at 80%+ of frontier depth: the remaining gap is detail, not correctness.
If the model is free, what does Interlinked Files actually sell?
The retrieval scaffold, not the model. It keeps an always-fresh, machine-wide index so any local or API model gets the right files instantly: a single filename lookup in 85 µs (139 µs median across 4.47M files), and content search in ~7-9 ms.
How much faster is that than the tools I already use?
On a 4.47M-file machine (Ryzen 9 9950X3D), a filename lookup runs 412,000x faster than VS Code and ~480,000x faster than Windows Search, which takes 67 s. A content query that takes ripgrep 93.8 s comes back in 16 ms, roughly 58,625x.
Why does search speed matter for an AI agent specifically?
It collapses the slow part. A grep-driven lookup that cost an agent 6m57s across 71 tool calls (burning ~58% of its context) becomes one call in 16 ms and ~0% of tokens, about 7,200,000x faster. The index idles at ~44 MB and reflects edits in ~1 ms, so results are never stale.
What does it cost?
Everything local is free forever, no card. Hosting starts at $5.99/mo. No API keys, no per-token metering, and the index never leaves your machine: nothing is uploaded unless you publish a project or a link.