Explainers · updated July 2026
How Copilot finds context: the code around your cursor, and the tabs you left open.
When Copilot suggests that grey line of code, it isn't reading your whole project. It builds a prompt from the file you're in (the code just before and after your cursor) plus snippets from your other open tabs, ranks them to fit a fixed budget, and asks the model to fill in the middle. It's a fast, clever heuristic. It's also a boundary you can draw: close the tab and the context is gone, and the file you never opened, let alone the other repos or the rest of the machine, was never in the room.
TL;DR · Key takeaways
Copilot's inline completion builds its prompt from just the code around your cursor plus your open tabs (GitHub's neighboring tabs) assembled fresh on every keystroke, with no stored index. Close the tab and that context is gone.
Copilot Chat's @workspace does build a workspace index (remote, local, or basic), but both paths stop at the one folder you opened: the sibling repos and the non-git ~90% of the disk stay dark.
Cursor takes the opposite approach (a semantic index of the repo) yet shares the same edge: scoped to the workspace, siloed to itself, and blind to the rest of the machine.
When the file an agent needs lives outside that circle it has to walk the disk: one measured run spent 6m 57s and 71 tool calls (about 58% of its tokens) to land on a single file, versus 16 ms and one call through a warm index.
Interlinked is the literal, whole-machine layer under all of them: any file in 85 µs (139 µs median across 4.47M files), content in ~7 to 9 ms, fresh ~1 ms after each save, ~44 MB idle, shared with every agent, Copilot included.
The completion path, drawn fairly
The context is whatever you left open. Nothing more.
By GitHub's own description, inline suggestions draw on the current file and your other open editor tabs (a technique GitHub calls neighboring tabs) and use the code both before and after your cursor to fill in the middle. There is no persistent index behind the ghost text: a prompt is assembled from scratch on each keystroke, ranked to fit a limited window, and anything that doesn't fit is dropped. Draw it to scale and the edge is obvious: a small lit box inside the whole machine.
This is the right design for autocomplete: local, fast, and scoped to what you're actively touching. It is also, by construction, blind to everything you don't have open: the closed files in the same repo, the sibling repos on the same disk, and the non-git majority of the machine where the answer often actually lives.
The two ways Copilot gathers context
Completion guesses. Chat retrieves. Both stop at the workspace.
Copilot has a second, heavier way of finding context. When you ask a question in Copilot Chat about your codebase, GitHub builds a workspace index and retrieves the most relevant snippets across the project. GitHub documents three kinds: a remote index for repositories hosted on GitHub, a local index built on your machine for smaller projects, and a basic fallback when neither applies. It's genuinely good for the repo you have open. But completion and Chat share the same edge: the folder you opened in the editor.
No index at all: a prompt built each keystroke from your cursor and open tabs. Instant, local, and forgotten the moment the tab closes.
A retrieval index of the one project you opened. It answers cross-file questions well, inside that project, and only that project.
Both draw their context from the workspace. The sibling repos and the non-git 90% of the disk are outside the circle for either mode.
Copilot and Cursor · the two anchors
Two of the best assistants, one shared blind spot.
Cursor takes the opposite approach to Copilot's open-tabs heuristic: it builds a semantic index of the repository you have open, so plain-English questions find the right code even when you don't know its name. Different machinery, same edge. Both are scoped to the workspace, both keep their context to themselves, and both are dark to the rest of the machine.
| GitHub Copilot | Cursor | |
|---|---|---|
| Finds context by | open tabs + a workspace index | a semantic index of the repo |
| Scope | the workspace you opened | the workspace you opened |
| Context stored in | the prompt · workspace index | Cursor's vector store |
| Blind to | sibling repos · non-git 90% | sibling repos · non-git 90% |
| Other agents can use it | no | no |
The silo is the quieter limit: Copilot's context lives in its prompt and GitHub's index; Cursor's lives in Cursor's vault. Neither is reachable by the other, so every agent that isn't the one that built it starts from nothing. How Cursor's index works, in detail →
One real task, measured on the 4.47M-file machine
When context lives outside the circle, someone has to go get it.
When the file an agent needs was never in its context (a sibling repo, a closed file, a document) it has to go find it, and with no warm index that means walking the disk. 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. Tokens spent grepping are tokens not spent thinking. The same lookup, everywhere it happens today:
| The searcher | The task | Time | vs Interlinked |
|---|---|---|---|
| Interlinked | one indexed lookup | 85 µs | the 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 all of them
One index for the whole machine. Copilot included.
Interlinked draws the outer box in the diagram. It keeps an always-fresh index of every file on the machine (names and contents) across every repo and the non-git 90%, and exposes it to whatever assistant you use through one connector. It isn't a semantic index and doesn't try to be: it is the fast, literal, exhaustive layer that answers "where is this, anywhere on this machine?" in the time Copilot takes to notice you pressed a key. Keep Copilot's open-tabs context and Cursor's embeddings: 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 COPILOT: THE LITERAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT, COPILOT INCLUDED.
FAQ · Common questions
The questions people ask after reading this.
Does GitHub Copilot index my whole codebase?
Not for inline completion: that assembles a fresh prompt from the code around your cursor and your open tabs on each keystroke, with no stored index. Copilot Chat's @workspace does build a workspace index (remote, local, or basic), but only for the single folder you opened.
What are "neighboring tabs" in Copilot?
It's GitHub's name for scanning your other open editor tabs for snippets similar to the code you're writing, then feeding the best of them into the completion prompt. Close a tab and it drops out of context.
Why does Copilot miss files in other repos or outside git?
Both of Copilot's paths stop at the workspace you opened, so sibling repos on the same disk and the non-git ~90% of the machine (documents, configs, datasets, other tools' projects) are never in the prompt. When the file an agent needs is out there it has to walk the disk: one measured run took 6m 57s and 71 tool calls, versus 16 ms and one call through a warm whole-machine index.
How is this different from Cursor?
Cursor builds a semantic (embedding) index of the open repo instead of reading your tabs, so plain-English questions find code by meaning rather than name. Different machinery, same edge: it's still scoped to the workspace and siloed to Cursor, so no other agent can use it.
What is Interlinked, and do I have to stop using Copilot?
No. Interlinked is a literal, whole-machine index that sits under whatever assistant you use, Copilot included. It answers "where is this, anywhere on this machine?": any file in 85 µs, content in ~7 to 9 ms, fresh ~1 ms after each save, ~44 MB idle. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
Do this today
Keep Copilot. Add the whole machine.
Install once. One signed installer auto-configures 19 AI clients: Copilot, Cursor, Claude Code, 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 Cursor indexes your codebase