14 µs.
Not a typo.
The fastest query in our benchmark returns in fourteen microseconds. That's the wall-clock time to search 4.47 million files across a 4 TB4 Terabyte drive. Sound doesn't travel five millimeters in that time.
TL;DR
The whole thing, in five lines.
- A single-file search returns in ~85 µs (139 µs median) across 4.47M files on a 4 TB drive: a prebuilt, always-fresh index, not a filesystem walk.
- It runs 412,000× faster than VS Code’s Find in Files and ~480,000× faster than Windows Search, which needs ~67 s for the same query.
- Content search runs in ~7 to 9 ms; ripgrep takes 93.8 s and only reaches 16 ms warm, a 58,625× gap that’s architectural, not a micro-optimization.
- For an AI agent, one lookup drops from 6m57s across 71 tool calls to 16 ms in a single call (~7,200,000×), and search’s share of the context window falls from ~58% to ~0%.
- It idles at ~44 MB with ~1 ms freshness. Everything local is free forever, no card. Hosting starts at $5.99/mo.
Wall-clock latency
Across 4,470,000 files on a 4 TB4 Terabyte drive. Single thread. No warm-up tricks.
The operating system is the bottleneck, not the engine.
Best case
Light travels 4.2 km in this time
Median
What a user actually experiences
What 14 microseconds looks like
Nine reference points at the edge of what hardware can do.
| Reference | Latency | 14 µs equals |
|---|---|---|
| L1 cache hit | ~1 ns | 14,000 of these |
| L2 cache hit | ~4 ns | 3,500 of these |
| L3 cache hit | ~15 ns | 930 of these |
| DDR5 access (miss) | ~75 ns | 186 of these |
| Branch mispredict | ~2 ns | 7,000 of these |
| Light through air (14 µs) | 4.2 km | About one neighborhood |
| Sound through air (14 µs) | ~5 mm | The width of a small coin |
| A single Python function call | ~100 ns | 140 of these |
| One pixel drawn to screen | ~10 ns | 1,400 of these |
These aren't impressive numbers on their own: any kernel engineer would shrug. They exist to anchor what 14 microseconds actually is. A file search engine returning results in the time it takes light to cross a neighborhood.
The anatomy of one query
What happens in those 14 microseconds.
The caller submits a query to the background daemon. The OS carries the request across a process boundary. That alone eats a few microseconds. The daemon wakes the handler thread, looks up the query in its in-memory index, collects matching file records, and serializes them. The OS carries the response back. The caller deserializes.
Of those steps, only the index lookup touches “the algorithm.” Everything else is overhead: IPC framing, thread scheduling, context switches, memory copies. The actual lookup work is in the noise.
IPC overhead
Named pipe round-trip, context switches
Index lookup
The actual algorithm. In the noise.
A faster engine wouldn't help. The OS is the bottleneck.
The wall is how fast the kernel moves bytes between processes.The full spectrum
From best case to worst case, everything is under a millisecond.
The median query is 130 µs, what a user actually experiences. The best case of 14 µs is a short unique substring hitting a cache-hot path with no wasted branches.
Short unique substring, cache-hot
Typical lookup during normal work
Broad pattern, many partial matches
Worst observed, still sub-millisecond
Burst throughput
queries/sec, single thread
Corpus
files indexed on the volume
vs Claude Code
the wide end of the ratio
Why the best case matters
The floor is the ceiling.
Median numbers are more useful for planning. Best-case numbers tell you something different: how fast the engine can recover between queries in a tight loop.
At 14 µs per best-case lookup, the engine can sustain roughly seventy thousand queries per second on a single calling thread. That's enough that an agent running against it no longer needs to think about search as a budgeted operation.
The shift
Before
“Be careful with search calls”
Budget-constrained, minimize queries
After
“Be wasteful with search calls”
71K queries/sec, search is free
That shift is the whole reason to build this kind of engine.
Comparison
How others measure up.
Same corpus, same machine, same queries. The gap isn't an optimization difference. It's an architecture difference.
| Engine | Best case | Median | Architecture |
|---|---|---|---|
| Interlinked Files | 14 µs | 130 µs | Trigram index + named pipe IPC |
| ripgrep (content) | ~12 s | ~67 s | Walk + regex scan (no index) |
| VS Code Find in Files | ~8 s | ~35 s | Glob walk + content scan per query |
| Claude Code (find) | ~2 min | ~7 min | Agentic loop: subprocess + walk + regex |
The bigger picture
Search as a free operation changes what agents can do.
Today's coding agents treat file search as expensive. They minimize lookups, guess paths, cache results manually, and fail when their guess is wrong. That entire class of failure disappears when search costs nothing.
An agent with 71,000 queries per second can scan an entire codebase by firing thousands of lookups in sequence and still respond in under a second. It can verify every assumption. Check every import. Confirm every path exists before acting on it.
The 14 µs best case isn't the point. The point is what becomes possible when the floor is this low. File search stops being a tool the agent uses carefully and becomes infrastructure it breathes.
Common questions
What people usually ask.
Q1Why is it so much faster than a normal file search?
The engine keeps a prebuilt, always-fresh in-memory index of every file’s name and contents, so a query is an index lookup rather than a directory walk. At ~85 µs per single-file search, the operating system’s cross-process IPC (not the algorithm) becomes the bottleneck.
Q2How does it compare to ripgrep, VS Code, and Windows Search?
On the same 4.47M-file corpus it is 412,000× faster than VS Code’s Find in Files and ~480,000× faster than Windows Search (~67 s). For content search it runs in ~7 to 9 ms versus ripgrep’s 93.8 s cold, a 58,625× gap once the index is warm at 16 ms.
Q3Why does this matter for AI coding agents?
Agents treat file search as expensive, so they minimize lookups and guess paths. A task that took an agent 6m57s across 71 tool calls collapses into a single 16 ms call (~7,200,000× faster), and that search’s token cost drops from ~58% of the context window to ~0%, so the agent can verify every path instead of rationing lookups.
Q4Does the index stay fresh, and how heavy is it?
Yes: edits show up with ~1 ms freshness, and the background service idles at ~44 MB. It is a daemon maintaining an index, not a scanner that re-walks the disk per query. All figures are measured on a Ryzen 9 9950X3D over 4.47M files.
Q5What does it cost, and does anything leave my machine?
Everything local, the desktop app and the agent integration (MCP for Claude Code, Cursor, Codex and others), is free forever, no card. Hosting starts at $5.99/mo. There is no AI in the box, and the index never leaves your machine: nothing is uploaded unless you publish a project or a link.