Explainers · measured July 2026
You hit save. The search already knew.
Most indexes are always a little behind: a rebuild here, a scheduled crawl there, minutes between your last edit and what search can see. A file watcher closes that gap to about a millisecond. Here is what a file watcher is, why it beats scanning on a timer, and how it keeps a whole-machine index fresh enough that an AI agent never searches a version of your machine that no longer exists.
TL;DR: the short version
- •A file watcher is the operating system telling software the instant a file is created, changed, renamed, or deleted, so software never scans the disk just to notice.
- •It is push, not poll. No timed full-disk scan; the OS pushes one change event and the index patches only what moved: fresh, and nearly free at rest.
- •On Interlinked a save is searchable in about 1 millisecond (under 30 ms worst case), measured across 4.47M files. Less than one screen refresh.
- •VS Code re-reads files and rebuilds; Windows Search crawls on a schedule. Both can sit minutes behind your last save.
- •Freshness is what keeps an AI agent honest: a stale index sends it hunting for a file that already moved.
Start here
A file watcher is the OS doing the noticing for you.
A file watcher is the operating system's way of telling a program the exact moment a file changes (created, edited, renamed, or deleted), so the program never has to scan the disk to find out. Instead of asking “did anything change?” over and over, the software registers interest once and waits. The OS does the noticing and delivers a small note the instant something happens.
Every modern operating system ships one: Linux calls it inotify, macOS calls it FSEvents, Windows has its own built-in service. Editors, sync clients, and search indexes all lean on it. It is the difference between a night watchman who walks the whole building every hour and a building wired with door sensors that page him the instant one opens.
Push, not poll
The old way scans on a timer. The fresh way waits to be told.
The difference is push versus pull. A polling index pulls: every few minutes it walks the disk, compares what it finds to what it remembered, and updates the difference, paying the full cost whether ten files changed or none. A file watcher pushes: it sits idle until the OS hands it a note (this file just changed) and only then touches the index, patching the one thing that moved.
That is what makes an index both fresh and cheap at once. There is no schedule to fall behind and no periodic scan to burn power. A save completes, the OS event fires, the changed file is re-indexed in place, and the next search sees it about a millisecond later. It is incremental indexing at its most immediate: never rebuild the whole thing, only ever touch what actually moved.
Same machine · same drive
How four tools keep up with your edits.
| Tool | How it stays current | Edit shows up in |
|---|---|---|
| Interlinked | Rides the OS change event (a file watcher) | ~1 ms |
| VS Code search | Re-reads files per query; rebuilds on reopen | seconds |
| Windows Search | Scheduled background crawl, indexes when idle | minutes+ |
| grep / ripgrep | No index: reads every file on each run | instant, re-scans every query |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Freshness is the time from a completed save to the edit appearing in results. VS Code and Windows Search behave as their documented, observable design intends. Why VS Code stays behind and why Windows Search lags go deeper.
Fresh is only half of it. When the query actually runs, the same index answers a filename lookup in about 85 microseconds, against 35 seconds in VS Code (412,000×: a spinner you would walk away from versus a blink you would miss) and a 67-second median in Windows Search (~480,000×: long enough to refill your coffee), on that same 4.47M-file machine. A file watcher keeps that answer current; the index keeps it fast.
Why an agent cares
A stale index sends an agent chasing a file that already moved.
An AI agent trusts its search the way you trust muscle memory. Ask it to fix a function and it searches for the name, opens whatever the index points at, and edits. If the index is three minutes behind, it opens a file that already moved, edits a copy that no longer matters, or never finds the thing you just created for it, and then it does the slow, expensive thing: it falls back to walking the directory tree by hand.
We measured where that time goes in the backbone of the LLM economy. Without a fresh, machine-wide index, one file cost an agent 6 minutes and 57 seconds and 71 separate tool calls. With one, the same lookup was 16 milliseconds and a single call: the difference between an agent grinding through your entire coffee break and one that never breaks stride. A file watcher is what keeps the second number the true one, edit after edit, all day.
Fresh, and cheap, and whole-machine
A millisecond behind your last save. Across every file you own.
Because it waits to be told instead of scanning, staying current costs almost nothing. The engine sits around 44 megabytes at rest (less than a single browser tab), and the on-disk index is under 1% of the drive. The same freshness carries the knowledge vault too: a note you or an agent leaves on a file is live for the next query the moment it is written, and it is keyed to the file's OS identity, so a rename does not lose it.
Questions people ask
File watchers, answered.
What is a file watcher?
A file watcher is a service the operating system provides that notifies a program the instant a file is created, changed, renamed, or deleted, so the program never has to scan the disk to find out. The software registers interest once and the OS delivers a small note whenever something happens.
How is a file watcher different from a scheduled scan?
A scheduled scan (polling) periodically walks the disk and compares what it finds to what it remembered, paying the full cost every sweep whether anything changed or not. A file watcher is push-based: the OS tells it the moment something changes, so updates are near-instant and cost almost nothing while the machine is quiet.
How fresh is Interlinked's index?
Typically about 1 millisecond from a completed save to the edit appearing in search results, and under 30 milliseconds in the worst case measured on a 4.47M-file machine. That is less time than your monitor takes to redraw the screen once.
Does watching every file slow down my computer?
No. Because it waits for the OS to push events instead of scanning on a timer, the engine sits around 44 megabytes of memory at rest (less than a single browser tab), and the on-disk index is under 1% of the drive.
Why does freshness matter for AI agents?
A stale index sends an agent to a file that already moved or changed, wasting tool calls and tokens before it falls back to walking the disk by hand. A file watcher keeps the index a millisecond behind your last edit, so the agent always searches the machine as it is right now.
Try it
Give your agent an index that is never behind.
One signed installer sets up whole-machine search (names and contents) for 19 AI clients at once, and keeps it fresh in the background as you work. Filename search is live immediately; content fills in behind it. Nothing leaves the machine, and there is no model in the box to wait on.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows.