Interlinked.

Explainers · measured July 2026

Agentic search is a loop, not a query.

When you search, you type once and scan the results. When an AI coding agent searches, it does something different: it runs a query, reads a few of the hits, decides they are not quite right, writes a sharper query, and runs it again, over and over until it has the context to act. That search-read-refine loop is what makes agents feel capable. It is also what makes them slow and expensive, because every turn of the loop is another tool call and another pile of tokens. Here is the loop, drawn on a real 4.47-million-file machine, and the one thing that decides whether it costs minutes or milliseconds.

The loop, drawn

Search. Read. Refine. Then do it again.

A one-shot search returns a list and stops. An agent's search is a cycle: each lap it searches the disk, reads the hits into its context, and (if that was not enough to answer) refines the query and goes around again. It exits only when a read is finally enough. Follow the arrows. The two stages tinted red are where the bill is run up: the search walks the disk (that is where the seconds go), and the read pours results into the context window (that is where the tokens go).

THE ASKHITSNOT ENOUGH CONTEXT↻ GO AGAINENOUGHQUESTIONone askSEARCHwalk the diskREADhits into contextREFINEa sharper queryANSWERenough at last◆ SECONDS PER LAP◆ TOKENS PER LAP◆ NEARLY FREEUP TO 71 LAPSmeasured · one file

Every lap pays both taxes (wall-clock on the search, tokens on the read), and the loop can run dozens of times before it exits. The counter in the middle is not a worst case; it is a measured run: 71 laps to locate one file. Shrink the cost of one lap, or the number of laps, and the whole loop gets cheaper.

Why the loop gets expensive

One question. Seventy-one searches.

The loop is powerful precisely because it is iterative: the agent corrects itself, narrows in, recovers from a bad first guess. But iteration has a price, and the price is paid per lap. We watched Claude Code find a single file on the benchmark machine and counted:

71
searches to locate one file, the measured lap count
6m 57s
wall-clock time the loop spent before it exited
~58%
of the session's tokens spent hunting, not thinking

Each of those 71 searches walked the disk and pushed its results back into the context window, where the model re-reads them on every turn that follows. The loop did not fail. It found the file. It just paid the search-and-read tax seventy-one times to get there. And none of this is the agent's fault, nor ripgrep's: the loop is the right strategy, and ripgrep is excellent at reading a disk quickly. The trouble is that the search primitive underneath the loop was never meant to be called seventy-one times to answer one question.

Same machine · same drive · same file

One turn of the loop, and the whole loop.

Underneath the loop sits a single search primitive. In Claude Code, that primitive is ripgrep, a fast, well-built tool that reads the filesystem on every call. One turn of the loop is one ripgrep run; the whole loop is that, times the number of laps. Measured on the same drive, the gap between one turn and the whole loop is exactly the multiplier from the diagram:

One turn / the loopWhat it doesTime · 4.47M filesvs Interlinked
Interlinkedone indexed lookup, no walk16 ms
ripgrep (the search Claude Code runs)content walk of the same drive93.8 s58,625× *
Claude Code · the whole loop71 searches to find one file6 m 57 s~7,200,000×

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. * 58,625× is the average across a five-query content set; on the single query shown, 93.8 s collapses to 16 ms from the warm index. Interlinked also returns a single file by name in 85 μs (139 μs median of 20 queries, best case 2 μs). Per-tool detail in the ripgrep comparison and the anatomy of a tool call.

The multiplier

A loop is only as fast as one turn of it.

Here is the uncomfortable arithmetic of agentic search: total cost is the cost of one search times the number of searches. That makes the search primitive the single most leveraged thing in the system. If one turn takes seconds, a 71-lap loop takes minutes, and the model can do nothing but wait on the disk. If one turn takes microseconds, the same loop finishes before you can blink. A faster primitive does something subtler, too: when a search returns the three files that matter instead of three thousand lines to sift, the agent needs fewer laps to be sure, so both terms of the product shrink at once.

WALKING THE DISK: ONE LAP IS SECONDS6m 57s× 71 lapsA WARM INDEX: ONE LAP IS MICROSECONDS16 ms× 1 lapthe loop barely begins: one precise answer, doneTOTAL COST = COST OF ONE SEARCH × NUMBER OF SEARCHESa faster primitive shrinks the first term; precise results shrink the second

Same loop, same agent, same question. The only thing that changed between the two bars is how long one search takes, and that one change is the difference between a 6-minute-57-second hunt and a 16-millisecond answer.

What we built

Make one search free, and the loop stops mattering.

Interlinked keeps a live, always-fresh index of every file on your machine: names and contents, every repo, including the git-ignored files a project-scoped search never sees. The agent asks; the answer comes back from memory instead of a disk walk. One turn of the loop stops taking seconds and starts taking microseconds, and because the result is precise, the loop usually collapses to a single lap. Same agent, same question, on the same 4.47-million-file machine:

93.8 s → 16 ms
the content search a lap runs, answered from the warm index instead of a disk walk
85 μs
a single file by name across 4.47M files (139 μs median of 20 queries, best case 2 μs)
71 → 1 call
the measured hunt: one precise answer, not seventy-one (about 7,200,000× end to end)
~1 ms
from saving a file to finding it, so the index is never stale (under 30 ms worst case)

The loop is still there. It is the right way for an agent to work. It just has nothing left to grind against. And the result that comes back can carry more than a path: on a fresh machine the index seeds itself from your own history (26,958 relationships across all 12 repos, replayed from 8,455 git events in 1.7 seconds), so a search can arrive already knowing which files change together. That is laps the agent never has to run.

NO MODEL IN THE LOOP: THE SEARCH IS AN INDEX AND A MATCH · EVERY ANSWER STAYS ON YOUR MACHINE.

Do this today

Give the loop a faster floor.

1

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

2

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

3

Stay fresh for free. Save a file and it is searchable in about a millisecond, under 30 ms worst case. The loop never searches a stale index.

4

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 microseconds. Either way, the loop is one lap, not seventy-one.

Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. No AI, no keys, no metered lookups. The index never leaves the machine. Download for Windows.

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