Interlinked.

Agents · measured June 2026 · recovered August 2026 · 7 min read

71 tool calls. Three tools.

We've quoted the number for months: Claude Code spent 71 tool calls and 6m 57s to find one file on a 4.47-million-file machine. We never showed what was in those 71. So we went back to the tape and pulled every call. The answer is worse than “slow”: it used three distinct tools, ran one of them forty-seven times with a single character changed, and in the end never found the file by searching at all.

71
tool calls, self-reported by the agent
3
distinct tools across all of them
37.9k
tokens burned inside the subagent
1
call that actually returned the answer

TL;DR

What was actually in the 71, in five lines.

  • The prompt was “find iron man movie on my computer”. Claude Code v2.1.39 on Opus 4.6 dispatched one Explore subagent, which reported Done (71 tool uses · 37.9k tokens · 6m 41s). The full turn: 6m 57s.
  • Across all 71 calls it used three tools: Glob, Bash, Read. Roughly 47 · 22 · 2.
  • The glob block is a nested loop over {extension} × {folder}, re-issued with one token swapped. When it emptied, the agent ran the identical sweep three more times: PowerShell, cmd, WSL bash.
  • It never searched C:\Movies\, where the file was. Call 61 read a leftover Windows Recent-items shortcut and lifted the path out of it. Sixty calls of searching found nothing; an accident found the file.
  • With a live index the same question is one call, 16 ms: a filename lookup returns in 85 µs (139 µs median across 4.47M files), and the tokens spent hunting drop from ~58% to ~0%.

Same question, same machine

One call, or seventy-one.

These are the clips that run on our homepage. Left: the agent asks the index once and gets the exact path back. Right: the same model, the same machine, the same file, with nothing but glob and bash to work with. The clip on the right is the exact session everything below is taken from.

With InterlinkedLess than a second
one MCP call · iFileNames
Without Interlinked6 min 57 sec
71 tool calls · sped up 6× · the run dissected below

The run, call by call

Two long blocks, not eighteen rounds.

Every call in chronological order, coloured by tool. Solid cells are calls whose exact command is legible in the recording; faded cells sit inside a collapsed stretch. Hover any cell to read what it ran. What you are looking at is not an agent exploring: it is an agent enumerating, then enumerating again in a different language.

Search / Glob: ≈47Bash: ≈22Read: 2command not legible
Glob sweepcalls 1 to 45
name × extension × folder, then release metadata, then brute force
Shell fallbackcalls 46 to 71
the same sweep again in PowerShell, cmd and WSL bash

The ringed white cell is call 61. Everything before it failed; it is the only call that returned the answer, and it wasn't a search.

Call 61

It never found the file. It tripped over it.

Read(~\AppData\Roaming\Microsoft\Windows\Recent\Iron.Man.2008.INTERNAL.REMASTERED.2160p.UHD.BluRay.X265-IAMABLE.lnk)

The movie was in C:\Movies\. The agent never probed C:\Movies\, not once in sixty calls. It swept ~\Documents, ~\Videos, ~\Downloads, E:\ and every corner of C:\Users\VladM. The file was in none of them.

What broke the deadlock was a Windows Recent-items shortcut: a breadcrumb left behind months earlier by a human double-clicking the file. The agent read the target path out of the .lnk and only then walked to the folder to confirm it.

This is the part the wall-clock number hides. Without an index the run didn't merely cost seven minutes: the search strategy failed outright, and was rescued by a stray artifact of human behaviour that happened to be lying on the disk. On a machine where nobody had opened that file, those 71 calls return nothing at all.

Composition

One tool did two thirds of the work.

47 SEARCH / GLOB
22 BASH
2

The white sliver at the right edge is both Read calls. One of the two is call 61.

Tool-level counts understate it. The repetition is at the query level. The glob block is one loop over extensions and folders, re-issued with a single token changed each time:

Search(pattern: "**/*iron*.wmv",  path: "~\Videos")
Search(pattern: "**/*iron*.flv",  path: "~\Videos")
Search(pattern: "**/*iron*.webm", path: "~\Videos")
Search(pattern: "**/*iron*.mp4",  path: "~\\Downloads")
Search(pattern: "**/*iron*.webm", path: "~\\Downloads")
Search(pattern: "**/*iron*.avi",  path: "~\\Documents")
                       … then the same loop again with [Ii]ron casing,
                           then again as release metadata,
                           then again in PowerShell, cmd and WSL bash.
Same sweep, re-run in3 languages

PowerShell Get-ChildItem, then cmd dir /s /b and where /r, then WSL find -iname and ls | grep.

Longest single stall~60 s

One unfiltered recursive walk of the entire user profile held the run for about a minute of real time.

Distinct glob patterns29 seen

Every one a variation on the same guess: the name contains “iron” and the file is a video. Both were true. Neither helped.

What it actually ran

The command inventory.

