Cursor vs VS Code, and whether the AI features justify switching editors

The Cursor versus VS Code comparison was simpler two years ago, when one editor had an agent and the other had an extension. That gap has closed from both directions. VS Code ships agent sessions, checkpoints, and instruction files of its own, and Cursor has moved much of its agent work out of the editor into a CLI and cloud machines. What remains is a narrower and more practical question: which of the specific differences is worth changing editors over, and which are settings.

What is the same

Cursor is based on the VS Code codebase, and the practical result is that the editing surface is shared. The keybindings, the Command Palette, the extension model, the settings file, the integrated terminal, the Source Control tab, the profile system. Cursor's settings panel has a one-click import that transfers extensions, themes, settings, and keybindings from a VS Code installation, which is possible only because both sides speak the same format.

This is why "switching editors" overstates the change. Nothing about how text is edited is at stake. What is at stake is which AI system is wired in, how much autonomy it gets, and who bills for the tokens.

One inherited detail is worth naming, since it cuts against Cursor: the documentation states that Cursor is regularly rebased onto the latest VS Code version but often runs a slightly older one for stability. Anyone relying on very new editor APIs will meet that lag.

What each side has built on top

Both editors now have an agent that can read a codebase, edit files, run terminal commands, and iterate. The differences are in the details.

On the Cursor side, the agent is opened with Cmd+I, cycles between Agent, Plan, and Ask modes with Shift+Tab, and has no limit on the number of tool calls in a task. Tab completion is the distinguishing everyday feature: it suggests code from recent edits, surrounding code, and linter errors, edits multiple lines at once, adds missing imports, predicts the next editing location when Tab is pressed again, and offers cross-file jumps through a portal window at the bottom of the editor.

On the VS Code side, agent sessions are built in, with the model, permission level, and agent role configurable per session, and checkpoints that restore workspace files and chat history. The documentation is careful about what that undo covers.

Stopping a request doesn't undo file edits, terminal commands, or other actions that already completed. To restore affected workspace files and chat history, restore a checkpoint. Source: code.visualstudio.com

Cursor's checkpoints answer the same problem from the other direction: they snapshot modified files before significant agent changes, restore files without deleting the conversation, and are stored locally and separately from Git.

Instruction files have converged almost completely. VS Code automatically detects an AGENTS.md file in the workspace root and applies it to all chat requests in that workspace, alongside .github/copilot-instructions.md and dynamically applied *.instructions.md files. Cursor reads project rules from .cursor/rules as .mdc files with frontmatter controlling when each applies, and also supports a plain AGENTS.md. A repository can carry instructions that work in both.

Where the real differences sit

Three things genuinely differ, and they are the ones to weigh.

The first is completion behavior. Cursor's Tab is the feature most users name when asked what they would miss, because multi-line edits, automatic imports, and the jump to the next edit location change typing rather than chatting. It is also the feature most likely to irritate: the controls for snoozing it, disabling it globally, or disabling it for particular file types sit in the Tab status indicator in the bottom-right corner, and turning it off for markdown is a common early adjustment.

The second is how command execution is governed. Cursor's Run Modes are a single explicit setting with three positions: Auto-review runs allowlisted calls immediately, sandboxes other shell commands where possible, and sends the rest to a classifier that can allow, redirect, or ask. Allowlist runs only pre-approved actions. Run Everything runs everything. The sandbox blocks unauthorized file access and network activity, and commands needing writes outside the workspace cannot use it, so they surface for review.

The third is billing. VS Code is free, and the cost is whatever AI subscription is attached to it. GitHub Copilot's individual plans are Free at $0 with 2,000 completions per month and limited chat and agent usage, Pro at $10 a month, Pro+ at $39, and Max at $100. Cursor's plans are Hobby free, Pro at $20, Pro+ at $60, Ultra at $200, and Teams from $40 per user per month, with usage drawn from monthly pools that reset with the billing cycle and do not roll over.

	Cursor	VS Code
Editor cost	Bundled with the plan	Free
Free tier	Hobby, limited usage	Copilot Free, 2,000 completions a month
Paid entry	$20/mo	$10/mo for Copilot Pro
Agent	Built in, Agent, Plan, Ask modes	Built in, configurable sessions
Completion	Tab, multi-line and cross-file	Inline suggestions and next edit suggestions
Instruction files	.cursor/rules, AGENTS.md	AGENTS.md, .github/copilot-instructions.md, *.instructions.md
Undo for agent work	Local checkpoints, separate from Git	Checkpoints restoring files and chat history
Version currency	Rebased, often slightly behind	Current by definition

