From Mexico, I watch my coding agent’s token meter more than I’d like to admit. A lot of that spend isn’t writing code. It’s the agent poking around the repo trying to figure out where things live. So LightOn’s new post on Hugging Face, published October 12, caught my eye: they released ColGrep-Agent-2B, a small open model that runs on your own machine and does the code search for the big model.
Their headline number: when Claude Code handed its searches to that local agent, it used 34% fewer API tokens than with plain grep, and cache-aware API cost dropped 40%. The interesting part is how they got there, and what it cost them.
What it actually is
ColGrep is LightOn’s semantic code search engine. ColGrep-Agent-2B is a 2-billion-parameter model that uses it: it searches the repository, reads the promising files, follows references and returns file paths, line ranges and the code itself. It sits between your coding agent and the repo. You install it locally, index a project once, and the index updates itself as files change. LightOn says there’s no Python environment, external inference server or API key to set up, and the default quantized model is about 2.5 GB.
It plugs into Claude Code, Codex and OpenCode. In Claude Code it works through hooks that suggest the search tool to the agent. They don’t force Claude to use it, which I like, because the model can still fall back to grep when a plain name lookup is faster.
Where the savings come from
LightOn tested Claude Code running Sonnet 5.5 on 52 code-search questions across 13 public repositories created in 2026, picked to reduce the chance the models had seen them in training. Each question ran three times in each of four setups, for 624 sessions. With grep, a question averaged 142k tokens. With the local agent, 93k.
The mechanism is simple once you see it. Every new turn resends the conversation, and in their runs that was about 23k tokens per turn. With grep, Claude averaged 5.5 turns per question. With ColGrep-Agent, 3.9. Fewer rounds of guessing symbol names means less context shipped back and forth. The savings also grew with repo size: 19% below 50k lines, 29% from 50k to 150k, and 40% from 150k to 600k lines.
The catch, and LightOn says it plainly
Two things keep this from being a free lunch. First, speed. In their words, “The trade-off is latency.” End-to-end time per question went from 13.0 seconds with grep to 21.6 seconds with the agent.
Second, accuracy. The agent setup answered 80.8% of questions correctly versus 83.3% for grep. LightOn writes that “That difference isn’t statistically significant, but the interval is wide enough that we can’t rule out a meaningful drop.” Their Balanced mode, which lets Claude choose between plain ColGrep and the agent, matched grep’s observed 83.3% while saving 21% of tokens. That’s the setting I’d try first.
And scope matters: “These results are for code-search questions, not end-to-end coding tasks.” This is about finding code, not proof that your whole agent session gets a third cheaper.
What I take from it
This is a vendor benchmark of its own tool, with a model doing the grading, so I read it as a well-documented signal, not a verdict. Still, I think the pattern is the story. We’ve been treating the frontier model as the thing that does everything, including the boring walk through a codebase. Handing the walk to a small local model keeps your code on your machine for search and trims the bill, as long as you can live with a few extra seconds.
If your agent spends half its turns grepping a big repo, this is worth an afternoon. Start with the balanced setting, run it on a repo you know well, and check two numbers yourself: tokens per task and whether the answers are still right.
Featured image: “Wooden Card Catalog Furniture,” photo by MarkBuckawicki, Wikimedia Commons, CC0 1.0 (public domain dedication). Cropped and resized to 1400×900 and lightly sharpened from the original upload.
