Plan: clarify, research, then a plan you can edit

Some changes are big enough that letting Agent - Cursor’s default execution mode - start editing on its first instinct is how you get a confident rewrite of the wrong thing. Plan, one of Cursor’s four built-in modes (as of September 2026), exists for exactly that change (Plan mode docs). Instead of jumping to edits, it runs a deliberate sequence before a single line is written:

1. It asks clarifying questions. Plan doesn’t assume the spec; it pulls the ambiguity out of you first.
2. It researches the codebase - read-only. It reads and greps to ground the plan in the real code, without touching anything.
3. It writes the plan as an editable markdown file. Not a chat message you skim and lose - a .md artifact you can open, argue with, and rewrite.
4. You edit the plan inline, then build from it.

An illustrative exchange from the course’s budgetcli example - a personal-finance API whose spend rules live partly in budget-policy, a shared package six other services import:

plan ›
> add a second-approver requirement: transactions above a configurable
  threshold can't post until a second user approves them.

  Before I plan this, a few questions:
  • Should the threshold be per-org or global?
  • Does "approve" need an audit record, or just a status flip?
  • Is the second approver any user, or a specific role?

> per-org threshold; yes, every approval must be audited; second
  approver must hold the "budget-admin" role.

  ⏵ Read  src/budget/guard.ts, src/budget-policy/policy.ts,
          src/audit/log.ts, src/models/transaction.ts       (gathering context)

  Wrote plan to second-approver-plan.md:
    1. Add perOrgThreshold to budget-policy (shared package - bump
       minor, coordinate the six importers).
    2. Add an Approval record + audit entry in src/audit/log.ts.
    3. Gate guard.ts on role "budget-admin".
    4. Migration for the transaction approval-state column.
  Edit the plan, then build when you're ready.

Two things in that transcript are the whole reason Plan exists. The clarifying turn caught three decisions you’d otherwise have discovered as bugs. And the research stage is about gathering context, not shipping changes - it reads and greps your actual code to ground the plan, and the only artifact it produces is the plan itself.

Where the plan is saved

Plans are saved by default in your home directory - it’s yours, a personal artifact, not part of the repo. When you want the plan in the repo so teammates (or a PR) can see it, click “Save to workspace”, which moves it into the project.

Plan with one model, build with another

The detail that makes Plan more than a speed bump, shipped in Cursor 2.0 (changelog): you can create your plan with one model and build it with another. Point a frontier reasoning model at the design - where the cost of a bad call is highest - and then hand the approved, written-down plan to a faster, cheaper model to execute. The plan is a markdown artifact, so the second model doesn’t need the first model’s reasoning context; it needs the plan, which is sitting right there. That is the capability-and-cost lens in one move: the strongest reasoning bought only for the turn that changes the answer, a cheaper engine for the typing.

Which changes earn the ceremony

The signal isn’t difficulty - plenty of hard changes are perfectly safe to hand to Agent. It’s who a mistake hurts, and how hard it is to reverse. The second-approver change above lands in a shared package six services import, so a wrong shape propagates before you notice it: that is Plan territory. A contained change in a file you own is the opposite case, and it belongs to Agent, as the Ask and Agent lesson argues.

Try it

Switch to Plan mode (the mode picker next to the chat input, or Shift+Tab) and describe a change that touches three files. Read the plan, argue with one step, then let it execute. Compare the result to what you’d have gotten by jumping straight to Agent mode.

Ask (read-only Q&A), Agent, and Plan all answer one question - how much rope do you hand over before the work starts. Debug is the posture for after the work has started and something has broken. Next: Debug, reproduce, instrument, then fix.