Explainers · updated July 2026
Autocomplete is a search. It just runs over a very short, very local list.
Type a dot and a menu of methods appears before your finger leaves the key. Your editor just ran a lookup and returned a ranked list. Two engines do it: the classic kind (IntelliSense in VS Code) resolves the type under your cursor and lists its members; the AI kind (Copilot) predicts the next tokens from the code around your caret. Different machinery, same move: search a small, local set of candidates and rank them. That locality is why it feels instant. It is also the whole story of what autocomplete can't reach.
TL;DR · the short version
Autocomplete (IntelliSense and Copilot) is a search over a deliberately tiny, local candidate set: the symbols in scope, or the tokens beside your cursor. That locality is why it feels instant, and it is also its ceiling.
The moment the answer lives outside that scope (a sibling repo, a closed file, a config, a document), the suggestion never comes, and the agent falls back to walking the disk with grep and find.
A warm whole-machine index answers "where does this live, anywhere?" just as fast: one file in 85 µs (median 139 µs across 4.47M files), about 412,000× faster than VS Code's Ctrl+P and ~480,000× faster than Windows Search's 67 s.
Inside file contents the same lookup runs in 7 to 9 ms, where ripgrep takes 93.8 s (→ 16 ms, 58,625×). For an agent, a 6m 57s / 71-call hunt collapses to one 16 ms call: ~58% of the session's tokens spent searching drops to ~0%.
Interlinked is that layer, kept warm: ~44 MB idle, edits searchable in ~1 ms. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
The classic path, drawn step by step
It looks up members it already parsed. Then filters by what you typed.
Behind IntelliSense sits a language server that has already read your project and its declared dependencies into a table of every symbol and its type. When you type user., it resolves the type of user, pulls that type's members straight from the table, keeps the ones that match your prefix, ranks them, and draws the menu. No guessing and no scanning: a lookup in a list it built ahead of time. That is why every suggestion is a real symbol that actually exists in scope.
This is the right design for autocomplete: exact, deterministic, and scoped to what the language server loaded (the file you're in, its imports, and the project you opened). It is also, by construction, unaware of any symbol that lives outside that scope: a helper in a sibling repo, a closed file you never opened, a snippet in a document. The candidate list can only contain what was parsed.
The two famous autocompletes
One lists symbols. One predicts text. Both stay under your cursor.
IntelliSense and Copilot are the two autocompletes most people mean. They find suggestions in completely different ways (one reads a symbol table, the other runs a model) but they draw their candidates from the same place: the code you have open right now.
The exact kind. A language server parses your project into a table of symbols. Type a dot and it resolves the type under your caret, lists that type's members, and filters by your prefix. Every candidate is a real symbol that exists in scope, deterministic, never invented.
The predictive kind. No symbol table: a model reads a prompt built from the code before and after your cursor plus your other open tabs, and predicts the next tokens. It can complete a whole function body, but every candidate is still shaped by the handful of files you have open.
Two engines, one radius. IntelliSense reads the symbols the language server loaded; Copilot reads the tabs you left open. Neither reaches a file you haven't opened, a sibling repo on the same disk, or the non-git majority of the machine. Autocomplete is local by design: that is the feature, and the ceiling. How Copilot gathers its context, in detail →
The same trick, a different haystack
Autocomplete searches dozens of things. An agent has to search millions.
Here is the insight that ties it together. Autocomplete is instant because its candidate set is deliberately tiny: the symbols in scope, the tokens near your cursor. It answers a local question: what belongs right here? An agent asks a different question: where does this live, anywhere on the machine? That is a search over a haystack millions of times larger. Same kind of lookup; a different-sized field to run it on.
The trap is assuming the second search must be slow because the haystack is huge. It doesn't have to be. A whole-machine index answers the machine-wide question in the same instant autocomplete answers the local one: it just keeps its list of every file, everywhere, warm ahead of time instead of a list of forty symbols.
Measured on the 4.47M-file machine
The moment the answer is outside the dropdown, someone has to go find it.
Autocomplete can only suggest what's in scope. When the thing an agent needs isn't (a function in a sibling repo, a value in a config, a closed file, a document), the suggestion never comes, and the agent falls back to walking the disk with grep and find. We measured one such run: Claude Code took six minutes and fifty-seven seconds and seventy-one tool calls to land on a single file; through a warm index the same task collapses to one sixteen-millisecond call, roughly seven-million-fold less time on the hunt. The same lookup, everywhere it happens today:
| The searcher | The task | Time | vs Interlinked |
|---|---|---|---|
| Interlinked | one indexed lookup | 85 µs | baseline |
| VS Code Ctrl+P | same file, same drive | 35 s | 412,000× |
| Windows Search | median of 20 queries | 67 s | ~480,000× |
| ripgrep (content) | same query, same corpus | 93.8 s | 58,625× |
| Claude Code (no index) | shells out to grep and find | 3 m 13 s | 2,276,000× |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. Single-file lookups median 139 µs across 20 queries (85 µs typical, 2 µs best case). The ripgrep row is a content query: 93.8 s for ripgrep versus 16 ms on Interlinked over the same corpus, 58,625×. The Claude Code row is a measured single-lookup agent run.
The layer under the dropdown
Autocomplete searches the scope. Interlinked searches the machine.
Interlinked is the big haystack in the diagram, kept warm. It holds an always-fresh index of every file on the machine (names and contents) across every repo and the non-git 90%, and hands it to whatever assistant you use through one connector. It isn't a language server and doesn't try to be: it is the fast, literal layer that answers "where is this, anywhere on this machine?" in the time it takes autocomplete to notice you pressed a key. Keep IntelliSense and keep Copilot: this is the floor they both stand on.
And it already knows how your machine fits together.
The same index carries a knowledge vault any agent reads for free on the searches it already runs, short notes left on a file or folder, and relationships derived from the machine's own history: which files change together, which separate repos ship as a set. No model, no embeddings, no guess: just receipts you can check.
NOT A REPLACEMENT FOR AUTOCOMPLETE: THE WHOLE-MACHINE LAYER UNDER EVERY AGENT, INTELLISENSE AND COPILOT INCLUDED.
Common questions
The questions people actually ask. Answered straight.
Does this replace IntelliSense or Copilot?
No. It's the layer underneath them, so keep both. Interlinked answers the whole-machine question they can't reach (a file you never opened, a sibling repo on the same disk, the non-git 90%), and hands the result to whatever agent you use through one connector.
How can a search over 4.47M files feel as instant as autocomplete?
Because the index is kept warm ahead of time, exactly like autocomplete keeps its symbol table warm. One file returns in 85 µs (a median of 139 µs across 4.47M files), about 412,000× faster than VS Code's Ctrl+P and ~480,000× faster than Windows Search's 67 s. Same trick, bigger haystack.
Can it search inside file contents, not just names?
Yes. Content search runs in 7 to 9 ms. On the same corpus where ripgrep took 93.8 seconds, the indexed query lands in 16 ms, 58,625× faster.
Does it actually make an AI agent faster?
Measurably. One Claude Code run spent 6m 57s and 71 tool calls walking the disk to find a single file, burning ~58% of the session's tokens on the hunt. Through the warm index that collapses to one 16 ms call and ~0% of tokens. The engine sits ~44 MB idle and a saved file is searchable in ~1 ms, so no agent reasons over a stale copy.
What does it cost?
Everything local is free forever, no card. Hosting starts at $5.99/mo.
Do this today
Keep your autocomplete. Add the whole machine.
Install once. One signed installer auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON editing.
Let it index. Filename search works immediately; content search fills in behind it. At rest the whole engine sits around 44 MB, less than a browser tab.
Scope when you can. Whole-machine when you don't know where something lives; a folder when you do. Scoped queries return in the microsecond range.
It stays fresh. Save a file and it's searchable in about a millisecond, so no agent reasons over a stale copy.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · How Copilot finds context