Comparisons · measured July 2026
Cursor indexes one repo. Interlinked indexes the machine it sits on.
Open a project in Cursor and it builds a semantic index of that one repo, a genuinely good map of what your code means. But your machine holds a dozen repos that ship together, plus the non-git 90% that was never in any index. This is not a fight: keep Cursor's index for the repo you're in, and add a whole-machine layer underneath it that every one of your agents can query. Here is exactly where each boundary falls, on two axes: how much it sees, and how many agents it serves.
First, they answer different questions
One indexes meaning. The other indexes everything.
Cursor turns each file into an embedding (a point in space where similar ideas land near each other), so a plain-English question finds the right function even when you don't know its name. That is semantic search, and it is the correct tool for reasoning inside one project. Interlinked does something different and complementary: it keeps a fast, literal, always-fresh index of every filename and every byte across the whole machine, so an agent can ask "does this exact string exist anywhere?" and get an answer in the microsecond-to-millisecond range. Different job, different scope.
For the full mechanism (chunking, embeddings, where your code goes): how Cursor indexes your codebase →
Two axes, one picture
How much it sees × how many agents it serves.
Every code index lives at a point on two axes. Scope: one repo, or the whole machine. Reach: one editor, or every agent you run. Plot the three tools and the shape of the market falls out: the top-right corner (everything, for everyone) is empty until you draw the outer box.
One repo, one editor. Deep semantic understanding of the folder you opened, reachable only from Cursor. The right design for an in-editor assistant, and a small circle on a big machine.
Many repos, cross-repo graph, but it runs on a server, is configured per repo, sees the pushed state, and answers through its own surfaces. Wider than Cursor, still not the local disk.
The whole machine: every repo plus the non-git 90%, served to 19 clients through one connector. Not semantic: literal and exhaustive. The floor the meaning-index stands on.
The other famous anchor
"Just index all the repos" is Sourcegraph, with a catch.
Cross-repo indexing is a solved problem at the org level. Sourcegraph builds a code graph across an organisation's repositories. Powerful, and the right tool for a platform team. But it runs on a server, has to be configured per repo, and sees the pushed state, not the working copies sitting on your disk right now, and never the files that were never in git.
So the two anchors bound the same gap from opposite sides. Cursor sees one local repo in depth, but only that repo and only from Cursor. Sourcegraph sees many repos, but server-bound, pushed-only, and through its own surfaces. Neither indexes the local, unpushed, non-git reality of the machine you actually work on, and neither hands that to every agent. The layer nobody indexes is the one closest to you.
That cross-repo fact (a folder of separate projects that ships together) is something neither a per-repo embedding index nor a pushed-only code graph can represent. How the vault seeds itself →
The comparison, row by row
Same axes, spelled out.
This is not "who is faster at the same task": Cursor and Sourcegraph answer a semantic question Interlinked doesn't try to answer. It is a map of coverage: what each one sees, where it lives, and who can query it.
| By the axis | Cursor | Sourcegraph | Interlinked |
|---|---|---|---|
| What it indexes | the one repo you opened | many repos you configure | every repo + the non-git 90% |
| Where the index lives | your disk + Cursor's cloud | a server you run | your disk (offline, no cloud) |
| Local, unpushed files | yes: the open repo | no: the pushed state only | yes: the live disk, ~1 ms after a save |
| What a query matches | meaning (semantic vectors) | a code graph across repos | exact names + contents (literal) |
| Agents that can use it | Cursor | Sourcegraph's own surfaces | 19 clients: any agent, one connector |
Speed, for the literal layer, on the same machine: a single filename lands in 85 µs, a median 139 µs across all 4.47M files; content search runs in the 1 to 10 ms range: a query that took ripgrep 93.8 s here returned in 16 ms. Those are literal-lookup times, not a like-for-like race against semantic search; they are the floor the meaning-index stands on. Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. Full write-ups: the 412,000× lookup and the ripgrep comparison.
Keep Cursor. Add the layer under it.
One index. Every agent reads it.
Interlinked draws the outer box in the matrix. 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 agent you use through one connector. Cursor keeps doing what it does well inside your open repo; every agent, Cursor included, gets a fast, literal, whole-machine search alongside it. The two live at different points on the map, so you don't choose: you stack them.
Cursor is lit white above because it doesn't leave: it keeps its own semantic repo index and also reads the shared layer. The other 18 clients get the same whole-machine search for free, from the same index, with no per-tool setup.
It never leaves the machine, and there is no model anywhere in the box: every result is an index lookup, not a guess. At rest the whole engine sits around 44 MB in Task Manager, and the index on disk stays under 1% of the drive. A single filename lands in 85 µs (139 µs median across 4.47M files); VS Code's own search takes about 35 seconds on the same machine, 412,000× slower.
NOT A REPLACEMENT FOR CURSOR'S INDEX: THE LITERAL, WHOLE-MACHINE LAYER UNDER EVERY AGENT, CURSOR INCLUDED.
Add the machine under your editor
Keep Cursor. Add the rest of your machine.
One signed installer indexes every file on your machine and wires up the 19 AI clients you already use: no JSON editing, no cloud account, no keys. Cursor keeps its semantic index inside your open repo; every agent gets a fast, literal, whole-machine search alongside it. Then ask any of them "which repos do I have, and how do they relate?" and see how much lived outside the circle.
Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo. Download for Windows · How Cursor's index works · Why finding files is the bottleneck