Agents · where the time goes · measured July 2026
Most of your agent's day isn't thinking. It's finding and reading.
Every agent session is three jobs: find the file, read what's in it, then reason about it. Only the last one needs the frontier model you're paying for. On a real Claude Code session measured on a 4.47-million-file machine, the first two ate about 58% of the tokens. This is where the time actually goes, and how to hand the thinking back its budget.
TL;DR: the takeaways
An agent session is three jobs. Finding files, reading them, and reasoning. Only reasoning needs the model you pay for. The other two are context acquisition.
Finding + reading dwarf reasoning. On a measured Claude Code run, ~58% of the session's tokens went to acquiring context; reasoning and output split what was left.
Reading is the sneaky-expensive half. A one-line search returns thousands of lines the model must read to find the one that matters, and it re-reads them every turn.
One indexed lookup replaces the hunt. 6 minutes 57 seconds and 71 tool calls collapse to 16 milliseconds and 1 call, about 7,200,000× faster, on the machine below.
The balance tips back to thinking. Finding drops to ~0% and reading shrinks to the right file, so the token budget goes back to the work you actually wanted.
The anatomy of a session
Three jobs. Only one is the thinking.
Context acquisition is everything an agent does before it can think: locating the right file, then reading its contents into the model's context window. It is necessary work. It is also, on today's tools, most of the work. An agent that wants to change one function first has to answer two questions the hard way: which file? and what's in it? Both are answered by shelling out to the disk: directory walks, grep, reading candidate after candidate to rule them out.
Here is one real Claude Code session, drawn to scale. The blue is context acquisition: the finding and the reading. The dark block is the reasoning and the answer: the part you actually rented a frontier model to do. Then the same session, once a single indexed lookup answers both questions at once.
One agent session · 100% of the tokens your plan pays for
Measured: Claude Code on the benchmark machine, one real file-hunt task; ~58% of the session's tokens went to finding-and-reading before the answer was written. The internal finding-versus-reading split shown in the top bar is illustrative; only the combined ~58% is measured. In the lower bar, the finding collapses to ~0% (one lookup, no hunt) while the reading shrinks to the single relevant file.
Why finding isn't even the expensive part
Reading is the sneaky-expensive half. And it's billed on repeat.
A search is one line out. Its results are thousands of lines back: a directory listing, a grep dump with four thousand candidate paths, whole files opened just to confirm they're the wrong ones. The model has to read all of it to figure out which single file matters. That reading is the bulk of context acquisition. Not the finding, the wading.
And an agent works in a loop: every result is appended to the conversation and re-sent on the next turn, and the next. So the wading isn't paid once. It compounds. We drew that compounding in where your tokens go; by the last calls, the agent spends more of its budget re-reading its own search history than reading the file it was looking for. The context window fills with the hunt, not the work.
That is roughly a 7,200,000× speed-up on the measured task, the difference between a six-minute coffee break and a single blink. Watch the same content query run on the tool your agent actually shells out to and it takes 93.8 seconds on ripgrep, versus 16 milliseconds here.
THE MODEL WAS NEVER THE BOTTLENECK. THE READING WAS.
What changes with an index
Give both questions one answer. The budget goes back to thinking.
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 agent asks once and gets the file, or the exact matching lines. The finding is over in microseconds; the reading is trimmed to what's relevant instead of walls of candidates. Same session, same answer. The tokens that were finding and reading are now thinking.
| Per session | Walking the disk | With the index |
|---|---|---|
| Finding a file | 6m 57s · 71 calls | 16 ms · 1 call |
| Reading to locate it | walls of candidates | just the right file |
| Tokens on find + read | ~58% | ~0% |
| Single-file lookup | walks the drive | 85 μs |
| Edit → searchable | re-index / re-walk | ~1 ms |
| Budget left for thinking | the minority | the majority |
A single-file lookup returns in 85 microseconds. 139 microseconds is the median across 20 queries on the 4.47-million-file drive, best case 2. A save is searchable in about a millisecond, under 30 milliseconds worst case, so the answer is never stale. The whole engine sits around 44 MB at rest (lighter than a single browser tab) and its index takes under 1% of the drive. The same picture, drawn as a stack, is in the backbone of the LLM economy.
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. The agent run is the measured Claude Code session; lookup and content times are the indexed engine on the same corpus.
Questions people ask
Reading vs thinking, answered.
What do AI agents actually spend their time on?
Three things: finding files, reading them, and reasoning. On a measured Claude Code session, finding and reading (context acquisition) took about 58% of the tokens; reasoning and output split what was left. Only reasoning needs the frontier model you're paying for.
Why is reading so expensive for an agent?
A search returns far more than the answer: directory listings, grep dumps with thousands of candidate paths, and whole files opened just to rule them out. The model must read all of it to find the one that matters. Agents also re-read the whole conversation each turn, so that reading is billed again and again.
Does a faster or smarter model fix this?
No. The bottleneck is context acquisition, not thinking speed. A frontier model still has to find and read the file first. A live index removes that step (returning one file in about 85 microseconds instead of 71 tool calls), which is what actually moves the budget back to reasoning.
How much faster is an indexed lookup, exactly?
On the benchmark machine, one real file-hunt task went from 6 minutes 57 seconds and 71 tool calls to 16 milliseconds and 1 call, roughly 7,200,000×. A content query that took ripgrep 93.8 seconds returned in 16 milliseconds on the same corpus.
Does this replace RAG or my model's memory?
No. It runs in parallel, underneath both. It's an exact, offline index of your machine's files, names and contents, not an approximate vector store or a per-vendor memory. Nothing leaves the machine, and there are no models or keys in the lookup itself.
Do this today
Let your agent think again.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Codex, Copilot, 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 its index takes under 1% of the drive.
Ask once, read less. Whole-machine when you don't know where something lives; scoped to a folder when you do. Either way the answer is one tool call, not a hunt the model has to read back.
Watch the balance shift. The tokens that were finding and reading are now reasoning. Same plan, same model: more of it spent on your actual problem.
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.