Tab, and why next-edit prediction is different
Ordinary completion predicts what comes after the cursor. Cursor’s Tab predicts the next change you are going to make, which is a different problem.
Rename a variable in one place and it proposes the same rename at its other uses. Change a function signature and it offers to update the call sites. Add a field to a type and it suggests the corresponding handling elsewhere in the file. Suggestions can appear above the cursor as well as below, and can span several lines.
This is the feature people notice first and the main reason they switch. It is also the feature that most divides opinion: predicting an edit you did not want is more intrusive than suggesting a line you can ignore, and there is no middle setting between helpful and constant.
Inline editing and Agent mode
Select code, describe a change, and see it as a diff to accept or reject in place. That is the fastest loop in the tool and the one experienced users spend most time in.
Agent mode takes a task description and works across multiple files, running commands and reacting to their output — the same shape as Cline or Claude Code, integrated into the editor rather than bolted alongside.
The agent shares the editor’s index, so it starts with context that a terminal agent has to discover. That is a real advantage on a large unfamiliar codebase and a smaller one on a project you know well.
How the index works, and when it goes stale
Cursor builds a semantic index of the project so questions can reach code you never opened. Files are chunked, embedded, and stored so that a query retrieves relevant sections rather than requiring you to name them.
Three things follow from that, and all three matter in practice.
Indexing takes time on a large repository, and the first hour in a big codebase is worse than the second.
A stale index produces confidently outdated answers. After a large merge or a branch switch, answers may describe code that no longer exists — and nothing signals this. Re-indexing when a project changes substantially is worth doing deliberately.
Indexing means processing your code. Which brings the question everyone should ask before adopting it.
Indexing means processing your source
By default, code is sent to hosted models for processing. That is inherent to the product — there is no local model option and no self-hosted deployment.
Cursor offers a privacy mode that changes retention behaviour, and publishes its own documentation on what is stored and for how long. Read that documentation rather than a summary of it, including this one: retention terms are exactly the kind of fact that changes and that a directory entry gets wrong.
The honest framing: if your policy permits using a hosted AI service on your source, Cursor is a reasonable choice and its controls are comparable to its competitors’. If your policy forbids code leaving your network at all, this whole category is out and the answer is Cline pointed at Ollama, or Tabnine self-hosted — accepting a real drop in capability.
Subscription mechanics, and where people get caught
- Windows, macOS or Linux. A desktop application, not a browser IDE.
- A free tier exists with limited requests; sustained professional use needs a paid plan.
- Plans meter requests to the strong models. Heavy agent use consumes an allowance faster than completion does, and exhausting it mid-task drops you to a lesser model — usually at the least convenient moment.
- An internet connection at all times. There is no offline mode, and a poor connection degrades the editor itself, not just the AI.
- Bring-your-own API key is supported for some models, which changes the cost profile for heavy users.
The cost of changing editors
Settings and extensions import, which makes the first hour painless and understates the real cost.
A fork trails upstream VS Code by some interval, so new VS Code features and security updates arrive later. Extensions that depend on very recent APIs may misbehave. Team-wide adoption means everyone changes editors, and mixed teams end up supporting two configurations.
None of that is prohibitive. It is worth knowing before a team standardises rather than after.
Who gets the most from it
Professional developers working primarily in one large codebase. The indexing pays off in proportion to project size and unfamiliarity, so the value is highest exactly where onboarding is hardest.
Teams that prefer one predictable subscription to managing API keys and variable token spend — for many organisations, predictability matters more than being cheapest.
Developers who spend most of their day writing rather than reading, since Tab’s advantage compounds with typing volume.
It is a weaker fit for people committed to Vim, Emacs or JetBrains; for polyglot developers hopping between small projects where the index never pays back; and for anyone whose work cannot go to a hosted service.
What you get for the money
- Next-edit prediction, a genuine step beyond line completion and the clearest reason people switch.
- Whole-codebase awareness without manually adding files to context.
- One tool — completion, chat and agent sharing the same index and interface.
- Predictable billing rather than variable token spend.
- A familiar starting point, since your VS Code setup carries over.
- Fast iteration on the product itself — it has moved quickly and continues to.
The drawbacks worth weighing
- Proprietary and hosted. No self-hosting, no local models, no offline use, no source to inspect.
- Switching editors is a real cost, and the fork lags upstream.
- Strong models are gated by tier, and allowances run out during heavy work.
- Stale indexes mislead with no warning that they are stale.
- Aggressive completion cuts both ways — some developers find it disruptive rather than helpful.
- Vendor concentration. Editor, index and models come from one company, so a pricing or policy change affects all three at once.
If you leave
Your code is untouched — it was always on your disk in an ordinary repository. Settings and extensions came from VS Code and go back to it.
What you lose is the index and any chat history, neither of which is portable. There is no export path for accumulated context, so the switching cost out is the same as the switching cost in: an afternoon of reconfiguration, not a migration project.
The realistic alternatives
- Windsurf — the closest competitor, also a VS Code fork, more agent-first in emphasis.
- GitHub Copilot — keeps your existing editor, weaker codebase awareness, broader IDE support.
- Cline — agent capability as an extension, your own API keys, optional local models.
- Claude Code — terminal-based and editor-independent, no completion.
Compiled from Cursor’s documentation and public sources. Plan limits and data-retention terms change — verify against Cursor’s own documentation before adopting. We have not hands-on tested this tool. Last reviewed 16 August 2026.
Ready to try Cursor IDE?
Visit the official website to get started — most tools offer a free plan or trial.
