Ask vs Agent and the run loop
Pick the right mode and know the four beats of an agent run.
Ask vs Agent: pick the right mode
After this you can decide when a task wants Ask or Agent.
Two modes, one decision.
The mode changes what you are asking Cursor to own. Ask keeps the work in your hands: it reads context, explains paths and helps you decide. Agent takes a bounded task and produces a diff you can review.
Agent is the right surface when the task needs edits, tool use, verification and a reviewed hand-back.
That extra power needs a sharper definition of done. Before you switch to Agent, name the files or behavior in scope, the change you expect and the check that will prove it worked.
- Understand a file / get an explanation
- Ask
- Make a multi-file change end to end
- Agent
- Run a refactor and the tests after it
- Agent
- Draft a snippet you'll paste yourself
- Ask
Give Agent a task, a goal and a check.
Give Ask a question.
Rename getUser to fetchUser across the repo, update its tests, then run the suite and show me the diff.
Task: the rename. Goal: every call site and its tests updated. Check: a green suite and a diff to read.
Takeaway. Use Agent for changes across files. Use Ask for answers.
Self-check
QYou want to rename a function across the codebase and update its tests. Ask or Agent?
Anatomy of an agent run
After this you can name the four beats of an agent run so you know where to intervene.
Every agent run moves through the same four beats:
- 1Plan: restate the goal and sketch the steps.
- 2Act: edit files and run tools or commands.
- 3Verify: run tests or commands.
- 4Hand back: summarize the diff for review.
The beats are useful because they give you places to stop the run. If the plan is vague, fix the prompt. If the action touches unexpected files, pause before the change grows. If verification is missing, run a check or ask for one.
The hand-back is a diff to review, not a result to accept.
Read the change and run it before you ship.
Those beats play out inside the Agents window. The figure below walks its three panes and what each one is for.
Interactive diagram. Tab through its regions; each focused region shows its detail in the panel below.
One instance can drive many agents across many repositories at once.
This kind of allows you to run multiple agents across multiple projects, switch between the progress of them, and see them unfold in real time.
Takeaway. Plan, act, verify, hand back. You stay in control at review.
Self-check
QAn agent starts editing files you never named. Which beat do you stop it at?
Choosing a model per task
After this you can match the model and its dials to the task in front of you.
The picker is a routing decision, not a loyalty contest.
Cursor exposes the frontier models alongside its own in-house ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. models in one picker. You don't have to know them all. You do need a rule of thumb for which way to lean when the task changes.
For demos and quick, low-reasoning lookups, like asking when you signed up once the tables are wired, a fast ComposerCursor's own fast coding model, tuned for the editor and priced well below frontier models; the recommended day-to-day model for executing a plan. model blends speed and medium intelligence. When production is down with a database error, or the bug is genuinely gnarly, reach for a smarter, longer-running model.
The split is rough but useful: Opus models lean creative, GPT models lean problem-solving.
We've seen that Opus is a bit more creative. The GPT models are a bit more problem solving.
Interactive widget. Tab through its controls; the result updates in the panel below as you change them.
Plan with a thinker, execute with a fast model.
Lean fast for low-reasoning lookups; lean smart and long-running for hard debugging. Auto routes for you.
Three dials on every model
Past the name, a model has three dials. Read them as a task fit, not a leaderboard.
The context window the model can hold.
Select the largest window when the task needs to reason over a lot of code at once.
High, medium or low.
Crank it up for hard debugging; drop it for a quick wired-table lookup.
The fast variant costs more.
It runs the same model on different GPUs. You pay for hardware, not a different brain.
Speed is typically more expensive, but uses the same model, just different GPUs.
Takeaway. Pick fast for quick lookups, a smart, longer-running model for gnarly bugs.
Self-check
QProduction is down with a database error and the bug is gnarly. Which way do you lean on the model picker?