Interlinked.

Explainers · measured July 2026

Do AI coding agents need a file index? Only after you cross a line.

The honest answer has two halves. For a toy repo, no: ripgrep walks a few hundred files in under a millisecond, and nothing beats a tool that needs no setup. For a real machine (a dozen repos, the files git ignores, the document with the answer) the same walk takes 93.8 seconds, and an agent runs it hundreds of times a day. This piece is about where that line sits, and the math on either side of it.

TL;DR · key takeaways

The short version. Five lines.

  • For a toy repo, no: ripgrep walks a few hundred files in under a millisecond, and nothing beats a tool that needs no setup.

  • For a whole machine, yes: the content search ripgrep walks in 93.8 s an index answers in 16 ms: 58,625× across the query set, on a Ryzen 9 9950X3D holding 4.47M files.

  • Filenames win widest: 85 μs a lookup (139 μs median), 412,000× over VS Code and ~480,000× over Windows Search’s 67 s.

  • Agents gain the most: one real hunt went 6 m 57 s / 71 tool calls 16 ms / 1 call, and file-search tokens fell from ~58% of a session to ~0%.

  • It stays flat and fresh: searchable in ~1 ms after a save, ~44 MB idle, no model, every hit a literal match. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.

The crossover

Where walking loses to an index. It has a shape.

Walking the disk and looking something up cost about the same on a tiny repo. Then the two curves separate: one climbs with every file you add, the other barely moves. Plot cost against corpus size and the whole decision fits in one picture. There is a crossover, and to its right the gap only widens.

0.1 ms1 ms10 ms100 ms1 s10 s100 s1001K10K100K1M10MCORPUS SIZE: FILES ON THE MACHINE (LOG)TIME PER CONTENT QUERY (LOG)toy repoone big repowhole machine · 4.47M filesWALK THE DISK · ripgrepLIVE INDEX · InterlinkedCROSSOVERwalk ≈ index ≈ 7 ms← ripgrep winsindex wins →~1,500 files93.8 s16 msTHE CLIFF

Both axes are logarithmic. Two real endpoints are pinned: a single whole-machine content query on the benchmark machine takes 93.8 s to walk and 16 ms to look up. The curve between them is the cost model, not measured points. The filename lane is steeper still: microseconds against tens of seconds. Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files.

The honest half

When you don't need an index. ripgrep already won.

An index earns its keep by amortizing a walk you would otherwise repeat. If you won't repeat it (or there is barely anything to walk), there is nothing to amortize, and the index is pure overhead. In these cases, reach for ripgrep and don't look back.

Small corpus
A toy repo

A few hundred files is a few hundred kilobytes. ripgrep reads all of it before an indexed round-trip finishes handshaking. Left of the crossover, the walk is genuinely the faster call.

One and done
A one-off query

You’ll run it once and never again. There is no repetition to pay back the cost of building and holding an index. A single walk is the right amount of work.

Narrow + exotic
One folder, any regex

You’re already inside the directory you care about, or you need an arbitrary regular expression over raw bytes. That’s ripgrep’s home turf: scoped, literal, exact.

None of this is a knock on ripgrep. It is the best content searcher ever written, and it is exactly the right tool on the left side of the chart. The question was never “is walking bad?” It was “how big does the corpus get before walking it every time stops making sense?”

The other half · Ryzen 9 9950X3D · 4.47M files

When you cross the line, it isn't close.

Three things flip the math at once on a real developer machine: the corpus is huge, the agent runs the same class of query hundreds of times a session, and it searches places no single-repo tool looks: sibling repos, build output, downloads, the git-ignored config with the answer. That's where our two famous anchors land, one on each axis of the cost.

ANCHOR 1 · THE WALL CLOCK
The best walker still walks.

ripgrep is not the slow option: it is the fastest byte-reader there is. But it has to read the bytes, and on this machine one whole-machine content query is 93.8 seconds of honest work. Run it once, fine. Run it in an agent loop and you've built a very slow database that rebuilds itself on every question.

ANCHOR 2 · THE TOKEN BILL
You pay for the model to read ls.

On a premium plan like Claude Max, we measured ~58% of a session's tokens going to file hunting: the model reading walls of directory output it forgets a turn later. Tokens spent grepping are tokens not spent thinking. You're paying top-tier rates for ls.

The six-order cliff

Put every measured comparison on one scale and the right side of the crossover comes into focus. These are not close calls: the index wins by four to nearly seven orders of magnitude, depending on the lane.

