Features · Apr 9 2026 · 6 min
Twenty editors.
Zero missed saves.
Every save pattern we could find, timed end to end. 7.5 to 8.9 seconds from Ctrl+S to searchable. The tightness of that distribution is the proof that the watcher isn't getting lucky.
TL;DR
The short version, up front.
Twenty editors, one budget. Every editor we tested (Notepad, VS Code, Vim, JetBrains, Word, Excel, even agents like Claude Code and Cursor) was searchable within 7.5 to 8.9 seconds of hitting save.
Three save patterns, all handled. Direct write, atomic rename, and create-new + delete-old each break naive watchers differently. Interlinked's USN-journal handler catches all three: reacquiring by path, reconciling by content-hash, debouncing overlapping events.
Bulk mutations stay in budget. A git checkout of ~2,000 files or an rsync of ~10,000 lands in the same window as a single Ctrl+S: no dropped events, no panic rebuild.
Agent edits look like a human's. There's no “agent mode.” When Claude Code or Cursor writes a file, the watcher indexes it exactly like a Ctrl+S, so an agent can save a helper and instantly query what should import it.
Detection is the wait; search is instant. Once merged, the file is fully searchable: content queries return in 7 to 9 ms, and a scan that takes ripgrep 93.8 s comes back in 16 ms.
Editors Tested
every one detected within budget
Latency spread
7.5s fastest · 8.9s slowest
Every editor, ranked by latency
The distribution is the proof.
Bars anchored at 7.0 seconds to magnify differences. The fastest editor and the slowest editor are separated by 1.4 seconds. Every one lands inside the eight-second budget.
The numbers
Twenty editors, three save patterns, one watcher.
Test protocol: type a unique string, save, wait, run a fresh content-search query for the unique string, record time from save to first hit. Sort by latency to see the ranking.
| Editor | Save pattern | Time to searchable | Status |
|---|---|---|---|
| Notepad | Direct write | 7.5 s | Detected |
| Claude Code | Direct write | 7.5 s | Detected |
| Notepad++ | Direct write | 7.6 s | Detected |
| Sublime Text | Atomic rename | 7.7 s | Detected |
| Zed | Atomic rename | 7.8 s | Detected |
| Vim | Atomic rename | 7.9 s | Detected |
| Neovim | Atomic rename | 8.0 s | Detected |
| Obsidian | Atomic rename | 8.1 s | Detected |
| VS Code | Atomic rename | 8.2 s | Detected |
| Typora | Atomic rename | 8.2 s | Detected |
| Cursor | Atomic rename | 8.2 s | Detected |
| WebStorm | Atomic rename | 8.3 s | Detected |
| Rider | Atomic rename | 8.3 s | Detected |
| IntelliJ IDEA | Atomic rename | 8.4 s | Detected |
| PyCharm | Atomic rename | 8.4 s | Detected |
| rsync / robocopy | Direct write (batch) | 8.5 s | Detected |
| PowerPoint | Create-new + delete-old | 8.6 s | Detected |
| git checkout | Bulk mutation | 8.6 s | Detected |
| Excel | Create-new + delete-old | 8.7 s | Detected |
| Microsoft Word | Create-new + delete-old | 8.9 s | Detected |
Why this test is hard
Three save patterns. Three chances to break.
Editors don't save files the same way. A watcher that handles one pattern correctly will miss the others entirely. Direct write is the easy case: one modify event, reindex, done. Atomic rename replaces the file's inode entirely: the file being watched no longer exists. Create-new + delete-old produces three separate events in an order that can vary with the filesystem.
Most file watchers handle one. A few handle two. The USN journal handler in Interlinked Files reacquires by path, reconciles by content-hash, and debounces overlapping events. All three patterns, every time.
Direct write
Notepad, Claude Code, cat-style tools
Atomic rename
VS Code, Vim, JetBrains, Sublime, Zed
Create-new + delete-old
Word, Excel, PowerPoint
One file or a thousand. Ctrl+S or git checkout. The latency is always eight seconds.
The watcher doesn't care what caused the write.Bulk mutations
Thousands of files in under a second.
A git checkout on a medium repo touches thousands of files in under a second. The watcher must not drop events, not panic-rebuild, and coalesce overlapping updates so the same file isn't reindexed three times.
| Operation | Scale | Latency | Result |
|---|---|---|---|
| git checkout / branch switch | ~2,000 files | 8.6 s | All changed files searchable |
| rsync / robocopy batch copy | ~10,000 files | 8.5 s | All copied files searchable |
| Single file Ctrl+S | 1 file | 7.5 to 8.4 s | Same budget |
Why this matters for agents
The agent's edits are indistinguishable from a human's.
Claude Code and Cursor both appear in the table. When the agent writes a file, the watcher picks it up the same way it picks up a Ctrl+S. There is no “agent mode” and no special plumbing.
An AI coding agent that generates a new file or edits an existing one is doing exactly what a human with Ctrl+S is doing, only faster and in larger batches. The agent can generate a helper function, save it, and immediately query “which files should import this new helper?” And the query will include the just-saved file.
Claude Code
Direct write · fastest category
Cursor
Atomic rename · VS Code fork
The bigger picture
Live indexing is an infrastructure promise.
Most file search tools rebuild their entire index on a schedule: every few minutes, every hour, on startup. If you save a file and immediately search for it, you get nothing. The index is stale.
Interlinked Files watches the NTFS USN journal in real time. Every filesystem event (create, modify, rename, delete) gets processed as it happens. The eight-second latency is the time it takes to read the changed file, tokenize it, and merge the new trigrams into the content index.
That's why twenty editors all land in the same narrow window. The watcher isn't polling. It isn't debouncing on a timer. It's processing events as the filesystem produces them. The editor doesn't matter. The filesystem is the source of truth.
Common questions
Questions, answered.
QWhich editors did you test, and did any fail?
Twenty, spanning every save pattern we could find: Notepad, Notepad++, Sublime Text, Zed, Vim, Neovim, Obsidian, VS Code, Typora, Cursor, WebStorm, Rider, IntelliJ IDEA, PyCharm, Word, Excel and PowerPoint, plus bulk operations like git checkout and rsync/robocopy. All twenty were detected and searchable within 7.5 to 8.9 seconds. None failed.
QWhy does save-to-searchable take about 8 seconds if the search itself is instant?
They're two different clocks. Nearly all of that window is the editor's own fsync plus a short debounce that absorbs the overlapping create, rename and delete events a single save can emit. The actual index update is about 1 ms of freshness, and querying the finished index takes 1 to 10 ms. You're waiting on the write to settle on disk, not on the indexer.
QDoes this work the same for AI coding agents like Claude Code and Cursor?
Yes. There's no separate “agent mode.” Both appear in the test, and when either writes a file the watcher indexes it exactly like a manual Ctrl+S, so an agent can save a helper and immediately search for what should import it. Handing the agent a prebuilt index also collapses search itself: one task that took an agent 6m57s across 71 tool calls becomes a single 16 ms query.
QHow fast is search once a file is indexed, and how much memory does it use?
A filename lookup resolves in about 85 µs and content queries return in 7 to 9 ms. A machine-wide search that takes ripgrep 93.8 seconds comes back in 16 ms (roughly 58,625× faster) across 4.47M files on a Ryzen 9 9950X3D. The background service idles at about 44 MB.
QIs it free, and how do I get it?
Everything local is free forever, no card. Hosting starts at $5.99/mo. No per-query fees, because there's no model to run.