Interlinked.

Explainer · file indexing

Read everything once. Or read it all, every time.

That is the whole difference between an index and a scan. File indexing reads every file on your machine one time and builds a compact map of what is where. After that, a search is a lookup in the map, not a walk across the disk. Scanning skips the map and re-reads the files on every single query. This page shows how far apart those two ideas end up, measured on a 4.47-million-file machine.

The mechanism, drawn

Scanning pays every time. An index pays once.

A scan starts from nothing and reads the files themselves, so the full cost lands again each time you ask. An index moves that work to the front: read the machine once, build the map, then answer from the map. Follow the two lanes below along the same clock.

SCANgrep · findstrreads every fileINDEXbuild once,then look upSWEEP #193.8 sSWEEP #293.8 sSWEEP #393.8 sall 4.47M files re-read, every single queryBUILD MAPone time3 lookups16 ms eachthen it just stays fresh, nothing to redo◄ index done hereTIME →

Read the dashed line. By the moment the scan finishes its very first pass, the index has already been built and answered all three questions, and it will answer the next thousand for the same near-nothing each. The scan is still on query one.

The two you already know

grep and Windows Search, the famous two.

grep is the honest scanner: it never builds an index, so it re-reads the live bytes on every query. Always current, always slow. Windows Search keeps an index, but a partial one: many folders sit outside the indexed locations, so it frequently falls back to scanning them. Same machine, same 4.47M files, the two behaviours cost:

The scannerEach query, it…Time · 4.47M filesSame job, indexed
grep / ripgrepre-reads every byte
93.8 s
content query
16 ms
Windows Searchmisses, then scans
67 s
median filename query
139 μs
VS Code searchscans via ripgrep
35 s
same file, same drive
85 μs

Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. grep times are a content query (bytes inside files); Windows Search and VS Code are filename lookups; the indexed column is the same job on a prebuilt, always-fresh index. Windows Search is the median of 20 queries.

58,625×
grep vs the index across the 5-query content set. On the proof query, 93.8 s of scanning collapses to 16 ms.
~480,000×
Windows Search vs the index for a filename: 67 s median drops to a 139 μs lookup.

Build once, answer forever

The index wins on query number one.

“Build a map first” sounds like an upfront tax. It is not. Plot total time against how many questions you ask and the two approaches split immediately: scanning adds a full sweep per query, so its line climbs; the index adds 16 ms per query, so its line lies flat on the floor. There is no number of queries where scanning catches up.

100 s200 s300 s400 s123456QUERIES RUN →TOTAL TIME →keeps climbing+93.8 s / queryindex: +16 ms / query, flatquery #193.8 s vs 16 msthe index already leads

The upfront read is the entire price of an index, and it buys every query after it. An agent that touches a codebase a hundred times an hour crosses that break-even before you finish reading this sentence.

The catch everyone hits

An index is only worth it if it stays fresh.

Here is the real reason grep survives in the age of indexes: it is never wrong. It reads the live file, so it can never hand you a stale answer. An index that lags behind your edits is worse than useless: it confidently returns yesterday's file. That is exactly why Windows Search feels unreliable: its map is often behind, and a search that misses quietly turns back into a slow scan.

The whole trick, then, is an index that updates the instant a file changes, so it is as current as grep and as fast as a lookup. On the test machine, a save becomes searchable in about a millisecond, and under 30 ms in the worst case. Fresh like a scan, fast like a map.

Where this goes

One index. The whole machine.

Interlinked Files keeps a live index of every file's name and contents across the entire machine. Every repo, plus the roughly 90% of the disk that was never in git: configs, documents, downloads, the PDF with the answer. Names come back in 85 μs, contents in 7 to 9 ms, and the map stays fresh as you work. It is the same thing this whole page describes (a scan you only pay for once), built for the machine instead of a single folder.

~44 MB
what the always-warm index costs in memory at rest, less than one browser tab
< 1%
of the drive on disk, about 24 GB of map on a 4 TB machine
19
AI clients (Claude Code, Cursor, Copilot, Codex and more) wired up in a single install

THE INDEX ALSO REMEMBERS HOW YOUR FILES RELATE: WHICH CHANGE TOGETHER, WHICH REPOS SHIP AS ONE. NO MODEL. NO GUESS.

Do this today

Stop scanning. Start looking up.

1

Install once. One signed installer builds the map and auto-configures 19 AI clients. No JSON editing, no keys.

2

Let it index. Filename search works immediately; content fills in behind it. At rest the whole engine sits near 44 MB.

3

Ask freely. Whole-machine when you don't know where something lives; scoped to a folder when you do. Either way it's a lookup, not a walk.

4

Trust it fresh. Every save is searchable in about a millisecond, so the answer is never yesterday's file.

Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.

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