Explainers · updated July 2026 · 6 min
You saved the file a second ago. Why can't search find it?
That gap (the seconds, minutes, sometimes hours between changing a file and being able to find it) is a freshness problem, and it has a well-known fix: incremental indexing. Instead of rebuilding the whole index from scratch on a schedule, an incremental index updates only what changed, the moment it changes. Here is what that means, why most search tools don't do it well, and what it takes to make a saved file searchable in about a millisecond.
The core idea
Two ways to keep an index current. Only one stays fresh.
An index is a pre-built answer sheet: it's what lets a search return in milliseconds instead of reading every file. The catch is that files keep changing, so the answer sheet has to be kept up to date. There are only two strategies for that. The first is the full rebuild: throw the index away every so often and re-scan everything. Simple, but between runs the index quietly drifts out of date, and the rebuild itself is heavy, so you can't afford to run it often. The second is incremental indexing: watch for changes and fold just those into the existing index as they happen. Nothing is ever rebuilt, so nothing is ever stale, and the machine never spikes.
The difference is easiest to see on a clock. Both timelines below have the exact same file activity. The only thing that changes is when the index catches up.
The shaded area is how out-of-date search is at each moment. A full rebuild lets it climb, then snaps it back to zero, so a query is only as fresh as the last rebuild, and unlucky timing lands you in the stale window. An incremental index keeps that area pinned to the floor, so the answer is the same whenever you ask.
Anchor 1 · the one on every machine
Windows Search runs on a schedule. That's the gap you feel.
Windows Search does keep an index and does update it when files change, so it is not a pure full rebuild. But it is a background, best-effort service: by design it backs off while you're actively using the machine, and after a big batch of changes (a large copy, a fresh checkout, an install), it falls behind and works through the backlog on its own timetable. That is the familiar "we couldn't find it, indexing is still in progress" state: the file is right there on disk, but the answer sheet hasn't caught up. Nothing is broken; freshness is simply the price of a scheduled model.
Three approaches, drawn honestly. From the scheduled model, to incremental within a single project, to incremental across the whole machine:
| Approach | How it stays current | Freshness | Seen in |
|---|---|---|---|
| Full rebuild | Re-scans on a schedule or when the machine goes idle | Trails your edits; longer after big changes | Windows Search |
| Incremental, one scope | Re-processes only the files you changed in the open project | Fast, but one repo, and a server round-trip | Cursor |
| Incremental, whole machine, local | Folds each change into the live index the moment it lands | ~1 ms · ≤30 ms worst case | Interlinked |
Freshness figures are quoted only where they were measured. The Interlinked row is timed on the machine cited in the footer; the other two describe the published behaviour of each tool. Why Windows Search stays slow.
Anchor 2 · incremental, done well (with a boundary)
Cursor already indexes incrementally. Inside one repo.
Credit where it's due: when you edit a file in Cursor, it doesn't re-process your whole project. A change-tracking step re-indexes only the files you touched, so its index keeps pace as you type. That is incremental indexing done right, and proof the idea isn't exotic. Two catches, both structural rather than sloppy: it's scoped to the one workspace you opened (the sibling repos and the non-git majority of your disk never enter it), and each re-index round-trips your changed chunks to Cursor's servers to be turned into vectors. The freshness is real, but it's bounded to a single project and gated by the network.
So the interesting question isn't whether to index incrementally: the good tools already do. It's how short you can make one file's trip from saved to searchable, and how far that reach extends.
One file's trip: saved → searchable
Not drawn to scale: the real gap between waiting for a scheduled rebuild and a live update is far larger than one line can show. The point is only the shape: a rebuild makes you wait for the clock; an incremental update is already done by the time you switch windows.
Incremental, whole-machine, local
Save a file. It's searchable before you switch windows.
Interlinked draws the bottom timeline for the whole machine. It keeps one always-fresh index of every file (names and contents) across every repo and the non-git 90% of the disk, and folds each change in the moment it lands. There is no scheduled rebuild to fall behind, no idle-time backlog, and no cloud round-trip: the update happens locally, on the same box, and never leaves it.
It's the same index that answers a filename lookup in a 139 µs median across those 4.47M files (85 µs for a single file) and a content search in the 7 to 9 ms range: a query that took ripgrep 93.8 s on this machine returns in 16 ms. Because it never rebuilds, staying current is nearly free: the whole service sits around 44 MB at rest, and the index on disk stays under 1% of the drive. Measured on a Ryzen 9 9950X3D, 64 GB DDR5, NVMe, Windows 11, 4.47M files. Freshness is the time from a file finishing its save to that change appearing in a fresh result.
NO SCHEDULE TO TUNE · NO REBUILD BUTTON · NO CLOUD ACCOUNT. THE INDEX IS SIMPLY NEVER OUT OF DATE.
Stop waiting for the index
An index that's never behind your work.
One signed installer keeps every file on your machine current as you work, and wires up the 19 AI clients you already use, from Claude Code and Cursor to Copilot, Codex, Windsurf, Zed and Cline. No schedule to tune, no rebuild button, no cloud account. Save a file, and your agent can find it on the very next search.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · How Cursor indexes your codebase