Cursor Review

Cursor is worth paying for because of one mechanism that the marketing buries under the word "autocomplete": its Tab model predicts your next edit, not your next token. After three months as our daily editor across TypeScript, Python, and Rust, that distinction is the entire review. Everything else, the chat, the VS Code base, the pricing, either supports that claim or qualifies it.

What "next edit" actually means

Ordinary completion models, including the one inside GitHub Copilot's classic inline mode, answer one question: given the cursor position, what characters come next. Cursor's Tab model answers a different one: given the change you just made, where do you go next and what do you type there. Rename a struct field and Tab will queue the call-site fixes down the file and let you cycle through them with Tab, Tab, Tab. That is not a longer autocomplete. It is a diff predictor trained on edit sequences, and the practical result is that it tracks an in-progress refactor instead of guessing a line in isolation.

The accuracy is not uniform, and the reason is mechanical. On TypeScript the model has type information to constrain the next edit, so its call-site predictions during a rename were right far more often than wrong in our use. On untyped Python the same feature degraded visibly, because the constraint that makes the prediction cheap is gone. If most of your work is dynamic and untyped, discount the headline feature accordingly. That is the single biggest variable in whether Cursor earns its price for you.

Cmd+K and Composer: the same idea at two scales

Cmd+K is an in-file instruction. Select code, describe the change, get a diff in place, accept or reject. It beats pasting into a chat panel for one concrete reason: the model already has the file and selection as context, so you spend zero turns re-establishing what you are talking about. Composer is the same primitive across many files at once: one instruction, a set of diffs, every one shown before write.

Composer's failure mode is worth naming precisely, because it is not random. An incorrect edit in the first file becomes context for the second, so a single wrong assumption compounds down the change set before any test runs. The discipline that works: keep Composer changes small enough to read every diff, and never let it touch more files than you are willing to review in one sitting. Used that way it handles multi-file refactors that a chat-window tool structurally cannot, because a chat window has no mechanism to apply and reconcile edits across files atomically.

Where the mechanism breaks

Two places, both predictable.

The codebase index. Cursor builds an embedding index so chat and Composer can pull project-wide context. Past roughly 50k files that index lags, and project-aware answers slow and thin out with it. This is the structural ceiling: the feature that makes Cursor smart about your code is exactly the feature that does not scale linearly with repo size. On a large monorepo the per-file experience stays good while the codebase-wide experience does not.

The included usage. Cursor's plans bundle a set amount of frontier-model usage and then bill on-demand in arrears (current Individual plan is $20/month as of the May 2026 pricing page; the request-cap model the older Pro plan used has since shifted to usage-based billing). The behavior to plan around has not changed: lean on chat and Composer all day and you consume the included allowance, after which you either pay on-demand or drop to slower models mid-task. You feel the model downgrade in the latency of the next completion. Budget for it or cap your Composer use.

What you give up by switching: nothing

Cursor is a VS Code fork, not a lookalike. Extensions, keybindings, and settings import on first launch and behave identically because it is the same editor underneath. The switching cost that normally blocks editor migrations does not exist here. That is why the recommendation is unusually clean: the downside of trying Cursor is a config import, not a tooling rebuild.

The verdict

Write code most days and Cursor pays for itself in recovered edit time, specifically because the Tab model turns a refactor into a sequence of confirmations instead of a sequence of manual edits. The recommendation is firm for typed-language work on normal-sized repos.

It flips under two conditions, and only these two. First, if your daily work lives in a 50k-plus-file monorepo, the index lag erodes the project-aware features that justify the price, and a lighter editor plus a separate model may serve you better. Second, if your organization cannot route source code through a third-party editor, the question is moot regardless of how good the Tab model is. Outside those two cases, this is the editor to use.

If you want to try it, start from Cursor's pricing page and import an existing VS Code profile so the only variable you are evaluating is the AI.