Explainers · updated July 2026
What is a code index, and do you need one?
A code index is a prepared map of your code, built once, so a tool can answer "where is this?" without re-reading every file each time you ask. Your editor keeps one. Cursor builds one. Sourcegraph builds one. This is what an index actually is, what it buys you, and the one kind almost nobody has: an always-fresh index of your whole machine.
The idea in one picture
Read everything every time, or read it once.
Without an index, a search tool answers by walking the filesystem (opening folders, reading files, checking each one) from scratch, on every query. It is simple and always gives a correct answer, but the full cost is paid again for every question. An index flips the order: do the reading once, up front, and turn it into a structure built for lookups: a sorted map from "what you might ask" to "where the answer is." The first pass costs something. Every question after it is nearly free. That trade (pay once, look up forever) is the whole idea behind every code index.
Same three questions, same disk, same hardware: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4.47M files. On the left, three tools that re-read the tree each time; on the right, the same queries answered from a prepared index. The single-file lookup lands in 85 µs, the median across all 4.47M files in 139 µs, and a content query that takes ripgrep 93.8 s here returns in 16 ms.
Why every serious tool builds one
"Code index" means three different things.
The word covers three distinct jobs. Most real tools build two or three of them and stack the results, which is why the interesting questions are never "does it have an index" but how much it covers and how fresh it stays.
Jump straight to a file or a function, and list every place it is used. Your editor's Go-to-Definition and Find-References run on one of these.
Answer “does this exact string exist, and where?” across a huge tree without opening every file. This is what powers instant project-wide search.
Ask in plain English and match by meaning, not spelling: “where do we handle refunds?” finds the code even if it never says the word “refund.”
Do you need one? If you have ever run a project-wide search or asked an AI "where is X," you already depend on a code index. The real question is not whether to use one: it is how much of your world any single index can actually see. Index vs RAG vs grep →
The two most famous code indexes
Sourcegraph and Cursor, drawn to scale.
The two indexes most developers have met sit at opposite ends. Sourcegraph builds a code graph across an organisation's repositories, on a server, so a platform team can navigate hundreds of repos at once. Cursor builds a semantic index of the one repo you opened, part on your machine and part in its cloud, so you can ask in plain English. Both are excellent at their job. Both also draw a circle, and it is worth seeing exactly where each edge falls.
| The index | What it covers | Where it runs | Beyond one project |
|---|---|---|---|
| Sourcegraph | an organisation's repositories | a server you host | cross-repo, but only the pushed state |
| Cursor | the one workspace you opened | your machine + Cursor's cloud | no, one repo at a time |
| Interlinked | every file on the machine | a local background service | every repo + the non-git 90% |
The shared gap: one draws its circle around an org's pushed repositories, the other around a single open workspace. Neither is the machine in front of you: the working copies you have not pushed, the dozen repos that ship together, the config that broke the build, and the non-git 90% of the disk that was never a candidate for any of them. How Cursor's index works, and what it can't see →
The index almost nobody has
A machine-wide, always-fresh index is a different animal.
Every index above is scoped to a project: one repo, or an org's repos on a server. For what those tools do, that is the right call. But an agent's questions do not respect project boundaries: the config that broke the build, the PDF spec in Downloads, the helper copy-pasted into three repos, the note you left last week. Answering those needs an index that covers the machine, not a folder.
And it has to stay fresh as every file changes, without a server to host, and without shipping your code to a cloud to be embedded. Scale, freshness, and staying local pull against each other; hold all three at once and you have a genuinely different kind of index: whole-machine, literal, offline, and updated the instant a file is saved.
It runs parallel to Sourcegraph and Cursor, not against them. Keep the code graph. Keep the embeddings. This is the floor underneath both: the layer that answers "does this exact thing exist anywhere on this machine, and where?"
The whole-machine index
Index the machine. Hand it to every agent.
Interlinked 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. It is not a semantic index and does not try to be: it is the fast, literal, exhaustive layer, answered before Cursor notices you pressed a key. The same lookup that cost a Claude Code session 6 m 57 s and 71 tool calls returns in 16 ms and a single call.
That filename lookup takes VS Code's own search about 35 seconds on the same machine (412,000× slower) and Windows Search a median 67 seconds (~480,000×). At rest the whole engine sits around 44 MB in Task Manager, and the index on disk stays under 1% of the drive (about 24 GB on a 4 TB machine). The same index also seeds a knowledge vault: on a fresh install it found 12 of 12 repos and built 26,958 relationship pairs from their own git history: 8,455 events replayed in 1.7 s, no failures, and no model anywhere in the box. How the vault seeds itself →
NOT A SEMANTIC INDEX: THE LITERAL, WHOLE-MACHINE LAYER UNDER SOURCEGRAPH, CURSOR AND EVERY AGENT.
Do you need one?
You already use a code index. Give your agents the biggest one.
Install once. One signed installer indexes every file on your machine and auto-configures 19 AI clients: Claude Code, Cursor, Copilot, Codex, Windsurf, Zed, Cline and the rest. No JSON, no cloud account, no keys.
Keep your other indexes. Sourcegraph keeps mapping your org; Cursor keeps its embeddings for the open repo. This runs alongside: the fast, literal, whole-machine layer under both.
Ask across everything. Then ask any agent “which repos do I have, and how do they relate?” and watch how much lived outside the circle any single project index could draw.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · Why finding files is the bottleneck