Agents · measured July 2026 · 7 min
How Claude Code finds files, and why it's slow.
Ask an agent to open the file that logs a request and it hits a wall you never see: it does not know where that file is. It has no map of your machine, only shell tools. So it guesses: list a folder, grep for a word, read a candidate, decide, try again. On a real 4.47-million-file drive we watched that loop run 71 times over 6 minutes 57 seconds and burn about 58% of the session's tokens before it opened the right file. Here is exactly what happens, and why one indexed call ends it in 16 milliseconds.
TL;DR
Five lines, then the proof.
Agents can't see your machine. Claude Code and its peers have no map, only shell tools (ls, grep, read), so they guess their way to a file. On a 4.47M-file drive that loop ran 71 times over 6m 57s and burned ~58% of the session's tokens to open one file.
One indexed call ends the loop. The same lookup returns the exact path in 16 ms, one call, ~0 tokens. About a 7,200,000× swing on the same machine, model unchanged.
Filenames resolve in 85 µs. A name lookup across 4.47M files takes 85 µs (139 µs median), roughly 412,000× faster than VS Code's Ctrl+P and ~480,000× faster than Windows Search (67 s).
Contents resolve in 7-9 ms. Where ripgrep walks the disk for 93.8 s, indexed content search answers in 7-9 ms, 58,625× across a five-query set (93.8 s → 16 ms on one query).
Warm, cheap, free to start. The index idles at ~44 MB and refreshes in ~1 ms as you save. Everything local is free forever, no card. Hosting starts at $5.99/mo.
The loop, drawn
Every file it opens starts with a guess.
An agent's tools are the same ones a person types into a terminal: ls and Glob to list, grep to scan, read to open. The model picks one, runs it, reads the output, decides what to try next, and repeats. Every pass also re-reads the whole growing transcript, so the loop gets more expensive the longer it runs. That is the entire mechanism.
Same machine, same drive. The loop on the left is what runs today; the call on the right is one MCP tool away.
One real task, measured
We watched it hunt for one file.
The distance between hunting for a file and knowing where it is. A narrower, cleaner test (finding one file by name) put Claude Code at 193.5 seconds against the same indexed lookup at 85 microseconds: 2,276,000×, on the same drive.
This was Claude Code running Anthropic's strongest agent. The $200-a-month Claude Max plan buys a better model, not a better floor: the tools underneath are the same ls, grep and read, so the smartest agent still spends most of a session finding things instead of building them. Measured on a Ryzen 9 9950X3D, 64 GB DDR5, NVMe, Windows 11, 4.47M files.
Same machine · same drive · same jobs
The two famous anchors, and everything else that searches.
ripgrep is the fastest grep there is, and it is what an agent shells out to for content. It still walks the disk on every query. Line them up on one drive:
| The searcher | The job | Time | vs Interlinked |
|---|---|---|---|
| Interlinked | one indexed call, filename or content | 85 µs / 16 ms | the baseline |
| Claude Code (Opus, single lookup) | 71-call shell hunt for one file | 193.5 s | 2,276,000× |
| ripgrep | grep one string across the drive | 93.8 s | 58,625× (5-query set) |
| VS Code (Ctrl+P) | open a file by name | 35 s | 412,000× |
| Windows Search | find a file by name (median of 20) | 67 s | ~480,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename lookups are 85 µs single (2 µs best case) and 139 µs median of 20 queries. Content search runs 7-9 ms across a five-query set; ripgrep averaged 58,625× slower on that set, and on one representative query took 93.8 s to Interlinked's 16 ms. VS Code Ctrl+P (412,000×) and Windows Search (~480,000×) are the file-open and median-of-20 times on the same drive.
Why the loop exists
The tools were built for one open project, not a whole machine.
VS Code indexes the folder you opened. Cursor indexes the repo you're in. Both are fast, inside that one boundary. But an agent's questions don't respect folder boundaries: the answer might be in a sibling repo that ships alongside this one, or in the 90% of the disk that was never in git: a config, a document, a log. Nothing keeps a warm view of all of that.
So the agent falls back to the floor: ripgrep and ls, re-walking the disk on every single query, because nothing machine-wide is kept ready between them. The model isn't the bottleneck. It does exactly what a person would do with the same tools. The floor it stands on is what's slow.
The fix
One call. The loop is gone.
Interlinked keeps a live index of every file on the machine (names and contents) and exposes it to any agent over MCP. One signed install auto-configures 19 AI clients, Claude Code among them. Once the indexed-search tool is registered, the agent stops reaching for grep. It makes one call and gets the exact path back: no walk, no retries. The index sits warm in the background at about 44 MB, updates as you save (~1 ms typical, under 30 ms worst case), and every hit can carry notes and relationships the engine derived itself.
Same agent · same model · same query
Without index
With Interlinked
71 blind filesystem walks replaced by a single index lookup. Same model, same machine: a different floor.
THE MODEL DIDN'T GET SMARTER. THE FLOOR GOT FASTER. THAT'S THE ONLY THING THAT CHANGED.
Common questions
The questions everyone asks next.
Why is Claude Code slow at finding files?
It has no index of your machine, only shell tools like ls, grep and read, so it guesses its way to a file: list, scan, read, decide, retry. On a 4.47M-file drive that loop ran 71 times over 6m 57s before it opened the right file.
Does a bigger plan like Claude Max fix it?
No. A $200-a-month plan buys a stronger model, not a faster floor: the tools underneath are the same ls, grep and read, so even the smartest agent still re-walks the disk on every query.
How much faster is an indexed lookup?
A filename lookup returns in 85 µs across 4.47M files, about 412,000× faster than VS Code's Ctrl+P and ~480,000× faster than Windows Search (67 s). Content search answers in 7-9 ms where ripgrep takes 93.8 s, so the whole agent task drops from 6m 57s and 71 calls to 16 ms and one call.
Doesn't a background index eat memory and go stale?
It idles around 44 MB (less than a browser tab) and updates as you save, typically in about 1 ms. The on-disk index stays under 1% of the drive, so it stays fresh without a manual re-scan.
How do I give my agent the index, and what does it cost?
One signed installer auto-configures 19 AI clients (Claude Code, Cursor, Codex, Copilot, Zed and the rest) over MCP, with no JSON editing. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
Do this today
Give your agent a map.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed and the rest. No JSON editing.
Let it index. Filename search works immediately; content search fills in behind it. At rest the whole engine sits around 44 MB, and updates as you save.
Scope when you can. Whole-machine when you don't know where something lives; scoped to a folder when you do. Scoped queries return in the microsecond range.
Let the loop die. The agent trades 71 blind tool calls for one call that returns the exact path, and stops spending its token budget on directory listings.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.