Interlinked.

Foundations · measured July 2026

The backbone of the LLM economy

Your AI has a job. Most of it is looking for things.

On a 4.47-million-file machine we measured where an agent's time and tokens actually go. The answer is the least glamorous layer of the stack (finding files), and it still runs on tools built for humans in 2006.

searched across
every file
on the machine
by nameby contentinside PDFs & docseven .env & configsevery repoand non-git folders
What a single call returns

TL;DR · the whole thing in five lines

  • Every agent session starts with finding, not thinking: which file, which function, what was decided last time. That context-acquisition layer is the slowest floor in the stack, and it still runs on tools built for humans in 2006.
  • On a real machine of 4.47M files, one indexed lookup returns in 85 μs, about 412,000× faster than VS Code and ~480,000× faster than Windows Search's 67 s.
  • For content, the always-fresh index answers in ~7 to 9 ms where the agent's own ripgrep takes 93.8 s: the same query, 58,625× faster.
  • Watched end to end, the index cut one file hunt from 6m 57s across 71 tool calls to 16 ms in 1, and file-search token burn from ~58% of the session to ~0%.
  • It sits at ~44 MB idle, stays current within ~1 ms of a save, and pairs the speed with a knowledge vault that runs with no LLM in the loop, every relationship a receipt you can check.

The stack, honestly drawn

Every layer got faster. Except the one they all stand on.

Models double in capability yearly. Harnesses ship weekly. But when the agent needs a file, it shells out to the same primitives a 2006 laptop used: walk directories, grep bytes, hope. The lowest layer sets the ceiling for everything above it.

YOUthe intent, one sentenceTHE AGENTClaude Code · Cursor · Copilot: plans, calls toolsTHE MODELreasoning, the part you pay forfast, expensiveCONTEXT ACQUISITIONfinding files · reading code · remembering what's knownSLOW: the bottleneck← Interlinked lives hereYOUR MACHINE4.47M files · every repo · every document

One real task, on video

We watched Claude Code find one file.

Same question, same machine, same model. On the left the agent asks the index once; on the right it has nothing but glob and bash to work with.

With InterlinkedLess than a second
one MCP call · iFileNames
Without Interlinked6 min 57 sec
71 tool calls · sped up 6×
6m 57s
16 ms
time to the file: without, then with the index
71 tool calls
1
calls spent hunting for it
~58% of tokens
~0%
of the session burned on file search

Tokens spent grepping are tokens not spent thinking. On a $200/month agent plan, half your bill can go to directory listings: the model reads walls of ls output it will forget one turn later. The fix is not a smarter model. It is a faster floor. We went back and pulled all seventy-one of those calls apart: three tools, and a file it never actually found by searching.

Same machine · same drive · same queries

The same lookup, everywhere it happens today.

The searcherThe taskTimevs Interlinked
Interlinkedone indexed lookup85 μsbaseline
ripgrep (what your agent runs)content query, same machine93.8 s1,100,000×
VS Code Ctrl+Psame file, same drive35 s412,000×
Windows Searchmedian of 20 queries67 s~480,000×
Claude Code (no index)directory-listing archaeology3 m 13 s2,276,000×

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Single-file lookups are median-of-5; the ripgrep row is a content query over the same corpus; the Claude Code row is the measured agent run. Full per-tool methodology in the 412,000× write-up and the ripgrep comparison.

Why nobody fixed it

Search was built for a human with one project open.

VS Code indexes the folder you opened. Cursor indexes the repo you're in. Your machine has a dozen repos that ship together, plus the 90% of the disk that was never in git: configs, documents, downloads, the PDF with the answer. An agent's questions don't respect folder boundaries; its tools do.

So agents fall back to the floor: ripgrep, walking the disk on every single query, because nothing warmer exists machine-wide. An always-fresh index (riding the filesystem's own change journal, a save searchable in about a millisecond) turns that floor into bedrock. That is the entire product idea: make the layer every agent stands on answer at memory speed.

The other half of the bedrock

Speed finds the file. Memory knows why it matters.

The same index that answers in microseconds also carries a knowledge vault: relationships the engine derives by itself (files that change together, repos that share hundreds of identical files, which project is alive and which went dormant), plus notes any agent can leave on any file, that every other agent reads. Keyed to the file's OS identity, so it survives renames, spans every repo, and belongs to no vendor. Not a replacement for RAG or your model's memory: the layer under both.

1.7 s
after install, a fresh machine's 12 repos were webbed: 26,958 relationship pairs from its own git history
co-changed 6×
the edge that told an agent which file its fix needed next, before it asked
0 LLMs
every edge is receipts (counts and hashes you can check), never a model's guess

THE VAULT SERIES (how machine-wide memory works) BEGINS HERE THIS MONTH.

Common questions

Straight answers, before you install.

Doesn't my IDE already index my code?

It indexes the one folder you opened. Your machine has a dozen repos that ship together, plus the bulk of the disk that was never in git: configs, downloads, the PDF with the answer. Interlinked indexes all of it, machine-wide, and returns a single-file lookup in 85 μs, about 412,000× faster than VS Code's project search.

How is this different from the ripgrep my agent already runs?

ripgrep walks the disk on every query. On the same machine of 4.47M files, a content search that takes ripgrep 93.8 s returns from the always-fresh index in ~7 to 9 ms (58,625× faster) because the work is done once, up front, and kept current.

Does it use an LLM, or send my files anywhere?

No. There is no model and no cloud: it is an index, a hashmap, and a path/id match, fully offline. Every knowledge-vault relationship is receipts you can check (counts and hashes), never a model's guess.

Will a machine-wide index slow down my computer?

At rest the whole engine sits at ~44 MB, less than a browser tab. It rides the filesystem's own change journal, so a saved file is searchable in ~1 ms, without rescanning the disk.

What does it cost, and which agents work with it?

One signed installer auto-configures your AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and more. Everything local is free forever, no card. Hosting starts at $5.99/mo.

Do this today

Give your agent the bedrock.

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.

2

Let it index. Filename search works immediately; content search fills in behind it. At rest the whole engine sits around 44 MB, less than a browser tab.

3

Scope when you can. Whole-machine when you don't know where something lives; scoped to a folder when you do. Scoped queries return in microseconds.

4

Let the vault grow. Day one it knows your git history. Every week after, it knows your machine better, automatically.

Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows.

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