How I Choose AI Models in Cursor

“Which model should I use?” is the most common question I get about vibe coding, and it usually comes pre-loaded with leaderboard anxiety — as if picking the second-best model on some benchmark means shipping second-best products.

Relax. After shipping several products through Cursor, my honest observation: the difference between a good workflow and a bad one is ten times larger than the difference between frontier models. The model matters; it just matters less than the job you give it. So I pick by job.

Match the model to the phase

My loop has phases with very different demands:

Planning and architecture — use the strongest reasoning model you have. This is where a wrong turn costs the most: data models, module boundaries, “where should booking logic live.” Slow and expensive is fine here — plans are short, and rejecting a bad plan costs one message. I’ll happily let the heavyweight model think for a minute about something I’ll live with for a year.

Generation of well-specified chunks — use a fast, capable default. Once the plan exists and the chunk is small (“this component, these props, this existing hook”), most frontier models produce near-identical results. Speed becomes the feature, because the loop’s rhythm is worth more than marginal brilliance. This covers maybe 70% of my prompts.

Debugging something weird — escalate again. “The dolphin jitters when re-entering water at high velocity” or a Firestore rule doing what I said instead of what I meant — cross-domain reasoning, worth the strongest model and a detailed context dump.

Mechanical work — use the cheap fast one. Renames, test scaffolds, converting a component to the established pattern, writing alt text. Using a heavyweight model here is paying architect rates for moving boxes.

The three-strike escalation rule

When a model flails — same bug, second failed fix — I don’t argue with it in eleven more messages. Strike one: re-prompt with better context (usually my fault). Strike two: escalate to a stronger model with the full story. Strike three: I read the code myself, like an animal, because at that point the bug is usually in my understanding, not the model’s.

The anti-pattern is model-hopping mid-task with no added context, asking four models the same vague question and collecting four confident, incompatible answers. That’s not evaluation; that’s a séance.

Habits that beat model choice

• Fresh sessions per task. A mediocre model with clean context beats a frontier model dragging twenty minutes of drift.
• Rules files carry your conventions so any model starts already knowing your world — this is why switching models is cheap for me.
• Let plans be second opinions. For big architectural calls I sometimes ask two strong models for a plan and diff them. Where they agree, I relax. Where they disagree is exactly where I should think myself.
• Re-evaluate occasionally, not constantly. Models improve; my defaults shift a few times a year. Chasing every weekly release is a hobby, not a workflow.

The uncomfortable truth

If your product is failing, it’s almost never the model. It’s the spec, the review, or the judgment around it. The best model in the world generates debt with beautiful indentation if nobody steers — and a merely decent model, inside a disciplined loop, ships real software. I know, because that’s most of what’s on this list.