Comparisons · measured July 2026 · 7 min
Cursor is a fork of VS Code. So what actually changed?
Cursor didn't rebuild the editor: it forked it, then bolted an AI layer on top. The intelligence is genuinely new: Tab, Composer, a semantic index of your repo. But open the file switcher in either one and you are looking at the same code: the same Ctrl+P, the same content search, inherited unchanged. Here is what the fork changed, where each editor fits, and the one layer both still stand on: how they actually find things on your machine.
TL;DR
Cursor is a fork of VS Code. The AI layer is genuinely new (Tab, Composer, a cloud semantic index), but the file and content search is inherited unchanged. Both editors find files the exact same way.
That shared search re-walks the disk on every query. On a real drive (Ryzen 9 9950X3D, 4.47M files), a single Ctrl+P lookup takes 35 s, identical in both editors.
A warm, whole-machine index finds that file in 85 µs (412,000× faster than the inherited Ctrl+P) and answers a content query in 16 ms that took ripgrep 93.8 s (58,625×).
Choose by how central AI is to your loop, not by how you navigate. Switching forks is cheap; neither one touches the retrieval floor beneath both.
Everything local is free forever, no card. Hosting starts at $5.99/mo.
The fork, drawn to scale
New at the top. Identical at the bottom.
Cursor is built on the open-source core of VS Code, so almost everything below the AI layer is shared: the editor, the extension system, the terminal, Git. What the fork adds is the top tier: Tab autocomplete, the Composer agent, and a cloud semantic index of your open repo. VS Code reaches roughly the same AI through the GitHub Copilot extension. Underneath both, unchanged, sits the layer that decides how fast either one finds a file at all.
The fork changed the top of the stack, not the floor. Both editors still find files the exact same way.
The fork story is public: Cursor ships the VS Code editor core with its own AI on top; VS Code's Ctrl+P and its Search panel walk the workspace on the filesystem, and the Search panel is ripgrep-backed. Cursor inherited both verbatim. The AI got smarter. The way you get to a file did not.
The honest verdict
Pick by how deep you want the AI, not by how you navigate.
Because the editors share a core, switching is cheap: your extensions, keybindings and muscle memory come along. The real choice is how central AI is to your loop. Neither is strictly better; they are tuned for different defaults.
Best when you want the standard, free, hugely-extensible editor and opt into AI on your terms.
GitHub Copilot brings capable autocomplete, chat and an agent mode as an extension. Microsoft owns both, so the pairing is well-supported.
Lightest default footprint, nothing leaves the machine until you enable a cloud extension. The safe baseline millions already run.
Best when AI is the center of the loop, not a plugin you toggle. The whole editor is arranged around it.
Tab and Composer are native and best-in-class: multi-line completion and a multi-file agent that feel built-in, because they are.
The @codebase semantic index answers meaning questions across your open repo. The trade: embeddings are computed in the cloud, and it is a paid subscription.
Same editor core, same extensions, same file and content search. Cursor's semantic index adds a new way to ask about the meaning of code in your open repo, but for "jump to this file" or "find this exact string," both editors run the identical inherited search. And that search only ever sees the folder you opened.
The floor neither fork touched
Same search. Same wall.
The inherited search re-reads the filesystem on every query, because it keeps no warm index of your machine. On a small workspace you never notice. On a real drive (measured here on a Ryzen 9 9950X3D with 4.47 million files) it is the slowest thing either editor does, and it is byte-for-byte the same in both.
| The lookup · on 4.47M files | VS Code = Cursor | Warm index |
|---|---|---|
| Find one file by name (Ctrl+P) | 35 s | 85 µs |
| Find a literal string (content search) | ripgrep · 93.8 s | 16 ms |
| Edit a file → searchable again | re-scanned on demand | ~1 ms |
Methodology: Ryzen 9 9950X3D · 64 GB DDR5 · NVMe · Windows 11 · 4,470,000 files. The middle column is VS Code's own search, which Cursor ships unchanged as a fork: a single-file Ctrl+P lookup and its ripgrep-backed content search. The warm-index column is a purpose-built engine on the same drive: 85 µs single file (139 µs median of 20), and a content query that took ripgrep 93.8 s returning in 16 ms. Full method in the 412,000× write-up and the ripgrep comparison.
The layer under the fork
Replace the inherited floor. Both forks get faster.
Interlinked draws the highlighted floor in that diagram, but warm. It keeps an always-fresh index of every file on the machine, names and contents, across every repo and the non-git 90% that no workspace search touches. It is not a semantic index and doesn't try to be: it is the fast, literal layer that answers "does this exact file or string exist anywhere on this machine?" in the microsecond range, and it exposes that to whatever editor or agent you use through one connector. Keep Cursor's semantic edge; keep VS Code's simplicity. Just stop re-walking the disk to find anything.
And because it sees the whole disk, not one open folder, it carries something a per-repo semantic index structurally cannot: a knowledge vault the engine derives by itself (which files change together, which separate repos ship as a set) plus notes any agent leaves that every other agent reads. On a fresh machine, day one:
A saved edit is searchable again in about a millisecond, under 30 ms worst case. The inherited search re-scans on demand. At rest the whole engine sits around 44 MB in Task Manager, and the index on disk stays under 1% of the drive (~24 GB on a 4 TB machine). It never leaves the machine, and there is no model anywhere in the box.
NOT A REPLACEMENT FOR EITHER EDITOR: THE WARM, WHOLE-MACHINE FLOOR BOTH FORKS INHERITED COLD.
Common questions
The fork, answered.
Is Cursor just VS Code with AI?
Essentially, yes. Cursor is a fork of the open-source VS Code core, so the editor, extensions, terminal and Git are the same code. What the fork adds is a native AI layer: Tab, Composer, a cloud semantic index; what it inherits unchanged is how you find files and text.
Does Cursor find files or text faster than VS Code?
For a literal "jump to this file" or "find this exact string," no: both run the identical inherited search that walks the open workspace on the filesystem. On a real drive (Ryzen 9 9950X3D, 4.47M files) a single Ctrl+P lookup takes 35 s in either editor; a warm, machine-wide index does the same lookup in 85 µs.
How much faster is a warm index than the search both editors ship?
412,000× for a single filename lookup (85 µs versus 35 s) and 58,625× for content search, returning in 16 ms a query that took the ripgrep both editors ship 93.8 s. Freshness costs about 1 ms, so a saved edit is searchable again almost immediately, and the whole engine sits around 44 MB at rest.
Which should I choose: Cursor or VS Code?
Pick by how central AI is to your loop, not by how you navigate. Cursor arranges the whole editor around native AI (a paid subscription, with embeddings computed in the cloud); VS Code is the free, standard editor you add GitHub Copilot to on your own terms. Because they share a core, switching either way is cheap.
Do I have to switch editors to get the faster search?
No. Interlinked isn't an editor: it's the warm, whole-machine retrieval floor both forks inherited cold, exposed to whichever editor or agent you already use. Everything local is free, forever: the app, whole-machine search, MCP. Hosting starts at $5.99/mo.
Do this today
Keep your editor. Warm the floor.
Keep whichever you use. This changes nothing about Cursor or VS Code. Keep your fork, your extensions, your keybindings. Nothing to migrate.
Install once. One signed installer indexes every file on your machine and auto-configures 19 AI clients: Cursor, VS Code / Copilot, Claude Code, Codex, Windsurf, Zed and the rest. No JSON editing, no cloud account, no keys.
Let it index. Filename search works immediately; content search fills in behind it. At rest the whole engine sits around 44 MB. The walk becomes a warm lookup in the microsecond range.
Ask across the machine. Then ask any agent “which repos do I have, and how do they relate?” and see how much lived outside the one folder your editor could search.
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