Opinion · agents · measured July 2026
Agents don't need a bigger brain. They need better retrieval.
The frontier labs are in a context-window arms race: a hundred thousand tokens became a million, and a million will become ten. It reads like progress. But a context window is just room to hold text; it says nothing about whether the text is the right text. On a real 4.47-million-file machine we measured where an agent's budget actually goes, and the expensive part is not reasoning over context. It is acquiring it: deciding which three files out of millions matter. Make the window bigger and you have not answered that question. You have built a larger place to be wrong.
TL;DR · the argument in five lines
- →
A bigger context window is just room to hold text: it can't tell which three files out of 4.47 million matter. The costly part of an agent loop is acquiring the right context, not reasoning over it.
- →
Stuffing a window backfires three ways: slower (every turn re-reads it), pricier (you pay per token), and dimmer (recall drops for facts buried in the middle).
- →
One measured Claude Code session, no index: 6m 57s across 71 tool calls, ~58% of its tokens spent hunting for files. Handed a single indexed retrieval call, it reached the exact file in 16 ms (one call, ~0% of tokens).
- →
Same 4.47M-file drive, one content query: ripgrep took 93.8 s; the index returned it in 16 ms. Filename lookups land in microseconds, and an edit is searchable about a millisecond later.
- →
This isn't RAG. It's the exact files (by name and contents, across every repo and the git-ignored 90% of the disk) kept live by a ~44 MB engine with no model in the box.
The picture · same task, same three files
It was never the size of the box. It's what you put in it.
Give a model a million-token window and let an agent fill it the only way today's tools allow (directory walks, grep dumps, files opened on a hunch) and the three files that mattered arrive buried in hundreds that did not. Retrieval does the opposite job: it decides what deserves a slot before the model reads a single token.
Both windows hold the same three files: auth.ts, config.ts, handler.ts. On the left they are needles in a haystack the model paid to grow. On the right they are the whole haystack. Signal density, not token count, is the number that moves the answer.
Three taxes on a stuffed window
Bigger context isn't free. It's slower, pricier, and dimmer.
Every token in the window is a token the model must read before it answers. Pack a window to a million tokens and every turn pays to re-read a million tokens, most of them directory listings it will forget.
You pay per token, in and out. On a metered agent plan, a window full of grep output is a bill full of grep output. On a real machine we measured ~58% of a session's tokens going to file hunting, not to work.
Recall degrades as context grows, and it is worst for facts buried in the middle, a pattern researchers named “lost in the middle.” More haystack does not help you find the needle. It hides it.
None of these get better with a bigger window. All of them get better with a smaller, denser one, and you only get a dense window if something already found the right files.
One real agent · one real file
What retrieval quality does to a session.
Same agent (Claude Code), same drive, same file. Without an index it spent six minutes and 57 seconds across 71 tool calls building context the hard way: list, grep, open, repeat, stuffing its window with output it would forget a turn later. Handed one indexed retrieval call, it got the exact file in 16 milliseconds and moved on. One query answered the question a million-token window was being used to brute-force.
The starkest single query: a content search that took ripgrep (the multi-threaded engine an editor shells out to) 93.8 seconds on this machine returned in 16 milliseconds through the index. Same query, same 4.47-million-file drive.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. The agent run is the measured Claude Code session; the ripgrep line is a content query over the same corpus. Full per-tool methodology in the backbone write-up and the ripgrep comparison.
The obvious objection
"But isn't better retrieval just RAG?"
RAG retrieves chunks by embedding similarity: a model's guess at what is relevant, usually scoped to one repo you pre-loaded into a vector store and refreshed on a schedule. That is one flavor of retrieval, and it is a guess.
The retrieval an agent needs on a real machine is narrower and stricter: the exact files, by name and by contents, across every repo and the git-ignored 90% of the disk no vector store ever ingested, and current, because you saved them a second ago.
So this is not a replacement for RAG or for the context window. It is the thing that decides what earns a place in either. Retrieval quality is precision, reach, and freshness: three things a bigger window buys you none of.
Where the right files come from
Retrieval that keeps up with the window. So the window can stay small.
Interlinked keeps a live index of every file on the machine: names and contents, every repo, the git-ignored files a working-directory grep never sees. A filename lookup returns in the microsecond range; a content search across millions of files runs in roughly 7 to 9 milliseconds, 16 for an exact phrase. Edit a file and it is searchable about a millisecond later. Any agent that speaks MCP calls it directly (nineteen AI clients configured in a single install) and gets back the exact files instead of a wall of listings to wade through. The window stops being a haystack. It becomes a short list of needles.
THE RETRIEVAL LAYER EVERY AGENT STANDS ON: OFFLINE, MACHINE-WIDE, NO MODEL IN THE BOX.
Common questions
Questions, answered.
Isn't a million-token context window enough to just hold everything?
A context window is room to hold text, not a way to find the right text. On a 4.47-million-file machine the hard part is deciding which three files matter, so a bigger window only builds a larger place to be wrong.
How is this different from RAG or a vector database?
RAG retrieves chunks by embedding similarity: a guess, usually scoped to one repo you pre-loaded and refresh on a schedule. This returns the exact files by name and contents across every repo and the git-ignored 90% of the disk, and they're current because you saved them a second ago.
Won't retrieval just become the new bottleneck?
Filename lookups land in microseconds; a content search across millions of files runs in about 7 to 9 ms (16 ms for an exact phrase), versus 93.8 s for ripgrep on the same drive. An edit is searchable about a millisecond later, so retrieval is never the slow step in the loop. The engine is validated: crash-free with correct ranking across ~1,500 queries.
Does it need another model, and will it work with my agent?
There's no LLM in the box: it's a retrieval layer that sits around 44 MB at rest. Any agent that speaks MCP calls it directly, and one install auto-configures 19 AI clients.
What does it cost?
Everything local is free forever, no card. Hosting starts at $5.99/mo.
Do this today
Give your agent the right files.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing.
Let it index. Filenames work immediately; contents fill in behind. At rest the engine sits around 44 MB, and the index takes under 1% of the drive.
Retrieve, don't stuff. Point the agent at the index instead of grep. It fills its window with the files that matter, and keeps the rest of the window for thinking.
Scope when you know. Whole-machine when you don't know where something lives; scoped to a folder when you do. Scoped queries return in microseconds.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.