ToolStrategyRepresentative callSeen
GLOBname × extensionSearch(pattern: "**/*iron*.mkv", path: "~\Videos")~14
GLOBcase-permutedSearch(pattern: "**/*[Ii]ron*[Mm]an*.mp4", path: "C:\Users\VladM")~9
GLOBrelease metadataSearch(pattern: "**/*2160p*iron*", path: "C:\Users\VladM")~6
GLOBbrute forceSearch(pattern: "**/*.*", path: "~\Videos")~3
BASHPowerShell walkGet-ChildItem -Path 'C:\Users\VladM' -Recurse -ErrorAction SilentlyContinue~9
BASHcmd nativedir /s /b "*iron*" 2>nul | findstr /E "\.mp4$ \.mkv$"~5
BASHWSL / POSIXfind "C:\Users\VladM" -iname "*iron*man*" -type f | grep -E …~6
BASHconfirm on diskls -lah "C:\Movies\Iron.Man.2008.…IAMABLE"~4
READown task outputRead(~\AppData\Local\Temp\claude\…\b41cd63.output)1
READthe breadcrumbRead(…\Windows\Recent\Iron.Man.2008.…IAMABLE.lnk)1

The fix

One tool. Called once.

Interlinked keeps a live index of every file on the machine (names and contents) and hands it to any agent over MCP. The agent stops guessing extensions and folders because it no longer has to: iFileNames takes the name and returns the exact path. No sweep, no fallback languages, no breadcrumb needed. One signed install auto-configures 19 AI clients, Claude Code among them.

Same agent · same model · same file

Without index

Calls
71
Distinct tools
3
Time
6m 57s
Found by
accident

With Interlinked

Calls
1
Distinct tools
1
Time
16 ms
Found by
lookup

Seventy-one blind probes and a lucky shortcut, replaced by a single index lookup.

THE MODEL WASN'T GUESSING BECAUSE IT WAS DUMB. IT WAS GUESSING BECAUSE GUESSING WAS ALL IT HAD.

Common questions

The questions people ask after the breakdown.

How many different tools did the agent use across 71 calls?

Three: Glob (rendered as Search), Bash and Read, split roughly 47 · 22 · 2. The count is high not because the agent had many options but because it had almost none: each call rules out one folder or one extension, so covering a machine takes dozens.

Were the calls mostly repeats?

Yes, and at the query level more than the tool level. The glob block is a nested loop over {extension} × {folder} with one token swapped per call, and when it came up empty the agent re-ran the same sweep three more times in PowerShell, cmd and WSL bash. 29 distinct glob patterns, all variations on one guess.

Did it actually find the file by searching?

No. The file was in C:\Movies\, which was never probed. Call 61 read a Windows Recent-items .lnk shortcut (a breadcrumb from a human double-click) and took the path from it. On a machine where nobody had ever opened that file, the run returns nothing.

Why didn't it just look in C:\Movies?

Nothing pointed there. Glob answers one yes-or-no about one place you have already named, so the agent can only probe roots it manages to think of, and it thought of ~\Documents, ~\Videos, ~\Downloads, E:\ and every corner of the user profile. A folder sitting at the top of C:\ under a name nobody had mentioned never entered the loop. That is the actual failure: not slow searching, but a search that cannot be aimed. Whether a stronger model would guess better is a separate question, taken apart in how the count reaches 71.

Would it have gone better on a machine with fewer files?

Faster, not better. File count sets the price of each walk (the ~60-second stall was one unfiltered recursive pass over the user profile), but it does not change the aim. The same 71 calls on a smaller disk sweep the same wrong folders, just more quickly, and still end at a Recent-items shortcut. Volume is why the run took seven minutes; the strategy is why it never found the file.

Method & honest limits

What's exact, and what's reconstructed.

Exact

The 71 tool uses, 37.9k tokens, 6m 41s subagent / 6m 57s turn, and the count of three distinct tools. All four are read directly off the terminal, from the agent's own closing line: Done (71 tool uses · 37.9k tokens · 6m 41s).

Reconstructed

The 47 / 22 / 2 split, ±3 per bucket. The recording only ever shows the one or two most recent calls; the rest sit behind “ctrl+o to expand”, which was never pressed. The split is derived from where the collapsed counter advances, halved, and cross-checked against the ~46 calls whose commands are individually legible.

A trap worth naming

Claude Code's live “+N more tool uses” counter reaches +140 before the run ends, because it counts call and result rows, almost exactly 2× the true count. Only the closing Done line is quotable.

Recovery

4 fps frame extraction from the 73-second timelapse, cropped to the tool-call rows and de-duplicated to 79 unique states. The 4K master is corrupt (71 MB on disk, 7.4 s decodable), and the session transcript no longer exists. The timelapse is now the only surviving record of this benchmark.

Rig

Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Claude Code v2.1.39, Opus 4.6, Claude Max.

Companion write-ups: how the count reaches 71, where the tokens go. Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.

Run measured June 2026 · recovered frame-by-frame August 2026 · 4.47M files← All research