Explainers · Opinion · measured July 2026
Software moved to the cloud. Your agent's search should come home.
The best infrastructure an AI agent can have is the machine it already runs on. Three properties make that true: it's private (nothing leaves), instant (no round-trip), and offline (no connection required). Cloud code search traded all three away for team-scale sync. This is the case for taking them back, measured on a real 4.47-million-file machine.
TL;DR · Key takeaways
The long story, short.
- 01The best index an AI agent can have lives on the machine it already runs on: private (nothing leaves), instant (no round-trip), and offline (no connection required).
- 02Filenames resolve in 85 µs for one file (139 µs median across 4.47M files), 412,000× faster than VS Code and ~480,000× faster than Windows Search (67 s) on the same drive.
- 03Content search runs in 7 to 9 ms where ripgrep needs 93.8 s: one query that took ripgrep 93.8 s came back in 16 ms (58,625×).
- 04For the agent, finding one file dropped from 6m 57s across 71 tool calls to 16 ms in one (~7,200,000×), and file-search token burn from ~58% to ~0%.
- 05It idles at ~44 MB and re-indexes a saved file in ~1 ms. Everything local is free forever, no card. Hosting starts at $5.99/mo.
The shape of the choice
One query. Two very different journeys.
Every tool that lets an AI search your work makes one architectural choice: keep the index on the machine, or put it on a server. Both answer the agent's question. Only one keeps the answer (and your code) from ever crossing the boundary. Here is the same query, drawn both ways.
The round-trip is the tell. A cloud index can be superbly engineered and still can't win a race it has to leave the building to run. Local-first isn't a smaller version of cloud search: it's a shorter path.
How the famous tools chose
Cloud code search made the other trade.
Two of the best-known ways to search code and work with AI both put the index on a server, for good, deliberate reasons like team sharing and cross-device sync. Sourcegraph is built around a server that indexes your repositories; you can self-host it or use their cloud, but either way the index lives on a server your tools reach over the network, not on the developer's own laptop. Glean is enterprise search whose entire model is to ingest a company's content (documents, tickets, chats, code) into Glean's cloud and index it there. Both are excellent at what they do. Both require your content to leave the machine to be useful.
That's the right call for a team of hundreds searching one shared corpus. It's a heavy trade for a single developer who just wants their agent to find things on their own disk. Here is where the bytes actually go:
| The approach | What leaves your machine | Where the index lives | Offline |
|---|---|---|---|
| Interlinked Files | Nothing | On your disk | Yes |
| Sourcegraph | Your repositories | A server: self-host or cloud | No |
| Glean | Docs, tickets, chats, code | Glean’s cloud | No |
| ripgrep / grep (local) | Nothing | None: re-walks each query | Yes |
Based on each product's public documentation, July 2026. Sourcegraph can be self-hosted on infrastructure you operate: still a server, still a network hop, not the developer's machine. ripgrep and grep are local and private, but they keep no index and re-scan the drive on every query, which is why the same content search that Interlinked answers in 16 ms took ripgrep 93.8 s on this machine. Local, private, and fast is the combination that's hard to get, and the one worth arguing for.
The instant pillar · Ryzen 9 9950X3D · 4.47M files
A round-trip you never take.
Speed here isn't a bonus: it's a consequence of the architecture. An answer that resolves on the machine is 412,000× faster than VS Code searching the same drive, and 58,625× faster than ripgrep on a five-query content set (same files, same machine). No network hop, however fast, can beat a lookup that never had to travel. The clearest single proof: a content query that took ripgrep 93.8 s returned in 16 ms on the local index.
What that buys an agent
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Filename figures are medians: 139 µs across 20 queries, 85 µs single-file. Content queries run ~7 to 9 ms: rare symbols ~7 ms, common words ~9 ms, exact phrases ~16 ms. The agent figures are a measured Claude Code run finding one file, without then with the local index.
The scorecard
Three properties. One place they all survive.
Private, instant, and offline aren't features you toggle on. They're consequences of a single decision: where the index lives. Put it on the machine and you get all three for free; put it on a server and you lose all three at once. The trade is a package deal.
Freshness comes with the package, too. Because the index rides alongside the files, a save is searchable again in about a millisecond, under 30 ms in the worst case. There's no re-embedding step, no re-upload, no cloud to fall behind. The agent always sees the file as it is right now, not as it was the last time something synced.
Local-first, done right
Local by default. Better because of it.
Interlinked Files keeps the whole pattern on your machine. A background service maintains a prebuilt, always-fresh index of every file: names and contents, across every repo, including the git-ignored files a folder-scoped tool never sees. Your agents reach all of it through one local server. There's no account, no upload, and no cloud to breach, because there's nothing to send. And staying local doesn't just avoid the cloud's costs; it unlocks something the cloud can't see. On a fresh machine the engine wove its own history into a relationship map, with no model in the loop, purely from what was already on disk.
PRIVATE · INSTANT · OFFLINE: THE THREE PROPERTIES, KEPT.
FAQ · Common questions
Questions, answered.
QIs any of my code or content uploaded to the cloud?
No. The index lives on your disk, and every query and answer stays between the agent and that local index: zero bytes are uploaded. There is no account and no server-side copy, and the index disappears when you uninstall.
QHow can it be so much faster than the search I already have?
It answers from a prebuilt, always-fresh index instead of walking the drive on every query. A single filename resolves in about 85 µs, 412,000× faster than VS Code and ~480,000× faster than Windows Search (67 s) on the same machine, while content search runs in 7 to 9 ms where ripgrep takes 93.8 s.
QDoes it work offline?
Yes. Everything resolves on the machine, so it keeps answering with the network cable pulled. There is no round-trip and no cloud that can go dark or fall behind.
QWill the index be stale right after I edit a file?
No. Because the index rides alongside your files, a save is searchable again in about a millisecond. There is no re-embedding step and no re-upload to wait on.
QWhat does it cost, and what am I paying for?
Everything local is free forever, no card: that includes agent access and the local server all your AI clients share. The only paid product is hosting your projects, from $5.99/mo. The local index itself costs nothing: no keys, no per-query fees, no inference to pay for.
Get it
Bring your search back home.
Everything is free forever: a complete whole-machine file and content search, plus agent access, the local server every client shares, auto-configured across 19 AI clients (Claude Code, Cursor, Codex, Windsurf, Zed and the rest) in one install. No card, no trial, no device limits.
Hosting your projects is the only paid product, starting at $5.99/mo. The tool itself costs nothing: no keys, no per-query fees, no cloud.
Download for Windows →Nothing you index is ever uploaded. The index is yours, on your disk, and it disappears when you uninstall.