Cursor is a code editor with the model inside the workflow, not a chat tab beside it. You can point it at a repository, ask it to change several files, run commands, and then review the diff before anything is committed.
That is useful for more than “vibe coding.” Fast generation is one mode. Planning, tests, and a second model that did not write the change are the rest. This guide covers the features worth learning first, then which models to use for writing code and which to use for review. Model names and prices move. The figures below come from Cursor’s models and pricing docs and the Composer 2.5 page, checked in October 2026. Confirm the picker in your editor before you budget a month of usage.
What Cursor changes for a developer
A normal editor waits for you to type. Cursor can also edit the project, read the terminal, and keep going across files. The practical difference is context. The agent sees the code you already have, so a request such as “add validation to this form and cover the empty-email case” can land in the right files instead of a pasted snippet you still have to integrate.
It is a good fit when the task is repetitive, the shape of the solution is already clear, or you want a first pass you will inspect. It is a poor fit when nobody, including you, can say what “done” looks like. The model will still produce a confident diff.
- It keeps the edit loop in one place: read, change, run, fix.
- It works across a real repository, including tests and config.
- It lets you spend a cheap model on routine work and a stronger one on the risky parts.
- It can review a pull request separately from the model that wrote the code.
Features worth learning first
You do not need every panel on day one. These are the parts that change how the editor behaves.
Agent
Agent is the mode that edits files and uses tools. Use it when the change has more than one step: a bug that needs a failing case, a refactor that touches a template and a style file, or a migration that must run a command and report what broke. Give it a result and a boundary. “Update the contact form to reject empty messages, and do not touch the header” is a better prompt than “improve the site.”
Tab completions
Tab is for the line and the next few lines, not for architecture. It is the right tool when you already know the code and want the editor to finish a pattern. Daily Tab use usually stays inside included usage. Daily Agent use does not, which is why model choice matters more once you leave single-line edits.
Plan before a large edit
On a large task, ask for a short plan and stop there. Read it. If the plan edits the wrong layer, correct that before any files change. Planning is cheaper than unwinding a wide diff, and stronger models are often better at the plan than at the first burst of code.
Rules
Rules are standing instructions for the repository: how you name things, what must not be committed, which test command to run. Put the rules where Cursor will read them so you are not repeating the same constraints in every prompt. A useful rule names a check, not a mood.
Run the theme test command before you call a change done.
Do not add a new dependency for a one-line helper.
When reviewing, flag security and broken behavior before style.Point at the files that matter
Attach the file, symbol, or folder the task depends on. A vague request against the whole repository makes the model search, guess, and spend tokens on unrelated code. Narrow context also makes the later review shorter, because the diff stays local.
Bugbot for pull request review
Bugbot reviews a pull request diff and comments on bugs, security issues, and quality problems. It can run on each update, or when someone comments cursor review or bugbot run. In Cursor 3.7 and later, /review and /review-bugbot can review branch changes before you push. Autofix, if you turn it on, uses your default agent model to attempt the fixes. Bugbot is a review pass. It is not the model you should use to invent the feature.
Why it works for vibe coding, and for work you will ship
Vibe coding is the fast path: describe the outcome, accept a wide change, and see if the result feels right. Cursor is strong at that because the agent can keep iterating in the repo. The risk is the same as any fast path. The demo works, the edge case does not, and the review never happens because the same model is asked “does this look good?”
“The model that wrote the change is the worst one to ask if the change is safe. Switch model families, then ask what would break.”
Treat the two modes as different jobs:
- Explore. Use a fast, cheaper model. Ask for a first version and a way to run it.
- Constrain. Once the direction is right, name the files, the tests, and what must stay untouched.
- Review with someone else. Switch to a different model family, or send the diff through Bugbot. Do not ask the author model to grade its own homework.
- Read the diff. If you cannot explain a changed line, it is not ready.
Used that way, Cursor is not only a vibe-coding tool. It is a way to spend less time on boilerplate and more time on the decisions that still need a person: behavior, security, and whether the change belongs in the product at all.
Two usage pools, and why that matters
Cursor bills models from two pools. The Cursor Models pool covers first-party options, including Composer 2.5 and Grok 4.5, 4.6, and 4.7. Those have more included usage. The Other Models pool covers third-party models from Anthropic, OpenAI, Google, and others, charged at their API rates. Pro, Pro Plus, and Ultra include both pools. Auto can route a request for you, with modes aimed at cost, balance, or intelligence, and it bills whatever model it picks.
A practical default is to pin Composer 2.5 for implementation, and to pin a Claude or GPT model only when the task is hard enough to justify the other pool. Switching models every prompt makes it harder to see what your usage is buying.
Best models for coding and for review
There is no single best model. There is a best model for the next ten minutes. Use the table as a routing guide, then keep one coding default and one review default so the choice stays small.
Composer 2.5 for daily coding
Composer 2.5 is Cursor’s own agent model and the one to start with. It is trained for tool use, file edits, and terminal work inside Cursor, including long sessions. Standard pricing on the models page is $0.50 per million input tokens and $2.50 per million output tokens. Fast mode, the quicker variant, is $3 and $15. Cursor’s published comparison puts Composer 2.5 near Claude Opus 4.7 and GPT-5.5 on Terminal-Bench 2.0 (69.3% versus 69.4% and 82.7%) and SWE-Bench Multilingual (79.8% versus 80.5% and 77.8%). Cursor notes that the Opus 4.7 and GPT-5.5 public scores are self-reported. The useful takeaway is not the tenths of a percent. It is that everyday implementation no longer requires the most expensive model.
Claude when the reasoning has to be careful
Use Claude when the cost of a wrong answer is high: an architecture choice, a migration, or a review of a diff you do not want to trust to the model that wrote it. Claude Sonnet 5 is listed at $2 per million input tokens and $10 per million output tokens, which makes it a reasonable “stronger than the default, not the most expensive” step. Claude Opus 5 is listed at $5 and $25, and Claude Opus 5.5 at $4 and $20. Save those for the review pass or the bug that already survived a cheaper attempt. Opus-class models are the wrong default for renaming a function.
GPT-5.5 when the task lives in the terminal
GPT-5.5 is the OpenAI model to reach for when the work is a long agent run, especially around commands and test loops. On Cursor’s comparison it leads Terminal-Bench 2.0 at 82.7%. List price is $5 per million input tokens and $30 per million output tokens, so it belongs on the hard tasks, not on every file save. If you want a cheaper OpenAI daily option, GPT-5.6 Terra is listed at $2 and $12, with Luna below that for small specified edits.
Grok and Gemini for a second pass
Grok 4.6 and Grok 4.7 sit in the Cursor Models pool, so they are a useful second opinion when you want another family without leaving the included first-party usage. Grok 4.7 is listed at $2 per million input tokens and $6 per million output tokens. Gemini 3.1 Pro, at $2 and $12, is a better pick when the task is a large read or a screenshot of a UI, not when you want the first implementation as fast as possible.
Comparison
Prices are list rates per million tokens (input / output) from Cursor’s docs. Included usage depends on your plan, and third-party models on Teams and Enterprise also add a Cursor token rate.
| Model | Best job | Coding | Code review | Price (in / out) |
|---|---|---|---|---|
| Composer 2.5 | Default implementation | Strong, and the one to keep pinned | Only for a mechanical check, not the final review of its own diff | $0.50 / $2.50 |
| Composer 2.5 Fast | Tight edit loops | Same model, quicker responses | Too expensive to use as a reviewer | $3 / $15 |
| Grok 4.7 | Second opinion inside the Cursor Models pool | Good alternate when Composer is stuck | Useful different-family pass before a PR | $2 / $6 |
| Claude Sonnet 5 | Features, tests, focused refactors | Strong step up from the cheap default | Good reviewer when the change is important but not extreme | $2 / $10 |
| Claude Opus 5 | Architecture and high-stakes review | Use after a cheaper model fails | Best Claude pick for an adversarial read | $5 / $25 |
| GPT-5.5 | Long, terminal-heavy agent runs | Strong when the proof is a command and a test | Strong independent review, costly as a default | $5 / $30 |
| Gemini 3.1 Pro | Long context and UI screenshots | Read and plan first | Helpful when the bug is visual | $2 / $12 |
| Bugbot | Pull request review | Not a writer | Comments on the diff; optional autofix uses your default model | Plan feature, not a per-token model row |
A workflow you can repeat
This is the sequence we would use on a feature that has to survive a real review:
- Write the outcome in a few sentences: what changes, what must not change, and how you will know it worked.
- Implement with Composer 2.5. Ask it to run the relevant test or lint command.
- If it fails twice on the same bug, or the blast radius is large, switch to Claude Opus 5 or GPT-5.5 for that problem only.
- Ask a different family to review the diff. The prompt is “what is wrong, what is unsafe, and what would you not ship,” not “rewrite everything.”
- Open the pull request and let Bugbot comment. Fix the findings with your coding model, then read the diff yourself.
Hints that keep the quality up
- Demand a failing test before a fix when the bug is behavioral.
- Reject drive-by refactors. If a prompt was about the contact form, the header should not move.
- Keep secrets out of prompts and rules.
- Prefer a smaller model that you will re-run over a larger model whose diff you will not read.
- Revisit the pinned models every few months. The picker changes faster than your habits will.
What the models will not do for you
A high benchmark does not mean the patch matches your product. Composer can be close to Opus on a public coding eval and still misunderstand a business rule that exists only in your head. Bugbot can miss a logic error that needs the rest of the system to see. None of these tools replace reading the diff, checking the page, or deciding that the feature should not ship.
Kyle Cesmat, an engineering manager at Coinbase, described Composer 2.5 as “the most cost-competitive model at the frontier of intelligence.” Cost is the reason to make it the default. The frontier scores are not a reason to skip the review.
Questions developers ask
Which model should I leave selected?
Composer 2.5. Move to Claude Sonnet 5 for a harder feature, and to Claude Opus 5 or GPT-5.5 only when that attempt is stuck or the change is expensive to get wrong. Use a different family, or Bugbot, for review.
Should Auto pick the model?
Auto is fine when you do not want to think about routing and you accept the cost of whatever it selects. Pinning two models, one for writing and one for review, is easier to reason about once Agent is part of every task.
Is Cursor only for vibe coding?
No. The same agent loop supports a strict process: a written outcome, a cheap implementation pass, tests, a separate review model, and a human read of the diff. Vibe coding is what you get if you skip the last three.
Final words
If you want one default for coding in Cursor, pin Composer 2.5. Escalate to Claude Sonnet 5, then Claude Opus 5 or GPT-5.5, only when the task is hard enough to justify the other pool. For review, switch model families or send the diff through Bugbot.
That split is the whole point of this setup: a fast model to write, a second pass to catch what the first one missed, and you reading the diff before it ships. No magic. No single “best” model for every job.