Agents · Apr 9 2026 · 7 min
Three minutes
to find one file.
We measured Claude Code running Opus 4.6 against a single file-lookup task on a real 4.47M-file Windows drive. The agent took 193.5 seconds. Interlinked returned the same result in 85 microseconds.
TL;DR
The whole story, in five lines.
- 01
On a real 4.47M-file Windows drive (Ryzen 9 9950X3D), an AI coding agent needs ~71 tool calls to find one file. Interlinked returns the same result in 85 microseconds from a single query.
- 02
It's a prebuilt index, not a smarter model. Filename lookups land in 85 µs; full-text content search runs in 7 to 9 ms where ripgrep takes 93.8 s cold (16 ms warm).
- 03
Against everyday tools the gap holds: about 412,000× faster than VS Code's search and ~480,000× faster than Windows Search, which needs 67 s for the same query.
- 04
Wired into an agent over MCP, ~71 blind filesystem walks collapse to 1 index call, and the share of the token budget spent on search drops from ~58% to roughly 0%.
- 05
It stays out of the way: about 44 MB idle, ~1 ms to reflect a file change. Everything is free forever, no card. Hosting starts at $5.99/mo.
Interlinked
1 query · 1 response · no agent involved
Claude Code
71 tool calls · retries · partial walks
The difference between walking a filesystem and knowing where everything is.
What happens in 193 seconds
Tool calls, retries, partial walks, hope.
Claude Code has no built-in index. It has shell tools (find, ls, grep, Glob) and a model that picks one, runs it, reads the output, decides what to try next, runs that, and repeats.
On a 4.47-million-file drive, the cheapest tool still does a recursive walk of a multi-gigabyte directory tree. Fire the tool, wait 30 to 90 seconds, get too many results or none, scope down, fire again. Three minutes later, by persistence alone, the answer comes back.
The model isn't the bottleneck. The tools are.
Files on drive
Real Windows C: drive
Query
Literal filename search
Agent tool calls
Each one a blind walk
The real cost
Three minutes of search is not free.
| Metric | Per lookup |
|---|---|
| Wall clock time | 193.5 s |
| Tool calls (typical) | ~71 |
| Tokens consumed | 12k to 25k input, 2k to 4k output |
| Dollar cost (Opus pricing) | $0.35 to $0.70 |
| Lookups in a 4-hour session | 20 to 40 |
| Daily search tax | $7 to $28 per developer |
Token estimates are conservative: Anthropic's own usage logs for tool-heavy sessions trend higher. An active developer who pairs with Claude Code all day will spend $7 to $28 in agent tokens just on the search-and-locate portion of their work.
The model didn't get smarter. The tool got better.
That's the only thing that changed.With an indexed engine
The agent stops walking. The query goes straight to the index.
Interlinked exposes its file index to any AI agent over MCP, including Claude Code. When the indexed-search tool is registered, the agent stops reaching for find and grep. It calls the index. One tool call, two hundred tokens, 85 microseconds.
Same agent, same model, same query
Without index
With Interlinked
71 blind filesystem walks replaced by a single index lookup. Same model. Same machine. Different infrastructure.
The thesis
The infrastructure is the bottleneck, not the model.
None of this is the model's fault. Opus 4.6 is doing exactly what a human would do with the same tools. The bottleneck is not reasoning. The bottleneck is that the model is being asked to find a needle in a four-and-a-half-million-piece haystack with a flashlight and no map.
SWE-bench Pro shows a 22+ point swing between different agent scaffolds using the same model. That's larger than the gap between most frontier models. Retrieval infrastructure, context management, and tool orchestration matter more than the model weights.
The models are good enough. The infrastructure they call is what's slow. Fix the infrastructure, and the model wins. That's what Interlinked Files does.
Head to head
Same machine, same query, two ways of answering it.
| Claude Code (Opus 4.6) | Interlinked | |
|---|---|---|
| Wall clock | 193.5 s | 85 µs |
| Tool calls | ~71 | 1 |
| Token cost | 12k to 25k input + 2k to 4k output | ~200 total |
| Dollar cost | $0.35 to $0.70 | ≈ $0 |
| How it works | Recursive walks, retries, model guesses next folder | Pre-built index, direct lookup, no guessing |
Common questions
The questions this raises.
How can it find a file in 85 microseconds?
There is no AI and no live filesystem walk. Interlinked keeps a prebuilt, always-fresh index of every file on the machine (names and contents), so a lookup is a direct index hit, not a recursive scan. On the 4.47M-file test drive (Ryzen 9 9950X3D) a single-filename query returns in 85 µs.
Isn't this just ripgrep, VS Code search, or Windows Search?
Same job, a different order of magnitude. Full-text content search runs in 7 to 9 ms where ripgrep takes 93.8 s cold (16 ms warm, a 58,625× gap), and filename lookups land about 412,000× faster than VS Code's search and ~480,000× faster than Windows Search, which needs 67 s for the same query.
There's no model inside it, so how does it make an AI agent faster?
An agent's bottleneck is the tools it calls, not its reasoning. Expose the index over MCP and the ~71 blind find/grep walks it would otherwise run collapse into a single index call, dropping the share of the token budget spent on search from ~58% to roughly 0%.
Does a background index slow the machine down or go stale?
It sits at about 44 MB of memory when idle, and a file change is reflected in the index in ~1 ms, so results are effectively always current, with no manual re-scan.
What does it cost?
Everything (desktop search and the MCP connector that plugs into Claude Code, Cursor, and other clients) is free forever, no card. Hosting starts at $5.99/mo.
Machine-wide retrieval that turns any model into a better coding agent.
interlinkedfiles.com