Guides · measured July 2026
Why Cursor slows down on large repos.
The short version: a code index built from embeddings carries a cost that scales with the codebase. It has to be built, kept fresh as you edit, and searched. All three grow as the repo grows. On a small project you never feel it. On a large monorepo, you do. Here is the honest breakdown of where the time goes, then the one number that doesn't move.
The cost, drawn to scale
An embedding index has three costs. Every one scales with size.
"Indexing your codebase" means turning every file into chunks and every chunk into an embedding: a list of numbers that places the code's meaning as a point in space, so a plain-English question can find code that shares no keywords with it. That is a genuinely good tool. It is also three distinct jobs (build, keep fresh, search) and each one gets bigger as the repo does.
The rising curve is the shape of a documented mechanism, not a stopwatch on Cursor: more code means more chunks to embed, more re-embedding when files change, and a larger vector store to search. Cursor's own docs describe the pipeline: embeddings computed on its servers, a change-tracking tree so only edited files are re-embedded. The flat line is measured on the machine cited at the foot of this page: a median 139 µs filename lookup across 4.47M files, with an edit searchable in about a millisecond.
This is not a takedown
Embeddings are the right tool for meaning. The tax is the price of the feature.
Nobody should give up semantic search over the repo they're in. It is the correct design for an in-editor assistant, and the cost is honest: computing meaning is real work. In steady state, small edits re-embed only a handful of chunks, so day-to-day it stays cheap. The lag shows up at three specific moments, and every one of them gets worse the bigger the repo is.
Opening a large repo the first time means embedding every chunk in it before search is fully useful, the one-time build you wait through, and it is proportional to the codebase.
A branch switch, a rebase, a big pull or a code-gen run touches many files at once, so a large slice of the index has to be recomputed, not one chunk, thousands.
The index is scoped to a workspace, so every new project you open pays the build again from zero. Ten repos is ten separate indexes, each with its own tax.
None of this is a bug. It is what any meaning-based index costs. The useful question is not "how do we make embeddings free": it is which searches don't need embeddings at all, and can therefore stay flat no matter how big the repo grows.
Going cross-repo just moves the tax
Sourcegraph indexes many repos, on a server you run, over what you pushed.
"Just index everything" 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 the indexing cost doesn't vanish; it moves to infrastructure you operate. It scales with the corpus, is configured per repo, and sees the pushed state, not the working copy on your disk right now, and never the files that were never in git.
So both famous anchors pay a size-scaled tax; the only question is where it lives. Cursor's is per-workspace, in its cloud vector store. Sourcegraph's is per-org, on a server. Neither is the local, unpushed, whole-machine reality of the box you actually work on, and neither one is fast because it stopped growing.
There is a third shape: an index that is neither per-repo nor on a server, whose cost simply doesn't climb with the codebase, because it answers a different, cheaper question. Where should the index live? →
The one number that doesn't move
A literal index doesn't care how big the repo is.
This is a literal index (names and contents, matched exactly), not embeddings, and it isn't trying to be. It answers "does this string exist anywhere on this machine, and where" instead of "what code means this," which is why its cost is flat: a single file lands in 85 µs, content search runs in the 7 to 9 ms range, and a query that took ripgrep 93.8 s on this corpus returns in 16 ms. The ripgrep comparison → Different job from Cursor's meaning-index: the flat floor it can stand on.
How it sidesteps the per-repo tax
One index for the whole machine. Built once. Handed 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% of your disk, and exposes it to whatever agent you use through one connector. There is no "index this project" event when you open something new, because a new repo is already in it. A save is fresh in about a millisecond with no re-embed churn. And its lookup time doesn't climb with the codebase: it is already answering across 4.47M files in microseconds. That is what makes the line flat.
That same lookup takes VS Code's own search about 35 seconds on this machine (412,000× slower) and Windows Search a median 67 seconds (~480,000×). The whole engine sits around 44 MB at rest, and the index on disk stays under 1% of the drive. It never leaves the machine, and there is no model anywhere in it.
KEEP CURSOR'S INDEX FOR MEANING. ADD THE FLAT, LITERAL LAYER UNDER EVERY AGENT, CURSOR INCLUDED.
Stop paying the build twice
Keep the semantic index. Add the flat one.
One signed installer indexes every file on your machine and wires up the AI clients you already use: no per-repo build, no server, no cloud account, no keys. Cursor keeps doing what it does well inside your open repo; every agent gets a fast, literal, whole-machine search alongside it, the one whose cost doesn't grow when the codebase does.
Everything local is free forever, on all your devices, no card. Hosting starts at $5.99/mo. Download for Windows · What Cursor's index can and can't see