Agents · measured July 2026
Software ate the world. Now agents are eating your tokens.
In 2011, Marc Andreessen wrote in the Wall Street Journal that software was eating the world, that every company, in every industry, would become a software company. He was right for fifteen years. The sequel writes itself: if software ate the world, agents are eating software: writing it, running it, operating it. And what an agent eats, it eats in tokens. So we measured where the tokens actually go on a real 4.47-million-file machine. In the session we clocked, the biggest line item was not thinking. It was finding files: about 58% of the tokens, spent hunting for context the model forgot one turn later.
TL;DR · the short version
Key takeaways. The whole argument in five lines.
- Software ate the world; now agents eat software, and every step an agent takes is metered in tokens. In one measured Claude Code session, the biggest line item wasn't thinking, it was finding files: about 58% of the tokens.
- Interlinked is a prebuilt, always-fresh index of every file on the machine: a filename lookup across 4.47M files in 85 μs, content in ~7 to 9 ms, where ripgrep took 93.8 s on the same corpus (58,625×).
- With the index, that session's 6m 57s / 71-call file hunt became a single 16 ms lookup. Search fell from ~58% of the token budget to ~0%.
- The index stays about 1 ms behind your last save and sits around 44 MB at rest, so freshness is free. You can't out-model a slow retrieval floor, so we make the floor bedrock.
- Everything local is free forever, no card. Hosting starts at $5.99/mo.
The chain, nested and drawn
Each layer eats the one below it. The last one eats file-hunting.
Andreessen's thesis is the outer frame. Inside it, agents are the new consumer of software. Inside that, agents run on tokens, a metered budget for every plan, every step. And inside that, on the session we measured, most of the budget never reached the problem. It went to locating files.
The nesting is the point: you can buy a smarter model for the inner ring, but the ring it sits in (the token meter) is set by the layer underneath, and that layer is retrieval. This is the argument we make in full in the backbone of the LLM economy.
One real session · index on, then off
We watched Claude Code look for one file.
Same task, same machine, twice. Without a machine-wide index the agent did directory archaeology (list a folder, read the bytes, guess, repeat) for nearly seven minutes and 71 tool calls to locate a single file. With the index it was one call and 16 milliseconds. On a plan metered in tokens (Anthropic's Claude Max tops out at $200 a month), that 58% bought directory listings the model read once and forgot. A faster model would not have saved it; it would have forgotten them faster. We break the token math down file by file in where your tokens go.
Same machine · same drive · same queries
The retrieval floor, priced in seconds.
| The searcher | What was measured | Time | vs Interlinked |
|---|---|---|---|
| Interlinked | one indexed lookup, 4.47M files | 85 μs | baseline |
| VS Code Ctrl+P | find a file by name, same drive | 35 s | 412,000× |
| Windows Search | 20 filename queries, median | 67 s | ~480,000× |
| ripgrep (what your agent runs) | content search, same corpus | 93.8 s | 58,625× |
| Claude Code (no index) | the full file hunt, 71 tool calls | 6 m 57 s | ~7,200,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename lookups are median-of-20 (139 μs); the 85 μs figure is a single-file lookup, best case 2 μs. The ripgrep row is a content query over the same corpus: 58,625× is the average across the query set, and one query from it ran 93.8 s → 16 ms. The Claude Code row is the measured agent hunt (6 m 57 s, 71 tool calls) against a single indexed lookup; with the index the same task was one call, 16 ms. Full per-tool write-ups: the 412,000× VS Code comparison and the ripgrep content benchmark.
The economics nobody prices in
You can't out-model a slow floor.
A bigger model reasons better per token. It does not find files faster. It shells out to the same primitives underneath: list the directory, read the bytes, guess again. Double the model and you double the quality of the thinking; the retrieval floor beneath it is unchanged, and the floor sets the ceiling. The meter runs the entire time the agent is looking, and most of what an agent does is look.
So the economics of the agent era don't hinge on the frontier of the model. They hinge on the floor of retrieval, the least glamorous number in the stack, and the one that decides how much of a $200 plan you actually spend on your problem. An always-fresh index that answers machine-wide in microseconds turns that floor into bedrock. Put plainly: agents don't need bigger brains as much as they need to stop looking for their keys.
The other half of the bedrock
Speed finds the file. Memory knows what it's for.
The same index that answers in microseconds also carries a knowledge vault it builds by itself: relationships derived from your own history, plus notes any agent can leave on any file that every other agent then reads. It is keyed to the file's OS identity, so it survives renames, spans every repo, and belongs to no vendor. The meter that was running on search gets to run on the work instead, and the machine keeps getting easier to work on. It stays a millisecond behind your last save, sits around 44 MB at rest, and takes under 1% of the drive.
EVERY EDGE IS A RECEIPT (A COUNT OR A HASH YOU CAN CHECK), NEVER A MODEL'S GUESS.
Common questions
The questions we get, answered straight.
Is there an AI model or embeddings inside it?
No. It's a plain index plus a hashmap and a path/id match: no model, no embeddings, no keys, and nothing leaves the machine. That is the point: the retrieval floor an agent sits on shouldn't itself need a model.
How is this different from the search my IDE or ripgrep already has?
Those understand one project in isolation and walk the filesystem on every query. Interlinked is a prebuilt index of the whole machine, across every repo, including the git-ignored files a cwd search misses, and on the same corpus a content query that took ripgrep 93.8 s answered in 16 ms.
How fast is it, and on what machine?
On a Ryzen 9 9950X3D with 4.47M files indexed, a filename lookup returns in about 85 μs and content search in about 7 to 9 ms. In one measured Claude Code session that turned a 6m 57s, 71-tool-call file hunt into a single 16 ms lookup.
Does keeping the index fresh slow my machine down?
No. It stays about 1 millisecond behind your last save and sits around 44 MB at rest, so freshness is effectively free. You can't out-model a slow retrieval floor: the whole idea is to make that floor bedrock.
What does it cost?
Everything (including agent access, the MCP layer for Claude Code, Cursor, Codex and the rest) is free forever, no card. Hosting starts at $5.99/mo.
Do this today
Give your agent the bedrock.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing.
Let it index. Filename search works immediately; content fills in behind it. Freshness stays about a millisecond behind your saves, under 30 ms at worst.
Point it at everything. Whole-machine when you don't know where something lives; scoped to a folder when you do. Scoped queries return in microseconds.
Watch the meter drop. The tokens that were spent finding files stop being spent finding files. That budget goes back to the problem you were actually solving.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.