85 microseconds.
Five tools. Six orders of magnitude.
We typed iron man into five file search tools on the same machine, against 4.47 million files, and measured wall-clock time to first result.
TL;DR
The takeaways in five lines.
85 microseconds to find one file among 4.47M, a single indexed lookup, where VS Code is 412,000× slower and Windows Search takes 67 seconds (~480,000×).
Content search lands in 7 to 9 ms where ripgrep needs 93.8 seconds cold, 16 ms warm, up to 58,625× faster on the same query.
An AI agent's file hunt collapsed from 6m57s across 71 tool calls to 16 ms in one, roughly 7,200,000× faster, and that step fell from ~58% of the context window to ~0%.
It's an index, not a faster walk. The work happens once, in the background: idle footprint ~44 MB, and an edited file is searchable again within ~1 ms.
Everything local is free forever, no card. Hosting starts at $5.99/mo.
Interlinked Files
Indexed lookup, one pipe round trip
Claude Code (Opus 4.6)
~71 shell calls until it found the file
Same machine. Same drive. Same query. Same file.
The ranking
Five tools, one question, ranked.
Each tool was timed from the moment the query was submitted to the moment the first matching result was on screen. All returned the same file.
| Tool | Wall clock▲ | vs Interlinked | How it answered |
|---|---|---|---|
| Interlinked Files | 85 µs | 1× | Indexed lookup, one pipe round trip to daemon |
| VS Code Ctrl+P | 35 sec | 412,000× | Recursive filesystem walk + fuzzy scorer |
| Windows Search | 67 sec | 480,000× | Indexer service, slow to wake, slow to rank |
| grep -r | 71 sec | 832,000× | Full recursive walk, reads every byte of every file |
| Claude Code (Opus 4.6) | 3 min 13 sec | 2,276,000× | ~71 shell tool calls, running grep/find in a loop |
The shape of the gap
Two clusters, one chasm.
The tools sort themselves into two groups with nothing in between. Indexed engines answer in microseconds. Walkers spend tens of seconds to minutes doing filesystem bookkeeping.
Nothing on this list takes between 10 ms and 10 seconds. There is no mildly-slow file search engine. You are either indexed and fast, or you are walking and hopelessly slow.
Cluster 1: Indexed
Interlinked Files (85 µs)
Cluster 2: Walkers
VS Code, Windows Search, grep, Claude Code
Indexed or walking. There is no in-between.
The gap is six orders of magnitude.The index
Microseconds, because it never walks.
Interlinked answers from a prebuilt index that already lives in memory. The query never touches the disk: it's a lookup in a table that already knows where every one of the 4.47 million files sits. The work happened once, in the background. By the time you press a key, there is nothing left to compute but the answer.
Getting a lookup down to 85 µs doesn't come from writing tighter C. It comes from different data structures: a lookup table cache-friendly enough to fit its hot set in L2, a query path that avoids branch mispredictions, a background daemon that amortizes the memory materialization cost across every call, and a hardware generation that gives you DDR5, AVX-512, and sixteen cores.
A walker cannot reach this number no matter how tight its code is. grep reading every byte, VS Code's recursive scan, Windows Search waking its indexer: each pays the full filesystem tax on every query. The index pays it once, offline. That is not a faster walk. It is the absence of a walk.
Architecture comparison
Walking the disk
Recursive scan · every entry · no index · every query
Interlinked (indexed)
L2-friendly index · NTFS journal · Zig · zero-copy
Same problem. Same OS API. One walks the whole filesystem on every call. The other never walks at all.
The walkers
Every walker is bad in its own way.
Not a search tool. An agent that fires grep and find in a loop (71 shell calls) until something sticks. The AI is guessing where your file is.
Reads every byte of every file on the drive. Honest about what it is: a brute-force text scanner. No index, no shortcuts.
Has an index, but the indexer wakes up slowly and ranks with an aggressive scoring model that isn't built for speed. The worst of both worlds.
“Only” 35 seconds because it restricts itself to the open workspace. Ask it to search the whole drive and it joins grep in the minutes bracket.
None of it matters to the user. From their side, the question “is this file on my machine?” took somewhere between 35 seconds and three minutes. During that window they started composing the “I'll do it myself” response in their head.
Latency budget
What fits inside a human blink.
A human blink takes 150 to 400 ms. A keystroke-to-result loop that feels “instant” must complete in under 100 ms. Here's what each tool spends of that budget.
Only one tool fits inside the perception budget. Everyone else overflows it by hundreds to thousands of times.
The bigger picture
Why this gap will only widen.
AI agents call file search hundreds of times per session. The cost of walking compounds. The cost of an index stays constant.
Files on drive
Real developer workstation
Code files indexed
Content-searchable in memory
Test query
Same query, every tool
Claude Code without Interlinked Files spent 71 tool calls guessing where a file lives. With Interlinked, the answer comes back in 85 microseconds, before the model even finishes reading its own system prompt.
The model ceiling is reachable. The next frontier is retrieval, and that's where Interlinked Files lives.
Common questions
The questions everyone asks.
Why is it so much faster than grep, ripgrep, or VS Code search?
Because it answers from a prebuilt index that already lives in memory: it never walks the filesystem. A filename lookup is 85 microseconds; the walkers pay the full disk-scan tax on every query, which is why the same search costs them tens of seconds to minutes.
Does the index go stale between searches?
No. It stays synced to the NTFS change journal, so a newly created or edited file becomes searchable again within about 1 millisecond. The always-on index sits at roughly 44 MB of memory while idle.
Can it search inside files, or only filenames?
Both. Full-text content search returns in 7 to 9 ms, versus ripgrep's 93.8 seconds cold (16 ms warm), up to 58,625× faster on the same query. Word, PDF, Excel, and PowerPoint text is indexed too.
How much does this actually help an AI coding agent?
A lot, because agents call file search hundreds of times per session. In one measured task an agent's file hunt went from 6m57s across 71 tool calls to 16 ms in a single call (about 7,200,000× faster), dropping that step from roughly 58% of the context window to nearly 0%.
What does it cost?
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.