HOW FAR THE INDEX WINSsame 4.47M-file machine · bigger bar = larger gap · log scale10×100×1K×10K×100K×1M×10M×A full agent hunt → one lookup6 m 57 s → one indexed call≈7,200,000×Single lookup vs Claude Code193.5 s → 85 μs2,276,000×Filename vs Windows Search67 s → 139 μs (median)~480,000×Filename vs VS Code35 s → 85 μs412,000×Content vs ripgrepthe 5-query set average58,625×Toy repo vs ripgrepa few hundred files1×, a tie
ONE FILE, ONE REAL AGENT RUN
6m 57s → 16ms
time to find the file: without, then with the index
71 → 1
tool calls the agent spent hunting
~58% → ~0%
session tokens burned on file search

Show the work · same machine, same drive

The raw times behind the cliff.

The toolThe taskTimevs Interlinked
Interlinked (live index)filename / content lookup85 μs / 16 msbaseline
VS Code · Ctrl+Pone filename, same drive35 s412,000×
Windows Searchfilename, median of 2067 s~480,000×
ripgrepone whole-machine content query93.8 s → 16 ms58,625× (set)
Claude Code (no index)find one file, agent loop6 m 57 s → 16 ms~7,200,000×

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename rows compare each tool's time to Interlinked's 85 μs single-file lookup (median 139 μs across 20 queries; best case 2 μs). The ripgrep row is one whole-machine content query: 93.8 s to walk, 16 ms to look up; 58,625× is the average across the five-query content set. The Claude Code row is the measured agent run. Full per-tool method in the ripgrep comparison and the 412,000× write-up.

The flat line has a name

The index that stays flat. Whole-machine, fresh, no model.

The flat curve on the chart is a real thing: an always-warm background index of every file's name and contents, across every repo and the files git ignores. Save a file and it's searchable in about a millisecond (under 30 ms in the worst case), so it never goes stale and never needs re-embedding. At rest the whole engine sits near 44 MB, and its on-disk index is under 1% of the drive. No model is in the loop: every hit is a literal match you can verify, and nothing leaves the machine. It runs parallel to your model and your vector database, not against them.

16 ms
one whole-machine content query, flat whether the corpus is one repo or 4.47M files
~1 ms
from saving a file to that file being searchable, under 30 ms worst case
0 LLMs
every result is a literal match you can check, never a model’s guess, never an embedding to drift

SAME INDEX, DAY ONE: 12/12 REPOS FOUND · 8,455 GIT EVENTS REPLAYED IN 1.7 s · 26,958 RELATIONSHIP PAIRS · NO MODEL.

Cross it today

Give every agent the flat line.

1

Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON to edit.

2

Let it index. Filename search works immediately; content fills in behind it. At rest the whole engine sits near 44 MB (less than a browser tab) and the index is under 1% of the drive.

3

Keep ripgrep for the left side. Toy repo, one-off, a folder you’re already in: walking is still the right call. Hand the agent the index for everything past the crossover: whole-machine, every repo, the files git ignores.

4

Let it stay fresh. Save a file and it’s searchable in about a millisecond. No re-embedding, no re-index step, no drift: the curve stays flat as your machine grows.

Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.

Common questions

Questions people ask. Answered straight.

So do I actually need one?

Only past the crossover. For a toy repo or a query you’ll run once, ripgrep reading a few hundred files in under a millisecond is the right tool. Once the corpus is a whole machine (here 4.47M files) and an agent runs the same class of query all day, walking it every time costs 93.8 s a shot while an index answers in 16 ms.

Does this replace ripgrep?

No. It runs parallel to it. ripgrep is the fastest byte-reader there is and wins left of the crossover: small, scoped, one-off, or an arbitrary regex over raw bytes. The index wins right of it, whole-machine and repeated. Keep both, and hand each the side of the chart it owns.

Is there an LLM or embeddings under the hood?

No model is in the loop. Every result is a literal match you can verify, so there’s nothing to hallucinate and no embedding to drift, and nothing leaves the machine. It runs alongside your model and vector database, not against them.

Won’t the index go stale?

No. Save a file and it’s searchable in about ~1 ms, so there’s no re-index step and no re-embedding to schedule: the curve stays flat as the machine grows. At rest the whole engine sits near 44 MB, less than a browser tab.

What does it cost?

Everything (including the MCP layer for Claude Code, Cursor, Codex and others) is free forever, no card. Hosting starts at $5.99/mo. For scale: one measured agent hunt dropped from 6 m 57 s across 71 tool calls to 16 ms in a single call.

Measured July 2026 · Ryzen 9 9950X3D · 4.47M files · Windows 11← All research