Research · Apr 9 2026 · 6 min
The CLI tax.
Fifty years of walking.
Every command-line file search tool in common use today is a descendant of 1970s Unix. find. grep. locate. ack. ag. fd. ripgrep. Each one faster than the last. Every single one still walks the filesystem at query time.
TL;DR · Key takeaways
The short version.
85µs: filename search across 4.47M files, answered from a prebuilt index instead of a filesystem walk (139µs median). Every CLI tool from find (1973) to ripgrep still walks the disk at query time; Interlinked Files doesn't.
412,000×: faster than VS Code's built-in search on the same machine, and ~480,000× faster than Windows Search, which takes 67 s for the same query.
7 to 9 ms: full-text content search, versus 93.8 s for ripgrep on a cold cache (58,625× at 16 ms). The index stays fresh in ~1 ms per change via the NTFS journal: never stale, never re-walked.
7,200,000×: a real agent task that spent 6m 57s across 71 grep/find calls collapses to a single 16 ms call. Search drops from ~58% of the session's tokens to ~0%; the daemon idles at ~44 MB.
Free: everything local is free forever, no card. Hosting starts at $5.99/mo.
Interlinked Files
filename search across 4.47M files
ripgrep (best walker)
still walks 4.47M files every single time
The lineage
Every one a step forward. Every one still walking.
| Tool | Year | Approach | Speed on 4.47M files |
|---|---|---|---|
| find | 1973 | Walks directory tree every invocation | ~70 s |
| grep -r | 1973 | Full content walk | ~70 s |
| locate / mlocate | 1983 | Daily cron rebuild of a flat file DB | Fast but always stale |
| ack | 2005 | Perl grep with language filters | Slower than grep |
| ag (the silver searcher) | 2011 | Parallel C grep | ~23 s |
| ripgrep (rg) | 2016 | SIMD, parallel, .gitignore-aware | ~8 s |
| fd | 2017 | Rust find replacement, .gitignore-aware | ~5 s |
| Interlinked Files | 2026 | Queries local daemon’s prebuilt index | 130 µs |
From find in 1973 to fd in 2017, the history of CLI file search is a history of making the walker faster. The one thing nobody did was stop walking.
The exception that proves the rule
locate is fast. It's also always wrong.
There is exactly one CLI tool from the Unix tradition that uses an index. locate builds a flat file of every path on the drive once a day, typically via a cron job at 3 AM. Queries are fast because they're just grep over a text file. The catch is that the flat file is always stale. A file you created this morning won't show up until tomorrow.
locate got the index right while getting freshness spectacularly wrong. Every other tool responded by doubling down on the walker. “locate is stale, so we'll walk.” That decision cemented the CLI tax for another four decades.
locate (1983)
Always 12+ hours stale
Interlinked Files (2026)
Real-time via NTFS journal
Why this matters now
Agents reach for the CLI because that's what their tools expose.
Claude Code, Cursor, Aider, and every other coding agent in 2026 runs shell commands as its primary way of interacting with the filesystem. The shell commands they know are grep, find, and ripgrep.
The CLI tax was invisible for humans because humans grep occasionally and wait a second. The tax became catastrophic the moment AI agents started firing shell tools on every turn. A three-second lookup was manageable once an hour and ruinous sixty times an hour. That's the shape of the modern agent session.
Fixing this at the agent level is thankless. Every agent would have to individually stop reaching for grep and find, ship their own indexed replacement, maintain it, and ship their own watcher. None of them will. It's infrastructure, and infrastructure doesn't sell IDEs.
The agent tax
What 60 searches per hour actually costs.
| Scenario | Tool | Time per search | 60 searches | Verdict |
|---|---|---|---|---|
| Typical agent session | find + grep | ~70 s | 70 min wasted | Unusable at scale |
| Optimized agent | ripgrep | ~8 s | 8 min wasted | Bearable but painful |
| Best fast walker | fd | ~5 s | 5 min wasted | Better, still serial |
| Indexed daemon | Interlinked Files | 85 µs | 5 ms total | Invisible |
The agent doesn't know or care what's behind the tool. 60 lookups go from 70 minutes to 5 milliseconds. Same questions. Same answers. Five orders of magnitude faster.
The CLI tax was the cost of never having a daemon.
The next generation pays it once and the query cost never.How Interlinked Files works
CLI, but backed by a daemon.
The daemon runs in the background, all day, quietly maintaining its index via the NTFS change journal. Every file creation, rename, deletion, and move is captured in real time without polling, without walking, without touching the disk.
An MCP bridge sits on top of the same daemon. Claude Code, Cursor, or any MCP-compatible agent connects once and gets the same sub-millisecond answers without the agent vendor changing a line of code. The tax stops being charged because it stops being applicable.
Architecture comparison
Traditional CLI
Agent calls grep / find / rg
Each call walks entire filesystem
Indexed daemon + MCP
Agent calls MCP tool
Daemon queries prebuilt index via named pipe
Same questions. Same answers. 94,000× faster.
By the numbers
What the daemon delivers.
Filename search
4.47M files indexed
Content search
446K code files indexed
Index freshness
NTFS journal, zero polling
Memory overhead
Background daemon, invisible
The next decade
The daemon changes who wins.
Fixing file search at the CLI level is where it belongs. Ship a local indexed daemon. Register an MCP server so every agent can use the same daemon without knowing about it. Suddenly every agent on the machine can answer the same file lookups in microseconds, without the agent vendor changing a line of code.
SWE-bench Pro shows a 22+ point swing between different agent scaffolds using the same model. The retrieval infrastructure matters more than the model weights. The agent with the best file search wins. Every time.
The CLI tax was the cost of never having a daemon. The next generation pays the daemon cost once and the query cost never. Humans win. Agents win more.
Common questions
Frequently asked.
How is Interlinked Files so much faster than grep or ripgrep?
It never walks the filesystem at query time. A background daemon keeps a prebuilt index of every file's name and contents, so a query is an index lookup rather than a disk scan. Filename search returns in 85µs across 4.47M files; content search in 7 to 9 ms, where ripgrep needs 93.8 s on a cold cache.
Does the index go stale, the way the old locate command did?
No. Instead of a nightly cron rebuild, the daemon watches the NTFS change journal and applies every create, rename, delete, and move in ~1 ms. A file you save this second is searchable this second.
How much faster is it for AI agents specifically?
An agent's search cost compounds because it fires shell tools on nearly every turn. One measured task took 6m 57s across 71 grep/find calls; through Interlinked Files it was a single 16 ms call (about 7,200,000× faster) and search fell from ~58% of the session's tokens to ~0%.
What does it cost, and how heavy is the daemon?
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. The daemon idles at ~44 MB and needs no configuration.
How do coding agents like Claude Code or Cursor connect to it?
It exposes a local MCP server, so any MCP-compatible agent connects once and gets the same sub-millisecond answers with no code changes on the agent's side. All figures here were measured on a Ryzen 9 9950X3D indexing 4.47M files.