Agents · the hidden tax · measured July 2026
ls looks free. In an agent loop, it's the tax nobody budgets for.
To you, a directory listing is instant and costs nothing: you glance at it and move on. To an AI agent, every listing is tokens: read once, then re-read on every turn that follows, and re-listed from scratch whenever the agent forgets it already looked. We took one innocent ls and drew what it actually costs across a single session on a 4.47-million-file machine.
TL;DR
The tax, in five lines.
A directory listing looks free to you, but to an agent it's tokens: read once, re-read on every turn that follows, and re-run from scratch whenever the loop forgets it already looked.
One measured file-hunt ballooned to 71 tool calls over 6m 57s, burning ~58% of the session's tokens before the real answer began.
The cause is the disk hop underneath: on a 4.47M-file drive grep (ripgrep) takes 93.8 s and Windows Search 67 s. Nothing warmer exists machine-wide.
A warm index collapses the hunt to one call in 16 ms, ~7,200,000× faster end to end, with a file-by-name lookup at 85 μs (139 μs median).
Interlinked keeps that index always-fresh: searchable ~1 ms after a save, ~44 MB idle. Everything local is free forever, no card. Hosting starts at $5.99/mo.
One listing, drawn across a session
You run it once. You pay for it all session.
An agent works in a loop, and every tool result is appended to the conversation and re-sent on the next turn, and the next. So a listing is not billed once; it is billed on every turn it survives in the context. Worse, the agent has no standing memory that it already listed a folder, so it runs ls again on the same or an overlapping tree. Two multipliers, one innocent command. Here is what that looks like, listing by listing.
One agent loop · every directory listing still living in the context
The bright blocks are the moments an agent actually runs ls or a glob; the faded blocks are the same listings being re-read on later turns. The stack's shape is illustrative; the anchor is real: the measured run reached 71 tool calls to find one file, and each of those results kept getting re-read.
One real session, on the benchmark machine
It was never one ls. It was seventy-one calls.
None of those tokens touched the problem. They went to directory listings and grep dumps the model read once, weighed for a single line, and then re-read on every turn that followed. On a $200/month agent plan, that is a frontier model spending most of its budget running ls. The same task, answered from an index, is one call in 16 milliseconds, a ~7,200,000× difference end to end. The math per developer per day is in the token-cost write-up.
Same machine · same drive · same query
Why the loop is slow: the disk hop under it.
A tool call is only as fast as the tool it shells out to, and the ones an agent reaches for were built to walk the disk, not skip it. When Claude Code lists a folder it uses its LS and Glob tools; when it searches contents it shells out to grep (ripgrep, under the hood). On a real 4.47-million-file drive, both have to read the filesystem on every invocation, because nothing warmer exists machine-wide. Here is what that one hop costs, on a log scale.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Interlinked on the same tasks: 85 μs to open a file by name (139 μs median of 20 queries, best case 2 μs), and 16 ms on the content query grep took 93.8 s to run. Multipliers: 412,000× vs VS Code and ~480,000× vs Windows Search on filename lookups; 58,625× vs ripgrep is the average across the five-query content set. On the single query shown, 93.8 s collapses to 16 ms. Per-tool detail in the ripgrep comparison and the 412,000× write-up.
Why it keeps happening
The shell can't help, and the loop can't remember.
Every ls, grep and glob starts cold. It walks the tree and hands back everything it found, so the agent pays twice: it waits for the walk, then it pays in tokens for the dump; a match on a common word can be thousands of lines, and only one of them mattered. The tool has no way to return just the answer, because it never had an index to answer from.
And nothing records that a folder was already listed. A person would remember; the loop re-derives it every time, so overlapping directories get listed two, three, four different ways across a session, and each listing is re-read on every turn after it lands. That is the balloon in the diagram: not one bad tool, but a fast primitive with no memory under it. Fix the memory and the balloon never inflates.
Both multipliers at once
The listing goes free. And the machine remembers.
Interlinked keeps a live, always-fresh index of every file on the machine: names and contents, every repo, including the git-ignored files a project-scoped search never sees. The listing stops walking the disk and answers from memory, so the seconds collapse. And because the answer is the handful of files that match instead of a page of grep output, the result that flows back is small; the token tax collapses too. Same lookup, neither multiplier.
The re-listing stops too, because the machine keeps its own memory. On a fresh install Interlinked replayed 8,455 git events across all 12 repos in 1.7 seconds and seeded 26,958 relationship pairs (which files change together, which repos ship as a set) plus any notes an agent leaves on a file, read back on the searches it already runs. So a result can arrive already knowing what a re-listing would have gone looking for. Nothing to re-derive, nothing to re-read.
NO MODEL IN THE LOOP: AN INDEX AND A MATCH · EVERY ANSWER STAYS ON YOUR MACHINE.
Common questions
The tax, answered.
Isn't ls basically free? Why does it matter?
A single listing is cheap, but an agent re-sends every tool result on every following turn and re-runs the command whenever it forgets it already looked. One measured hunt reached 71 calls over 6m 57s and spent ~58% of the session's tokens before it answered.
Why not just use ripgrep, or a faster grep?
ripgrep is already what Claude Code shells out to, and on a 4.47M-file drive it still took 93.8 s, because it walks the filesystem on every call. Nothing warmer exists machine-wide until you keep an index; the same query answers in 16 ms from a warm one.
How fast is it, and does the answer stay fresh?
A file-by-name lookup is 85 μs (139 μs median across 20 queries) and a content query is 16 ms. The index refreshes about 1 ms after you save a file, so a listing is never stale, and the whole engine sits around 44 MB idle.
Is any AI model or cloud involved? Where does my data go?
Neither. Search is an index plus a path/id match, with no model, no embeddings and no keys, and your data stays put unless you publish a project yourself. That's also why the answer returns instantly instead of costing another inference call.
What does it cost?
Everything (including the MCP layer for Claude Code, Cursor, Copilot and the rest) is free forever, no card. Hosting starts at $5.99/mo.
Do this today
Stop paying rent on ls.
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.
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.
Stay fresh for free. Save a file and it is searchable in about a millisecond (under 30 ms worst case), so a listing is never stale and never re-walked.
Scope when you can. Whole-machine when you don't know where something lives; scoped to a folder when you do. Either way the answer is one call, 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.