Six orders
of magnitude.
Plot every file-search tool on a log scale. The points cluster at two extremes and leave the middle completely empty. You're either indexed, or you're hopeless.
TL;DR
The whole argument, in five lines.
A filename query returns in ~85 µs across 4.47M files (139 µs median), below the threshold of human perception, because it's a hashmap lookup, not a filesystem walk.
That's ~412,000× faster than VS Code search and ~480,000× faster than Windows Search (67 s), same drive, same query, same files.
Content search answers in 1 to 10 ms where ripgrep needs 93.8 s, a 58,625× gap (93.8 s → 16 ms), across the whole machine.
For an AI agent the effect compounds: a hunt costing Claude Code 6m57s across 71 tool calls becomes one 16 ms call (~7,200,000×), and context burned on searching falls from ~58% to ~0%.
It idles at ~44 MB with ~1 ms freshness. Everything is free forever, no card. Hosting starts at $5.99/mo.
Indexed
Interlinked Files on 4.47M files
Unindexed
grep on the same drive
The ladder
Seven orders of magnitude, one cliff in the middle.
Each row is 10x slower than the one above. Only two rows contain file-search tools. The middle five are empty.
| Order | What lives here | Latency | How it feels |
|---|---|---|---|
| 10⁻⁴ s | Interlinked Files, L2 cache round trip | ~14 µs | Below human perception |
| 10⁻³ s | Everything (2006), DDR5 page miss | ~1 ms | Borderline felt |
| 10⁻² s | SSD seek, single HTTP round trip | 10 ms | Just barely perceptible |
| 10⁻¹ s | A fast web page, human reflex | 100 ms | Noticed as a pause |
| 10⁰ s | The “is this broken?” threshold | 1 s | User doubts the tool |
| 10¹ s | User walks away, starts multitasking | 10 s | Workflow broken |
| 10² s | grep on 4.47M files, Claude Code hunt | 62 s | Session abandoned |
The first two rows and the last row are where file-search tools live. The five rows in between are uninhabited. No tool in production operates between 10 milliseconds and 10 seconds on a real drive. The cliff is absolute.
The speed difference between the top and bottom of the cliff.
14 µs vs 62 seconds. Same drive. Same query. Same files.
Why the cliff exists
Indexing is binary. You either have one or you don't.
The middle is empty because the cost structure of file search has no continuous knob. There is no “half-indexed” mode. An index is a prebuilt lookup structure that trades space for time, and that trade only pays off if the lookup is near-constant. Any attempt to moderate it destroys the advantage.
Every architecture that tried to land in the middle (partial indexes, heuristic walkers, fading memory caches) ended up bimodal: fast on hits, slow on misses, nowhere near the middle on average. The middle is structurally impossible to occupy.
Option A: partial index
1 ms on hits, 60 s on misses. Not middle.
Option B: parallel walker
Faster shade of hopeless. Still bottom of cliff.
Option C: fading cache
Two code paths, bimodal, RAM hog. It's been tried.
Top of the cliff
Indexed engines. The entire category is two products.
Making a file-search index is hard. You have to build a data structure that answers any plausible query in under a millisecond, maintain it as the filesystem changes, survive reboots, and not eat all your user's RAM.
Everything survived because David Carpenter committed to MFT parsing twenty years ago and has maintained it every year since. Interlinked Files started from scratch in 2026 with twenty years of hardware and algorithms Carpenter didn't have, and added content search on top.
#1
14 µs filename, ~9 ms content. 2026.
#2
~1 ms filename only. No content search. 2006.
Bottom of the cliff
Everything else. The lineage runs back to 1973.
| Tool | Method | Speed on 4.47M files | Year | Ceiling |
|---|---|---|---|---|
| find | Recursive tree walk | Minutes | 1973 | Bound by syscall count |
| grep | Linear byte scan | ~62 s | 1974 | Bound by disk bandwidth |
| ls -R / dir /s | Recursive directory listing | ~30 s | 1971 | Bound by directory entries |
| ripgrep | Parallel byte scan + gitignore | ~18 s | 2016 | Faster shade of the same ceiling |
| VS Code search | ripgrep wrapper | ~20 s | 2015 | Same engine, UI overhead |
| Windows Search | Partial index, fading cache | 5 to 60 s | 2006 | Bimodal: fast on hits, slow on misses |
| Claude Code (agent) | grep + find + heuristics | >60 s | 2025 | Agent overhead on top of walker |
Every entry on this list descends from find (1973). The approach is the same: open the top of the tree, descend recursively, compare. None of them can get faster without becoming an indexed engine, which is the one thing they're architecturally committed to not doing.
There is no middle ground. You either invest in an index or you live at the bottom.
The cliff is structural, not incremental.The physics of the cliff
Why every “middle” attempt collapses to one side.
Imagine you're an engineer trying to build a file search tool that lands at 100 milliseconds per query on 4 million files. You think: I'll build something halfway between grep and an indexed engine.
You can't. An index either covers the query space or it doesn't. A partial index means every query either hits (1 ms) or falls through to the walker (60 seconds). Your average is bimodal, not middle. You're simultaneously on both sides of the cliff.
The tradeoff that doesn't exist
WITHOUT INDEX
Walk 4.47M files from root
0 bytes RAM · 0 s build time
WITH INDEX
MFT scan + trigram index
~1.5 GB RAM · ~90 s build
The 1.5 GB and 90-second build are the cost of living at the top. No partial payment accepted.
The AI problem
Every AI agent is a walker.
Claude Code, Cursor, Copilot: they all wrap grep and find. They live at the bottom of the cliff.
| Agent | Search method | On 4.47M files | Cliff side |
|---|---|---|---|
| Claude Code | Glob + grep, heuristic file discovery | >60 s per search | Bottom |
| Cursor | ripgrep + workspace indexing (partial) | 5 to 30 s | Bottom |
| GitHub Copilot | Tree-sitter + local ripgrep | 10 to 60 s | Bottom |
| Interlinked Files | MFT index + trigram content index | 14 µs / ~9 ms | Top |
The lesson
Pick a side.
If you're building a product that needs fast file search, the lesson is brutal: you either invest in an index and live at the top of the cliff, or you ship a walker and live at the bottom. The middle is a dead zone.
Every tool that tried to land in the middle (Spotlight in its early days, Windows Search, Everything's open-source knockoffs) ended up on the slow side, because the middle is structurally impossible to occupy.
Interlinked Files picked the top. 14 microseconds on 4.47 million files. No middle ground. No compromise.
Common questions
Questions from the cliff edge.
How is an 85-microsecond search even possible?
Interlinked Files keeps a prebuilt, always-fresh index of every file on the machine (names and contents alike) so a query is a hashmap lookup rather than a walk down the directory tree. On a 4.47M-file drive a single filename lookup lands in ~85 µs (139 µs median), below the threshold of human perception.
How much faster is it than VS Code, ripgrep, or Windows Search?
On the same drive it's roughly 412,000× faster than VS Code search and ~480,000× faster than Windows Search (67 s). For file contents it answers in 1 to 10 ms where ripgrep needs 93.8 s, a 58,625× gap (93.8 s → 16 ms).
Why does this matter for AI agents like Claude Code?
Every coding agent is a walker: it wraps grep and find and lives at the bottom of the cliff. A file hunt that costs Claude Code 6m57s across 71 tool calls collapses to a single 16 ms call through Interlinked Files (~7,200,000× faster), and the share of the context window spent searching drops from ~58% to ~0%.
Does keeping a live index of the whole machine eat memory or go stale?
No. The index idles at ~44 MB and reflects filesystem changes with ~1 ms freshness, so a file you just saved is already findable. Measured on a Ryzen 9 9950X3D indexing 4.47M files.
What does it cost?
Everything (including the agent integration over MCP for Claude Code, Cursor, Codex and the rest) is free forever, no card. Hosting starts at $5.99/mo.