Interlinked.

Explainers · measured July 2026

The anatomy of an agent tool call.

When an AI agent does anything on your machine (reads a file, searches your code, checks a config) it makes a tool call. You see a tidy one-line summary. Underneath, six stages fire in order, and almost all of the wall-clock time and roughly half of the token bill hide in just two of them. This is the whole path, stage by stage, measured on a real 4.47-million-file machine, and the two places an index changes everything.

TL;DR · the whole piece in five lines

Six stages, two hot. Every agent tool call runs six stages; nearly all the wall-clock time and about half the token bill hide in just two: the disk hop, and the bytes that come back.

The disk hop is the seconds. On a 4.47M-file machine one ripgrep content query takes 93.8 s and Windows Search 67 s; a warm index answers by name in 85 μs (139 μs median), 412,000× faster than a VS Code-class open, ~480,000× vs Windows Search.

The bytes are the tokens. A raw grep result is thousands of lines the model re-reads every turn. One measured Claude Code session spent ~58% of its tokens on file hunting, not thinking.

One index kills both taxes. Content that took ripgrep 93.8 s returns in 16 ms (58,625× on the set); a 71-call, 6 m 57 s hunt collapses to one 16 ms call: ~7,200,000× end to end, ~58% → ~0% of tokens on search.

Warm, private, free to keep fresh. No model in the loop: just an index and a hashmap, on your machine. It idles at ~44 MB and re-indexes a saved file in ~1 ms. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.

One call · six stages

You see one line. The machine runs six stages.

Read it top to bottom. The two lanes on the right are the only things that matter: how much wall-clock a stage burns, and how many tokens it costs. Notice that both meters stay near-empty everywhere except two rows, and that the loop at the bottom pays for the whole thing again on the next call.

WALL-CLOCK TIMETOKENS / $1THE MODEL EMITS A CALLpicks a tool, writes the arguments: a tool_use blockone model turn~40 tokens out2THE HARNESS DISPATCHESClaude Code / Cursor runs the real tool on your diskprocess spawnnone3THE DISK HOPthe tool walks the filesystem and reads the bytesup to 93.8 snone◀ the seconds live here4BYTES COME BACKhits and file text are packed into a tool_resulta copy1,000s of lines◀ the token bill lives here5THE MODEL READS ITingested now, and re-read on every later turnone model turnre-read each turnANSWER, OR CALL AGAINone question becomes many calls; each pays both taxes× 71 CALLS TO FIND ONE FILE

Two stages are red. Stage 3, the disk hop, spends the seconds. Stage 4, the bytes coming back, spends the tokens. The model stages on either side are fast and cheap by comparison. Every optimization worth making is aimed at those two red rows.

Stage 3 · the latency tax

The seconds live in the disk hop.

The model deciding to call a tool takes one turn. Dispatching it takes a process spawn. But the moment the tool touches the filesystem, it stops being fast, because the tools an agent shells out to were built to walk the disk, not to skip it. On a 4.47-million-file drive, the same lookup that should be free becomes the slowest thing in the loop:

93.8 s
one content query with ripgrep, the tool Claude Code runs
35 s
opening a file by name in a VS Code-class editor
67 s
Windows Search, median of 20 whole-drive queries

A tool call is only as fast as its slowest stage, and its slowest stage is the disk. None of this is the tools' fault: ripgrep and grep are excellent at what they do, which is read the filesystem quickly. They just have to read all of it, on every query, because nothing warmer exists machine-wide.

Same machine · same drive · same disk hop

The same call, under Claude Code and Cursor.

The two most popular agents take different paths to the same place. Claude Code shells out to grep and glob. Cursor keeps a semantic index of the repo you opened (genuinely useful inside that folder), but an agent's questions rarely stay inside one folder. The moment the query leaves the workspace (another repo, a config, a git-ignored file, the PDF with the answer), Cursor falls back to the same disk walk. Both land on stage 3.