What the model is allowed to see

Both editors let a project decide what goes into context, and the mechanisms are similar enough to describe together. Cursor reads a .cursorignore file in the project root, respects .gitignore automatically, and already excludes environment files, .git/, and lock files by default. The limit is documented rather than hidden: ignored files are blocked from the agent, but terminal commands and MCP tools run outside those file access controls and may still read them. An ignore file shapes context. It is not a boundary that survives an agent with shell access.

On the vendor side, Cursor's pricing page states that privacy mode can be enabled in settings or by a team admin, and that with it on, code data is not used for training by Cursor or its model providers. Team-wide privacy mode is listed as a Teams plan feature. Anyone evaluating either editor under a client contract should read the current terms on both sides rather than relying on a summary, since these policies change more often than feature lists do.

Migration cost, measured honestly

Switching editors sounds expensive and mostly is not, which cuts both ways when weighing the decision.

Moving to Cursor takes one click for extensions, themes, settings, and keybindings, or a manual profile export through the Command Palette when moving between machines. Two adjustments usually follow: learning that AI settings live in Cursor Settings while everything else stays in the VS Code settings panel, and deciding whether to restore the vertical activity bar by setting workbench.activityBar.orientation to vertical.

Moving back is equally cheap, since the settings format is shared and nothing about the project is locked in. Rules written as AGENTS.md stay readable by both. What does not move is the habit built around one editor's completion behavior, which is the part that takes a week rather than a minute.

The real cost of switching is not the migration. It is the attention spent evaluating instead of working, and the subscription that gets paid during the overlap. Setting a deadline for the trial, a week is usually enough, keeps that cost bounded.

The question that decides it

Comparison tables rarely settle this, because the deciding factor is usually not in them. It is how much of the day the agent is expected to handle.

For someone who writes most of the code and wants a strong autocomplete with occasional agent help, the comparison is close, and price favors staying. Copilot's paid entry is half of Cursor's, and VS Code stays current with its own releases. Tab is the argument for moving, and a week of trial answers it better than any article can.

For someone who delegates large tasks and spends the day reviewing, the deciding features are the approval model, the undo model, and the ability to run agents outside the editor. Cursor's split between editor, CLI, and cloud agents is built around that pattern: the CLI runs the same modes in a terminal with a print mode for scripts and CI, and cloud agents run in isolated virtual machines that keep working when the laptop closes.

There is also a middle path that the binary question hides. Cursor's CLI installs with one shell command and runs the same Agent, Plan, and Ask modes in a terminal, with a print mode for scripts and CI, resumable sessions, and a sandbox toggle. Using it does not require moving editors at all: a VS Code user can keep the editor and still run Cursor's agent on the same repository from a terminal tab. For work that is shell shaped to begin with, that combination answers the comparison without picking a side.

For teams, the variables change again: pooled usage, privacy mode, centrally managed rules, and audit controls land in different tiers on both sides, and those details move faster than any comparison page. Check the current terms directly before committing seats.

The third option the comparison hides

There is a case where switching editors does not address the problem at all, and it is common enough to name. If most of the friction in a day is not inside the editor, no editor choice fixes it.

The shape of that friction is familiar: a project open in the editor, a terminal window for the commands the agent does not run, a file manager for everything outside the repository, and a browser for the rest. Assets on an external drive, reference material in a notes folder, downloads waiting to be sorted, screenshots that need renaming before they are used. None of that is in the repository, so none of it is in the editor, and each of those tasks is a window switch.

Both editors are organized around one opened project, by design. Reducing the switching means either deciding that everything lives in the project, which rarely survives contact with real work, or collapsing the windows that exist only to bridge each other. A file manager with a built-in terminal removes one switch by putting the folder and the shell acting on it in the same window, which is what Features describes. Whether that overlaps with a paid agent subscription, or sits beside it, is the question answered on Pricing and in the comparisons on Compared with other file managers.

What to change first

Before switching editors, spend one week measuring where time actually goes: typing, reviewing agent output, or moving between windows. If it is typing, try Cursor's Tab for a week and let that decide. If it is reviewing, the approval and undo settings matter more than the logo on the editor, and both sides have them. If it is window switching, the thing to change is the workspace around the editor, which is what Atriens is built for.