Your agent reads the whole repo. Every turn.
Latorium sits between Claude Code and your codebase. A local model does the searching and the reading, so the expensive one only ever sees the passage that answers the question — and your usage window lasts a great deal longer.
One call, instead of forty file reads.
Your agent asks a question. Latorium answers it with three excerpts rather than four hundred files.
It registers as an MCP server, so nothing about your workflow changes. The agent keeps doing the thinking. It just stops loading the codebase to do it.
What the agent actually receives.
latorium.context_packet waiting…
It looks at everything.
The local model reads across the whole workspace — every file your agent might otherwise have opened one at a time.
It sends back three passages.
Not the files. The passages that answer the question, bounded to a size you set, with the surrounding noise left on disk.
The difference is the whole product.
Candidate context against delivered context, measured on your repository — which is the only place an honest figure exists.
The number comes from your machine, not from us.
We don't publish a headline percentage, because we can't honestly promise yours.
A small project and a large monorepo will not see the same figure, and a vendor who quotes you one number for both is quoting you a number they made up. Latorium measures candidate context against delivered context on your own repository and shows you the result.
The figures above come from a single session on this project's own repository. Yours will differ — that is the point of measuring rather than asserting.
Where the local model holds up, and where it doesn't.
Latorium ships a benchmark suite and publishes what it scores, including the part that isn't flattering.
Retrieval and single-file work are solid. Multi-file work is not, and five-module tasks are where an 8B model still falls over. That is the boundary between what we let it do on its own and what it drafts for you to review.
- Single file, best 10-run session
- 0
- Three files, best 15-run session
- 0
- Five modules, best 6-run session
- 0
Those are our best sessions. Across every run we have recorded the figures are lower — 72.5%, 39.5% and 19.0% — and the benchmark suite ships inside the extension, so you can run it on your own hardware and get your own number rather than ours. Read the first row as what the local model can carry on its own once your usage window is gone, and the last as the reason it hands the hard things back to you.
Nothing leaves the machine. Verify it yourself.
Not a policy commitment. A property of the build — the extension never contacts us, so there is nowhere for your code to go.
- Set a default-deny outbound firewall rule, with one exception for your local inference port.
- Use Latorium normally — retrieval, drafting, the task board.
- Watch nothing leave the host.
Licence keys are verified offline with a signature check, so even paying for it doesn't phone home. Read the full claim
And when the window runs out, it keeps working.
Saving tokens is the point. Carrying on after you've spent them is the reason it's worth having installed.
Hit your limit at eleven at night and the local model is still there. It won't write your feature the way Claude would — the figures above say exactly how far it gets — but single-file work, tests, scaffolding and refactors don't stop because a usage window did. Everything it produces is a draft you review.
The same is true on a plane, behind an air gap, or anywhere the network isn't. Retrieval is the product; coding is the thing that means a spent window is an inconvenience rather than the end of the evening.