The searcherThe disk hop it runsTime · 4.47M filesvs Interlinked
Interlinkedan indexed lookup, no walk85 μs
Claude Code (Grep / Glob)ripgrep content walk of the disk93.8 s58,625× *
Cursorrepo index inside the folder; disk walk outside it35 s †412,000×
Windows Searchfull-drive search, median of 2067 s~480,000×
Claude Code · full run71 calls to find one file6 m 57 s~7,200,000×

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Interlinked, same tasks: 85 μs by name, 139 μs median of 20, 16 ms on the 93.8 s content query. * 58,625× is the average across the five-query content set; on the single query shown, 93.8 s collapses to 16 ms. † Cursor is built on VS Code; its file-open and outside-workspace search use the same machinery. Per-tool detail in the ripgrep comparison and the 412,000× write-up.

Stage 4 · the token tax

The bill lives in the bytes that come back.

Latency is the visible cost: you feel the wait. The token cost is invisible, and larger over a session. When the disk hop finishes, its raw output becomes a tool_result the model must read. A grep that matched a common word returns thousands of lines. Every one is an input token, and the model re-reads the whole transcript on every turn that follows.

Raw disk dump

1,000s of lines input tokens, re-read every turn

Indexed answer

license.ts · L42
validate.ts · L110
keys.ts · L7

the 3 files that matter a few hundred tokens

~58%
of one measured Claude Code session's tokens went to file hunting, not thinking. On a $200/month plan, that is the model reading directory listings it forgets a turn later.

Both red rows at once

One index. Both taxes gone.

Pre-index the machine once and keep it warm, and stage 3 stops walking the disk: it answers from memory. That alone collapses the seconds. But it also fixes stage 4: an index returns the handful of files that actually match instead of a page of grep output, so the tool_result that flows back is small. The same lookup pays neither tax. And because the answer is precise, the agent stops looping to disambiguate. The multiplier drops too.

85 μs
the disk hop, indexed: a single file lookup across 4.47M files (139 μs median of 20)
93.8 s → 16 ms
the same content query that took ripgrep 93.8 s, answered from the warm index
71 → 1 call
the measured session: 6 m 57 s of hunting became one call, ~7,200,000× faster end to end
~58% → ~0%
of session tokens spent on file search once the result is three files, not three thousand lines

The bytes that come back can carry more than paths, too. On a fresh machine the index seeded 26,958 relationships from 8,455 git events across all 12 repos in 1.7 seconds, so a result can arrive already knowing which files change together and what a past agent noted about them. That is future tool calls the agent never has to make.

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

Common questions

The tool call, answered.

QWhat exactly is an agent 'tool call'?

When an AI agent reads a file, searches your code, or checks a config, it emits a structured tool_use block; the harness (Claude Code, Cursor) runs the real tool on your disk and feeds the result back. You see one tidy line; six stages fire underneath.

QWhy is searching my own machine so slow for an agent?

The tools an agent shells out to (ripgrep, grep, editor search) were built to walk the filesystem, not skip it. On a 4.47M-file machine one ripgrep content query takes 93.8 s and Windows Search 67 s, because nothing warmer exists machine-wide.

Q412,000× faster: is that number real?

Yes, because an index never walks the disk. A prebuilt lookup answers by name in 85 μs (139 μs median of 20) instead of scanning 4.47M files, 412,000× faster than a VS Code-class open and ~480,000× vs Windows Search. The 93.8 s content query returns in 16 ms.

QWhy do tool calls burn so many tokens?

A grep that matches a common word returns thousands of lines, and the model re-reads that whole transcript on every later turn. One measured Claude Code session spent ~58% of its tokens on file hunting; an index returns the handful of files that matter instead, dropping that toward ~0%.

QDoes anything leave my machine, and what does it cost?

Nothing leaves: there is no model in the loop, just an index and a hashmap answering locally. The engine idles around ~44 MB and re-indexes a saved file in ~1 ms. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.

Do this today

Give the disk hop a shortcut.

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, and the index on disk stays 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 index tracks changes as they happen, so stage 3 is never stale.

4

Scope when you can. Whole-machine when you do not know where something lives; scoped to a folder when you do: scoped queries return in microseconds.

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

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