Features · Apr 2026 · 5 min
Eight seconds
from save to searchable.
Every file search tool has the same problem: you save a file, search for it, and it isn't there yet. Interlinked Files eliminates that gap. Eight editors. Three save patterns. One watcher. Every change searchable in eight seconds.
TL;DR
Save to searchable in eight seconds: the full round trip from “file finished saving” to “contents returned by a fresh query,” content extraction included.
Every editor, every save method: eight editors across three save patterns (direct write, atomic rename, create-then-delete) verified end-to-end, zero misses.
No polling, no rebuilds: it reads the NTFS USN journal and merges an in-memory overlay with the cold index at query time, so the live layer adds ~1 ms and never spikes the CPU.
The index it keeps fresh stays instant: a single file resolves in 85 µs (139 µs median across 4.47M files), content search in ~7 to 9 ms where ripgrep takes 93.8 s.
Built for agents: one can search code it wrote five seconds ago and get correct results: the difference between iterating on its own work and inventing callsites.
Save to searchable. Every editor. Every save method. Every time.
Why this is hard
Editors don't save files the same way.
Press Ctrl+S in Notepad and it opens the file, writes bytes, closes it. Simple. Press Ctrl+S in VS Code and it writes to a temp file, then atomically renames it over the original. The file the indexer was watching no longer exists. It's been replaced by a different file with the same name.
Office apps do something else entirely: write a new file, delete the old one, sometimes rename. Three separate filesystem events for one save.
A naive file watcher hooks “file modified” and calls it a day. It catches Notepad. Misses VS Code. Gets confused by Office. Within hours, the index is wrong about which files exist and what they contain.
We built a watcher that handles all three patterns end-to-end. The eight-second latency is the round trip from “file finished saving” to “contents are searchable from a fresh query”, including content extraction.
Direct write
Notepad, Notepad++, Claude Code
Atomic rename
VS Code, Vim, JetBrains, Sublime, Cursor
Create + delete
Word, Excel, PowerPoint
Verified end-to-end
Eight editors, zero misses.
Each tested by typing a unique string, saving in the editor, waiting eight seconds, and confirming the string was returned from a fresh content search.
| Editor | Save pattern | Detected | Latency |
|---|---|---|---|
| VS Code | Atomic write (rename) | Yes | ~8s |
| Vim / Neovim | Atomic write (rename) | Yes | ~8s |
| JetBrains (IntelliJ, WebStorm, Rider) | Atomic write (rename) | Yes | ~8s |
| Sublime Text | Atomic write (rename) | Yes | ~8s |
| Cursor (file edits) | Atomic write | Yes | ~8s |
| Claude Code (file edits) | Direct write | Yes | ~8s |
| Notepad / Notepad++ | Direct write | Yes | ~8s |
| Word / Excel / PowerPoint | Create-new + delete-old | Yes | ~8s |
The atomic rename pattern is the one most indexers miss. VS Code, Vim, JetBrains, Sublime, and Cursor all use it. That's the majority of professional editors. If your indexer doesn't handle renames, it's wrong about most of the files developers actually edit.
Why eight seconds matters
Agents search code they wrote five seconds ago.
A coding agent generates a function, writes it to disk, and immediately needs to find every other place in the codebase that should call it. If the search index has a five-minute lag, the agent either skips those callsites or invents fake ones.
With eight-second indexing, the agent writes a helper, saves it, then queries for every file that should import it, and gets correct results. That's the difference between an agent that iterates on its own work and one that can't.
Typical rebuild
Full re-index after changes
Interlinked
Live overlay, no rebuild needed
Under the hood
NTFS journal + overlay index. No polling. No rebuilds.
We don't watch individual files. We read the NTFS USN journal, the same log Windows uses internally to track every filesystem operation. Every create, modify, rename, and delete across every drive, delivered in order, with zero polling overhead.
When a change arrives, we don't rebuild the content index. We update an in-memory overlay that gets merged with the cold disk index at query time. The cold index stays on disk, untouched. The overlay holds only what changed since last full build.
Traditional vs live index
Traditional
File change detected
Schedule full rebuild
100% CPU, user waits
Interlinked overlay
USN journal event
Read file, update overlay
Zero CPU spike, instant queries
The cold index handles 4+ million files. The overlay handles the delta. Queries merge both in microseconds.
What we fixed
Three bugs that kill every other live indexer.
01: Read-before-mark
You must read the file before marking it as modified in the overlay. If you mark first and the read fails, the file disappears from both indexes: the cold one thinks it's been updated, the overlay has nothing. Gone.
02: Atomic rename detection
When VS Code saves, the USN journal reports a RENAME event, not a MODIFY event. If the new name is a code file, the watcher must trigger a content update. Most watchers ignore renames entirely: they think only modifications matter.
03: Delete-then-update ghost
If a file is deleted and then recreated (Office does this), the overlay must remove it from the deleted set when adding it to the modified set. Otherwise the file appears in both: the query skips it because “deleted” wins. The file exists on disk but the index says it doesn't.
Stale search ruins agent loops.
We refused to ship anything that had a stale-search problem.The real workflow
What agents do with live search.
This is the actual loop that breaks without live indexing.
| Step | Action | Requires live index? |
|---|---|---|
| 1 | Agent generates a new utility function | No |
| 2 | Agent writes it to disk | No |
| 3 | Agent searches for all files that should import it | Yes |
| 4 | Agent updates each callsite with the correct import | Yes |
| 5 | Agent searches again to verify no missed references | Yes |
Common questions
Questions, answered.
How is “eight seconds” measured?
It's the full round trip from the moment a file finishes saving to the moment its contents come back from a fresh query, reading the file and extracting its text included. It is not a “change detected” timestamp; it's when you can actually search the new content.
Does it work with the editor I use?
Almost certainly. We tested eight editors (VS Code, Vim/Neovim, JetBrains, Sublime, Cursor, Claude Code, Notepad/Notepad++, and Word/Excel/PowerPoint) across all three save patterns, with zero misses. The atomic-rename pattern most indexers miss is the one professional editors use.
Won’t watching every file slow the machine down?
No. We read the NTFS USN journal instead of polling files, so there's no per-file watcher and no CPU spike on save. The service sits at about 44 MB idle, and each change lands in an in-memory overlay that a query merges in about one millisecond, no full rebuild.
How fast is the actual search once a file is indexed?
A single file resolves in about 85 µs (139 µs median across a 4.47M-file machine). Content search runs in ~7 to 9 ms: the same query that takes ripgrep 93.8 s cold returns in 16 ms.
What does it cost?
Everything local is free forever, no card. Hosting starts at $5.99/mo.