Choosing a Model
Fast models vs. reasoning models, when escalating is worth it, and what latency and cost actually buy you.
Every tool now offers a model picker, and the names change every few months. Rather than memorising which model is currently best, learn the two axes they vary along — that knowledge survives the next release.
The two axes that matter
Ignore the branding. In practice you are choosing along two dimensions, and the second one is the one people miss.
Capability
How hard a problem it can hold in its head at once. Bigger models handle more interacting constraints before they start dropping some.
Deliberation
Whether it thinks before answering. Reasoning modes work through a problem internally first, which costs seconds and money but changes what is solvable.
A fast model with no deliberation is excellent at the thing you already know how to do. A reasoning model earns its cost on the thing you are stuck on.
The two axes are independent, which is the part worth sitting with. A model can be highly capable and still answer instantly, if the problem in front of it is one it has effectively memorised the shape of. And a model can deliberate for a long time and still be wrong, because thinking longer helps with problems that benefit from working through steps, not with problems where the model is simply missing information it was never given.
What the picker is really asking
Strip away the branding and every model picker on the market is asking the same question in different words: how much of the second axis do you want switched on. The exact labels change with every release. The underlying choice does not.
Deliberation off. The reasonable default — use it until it visibly struggles.
Deliberation on. Reach for it after a specific failure, not as a default.
The same dial, made continuous instead of binary. Higher is not automatically better on an easy task — it is slower and more expensive for no gain.
Read a new picker by mapping its options onto this pair of axes before you touch it. You will be right about what each setting does long before you have learned what it is currently called.
When fast is right
Most of your prompts should use the fast model, and this is not a compromise. For a large share of real work the answer is not hard — it is just tedious to type.
- 1Autocomplete while you type
Latency matters more than depth; a slow suggestion is a useless suggestion.
- 2Renaming, reformatting, mechanical edits
There is no reasoning to do.
- 3Writing a component you have described precisely
You already did the thinking in the prompt.
- 4Explaining what a piece of code does
Reading is easier than designing.
When to escalate
Switch to the slower, more capable model when the difficulty is in the thinking, not the typing:
- 1A bug that survived two fix attempts
Two failures means the obvious answer is wrong, which is exactly where deliberation pays.
- 2Changes that span many files
More interacting constraints than a fast model reliably holds at once.
- 3Anything with a security or money dimension
The cost of a subtle mistake is far above the cost of the tokens.
- 4Design decisions you will live with
Schema shape, API surface, state architecture.
What the cost actually is
Priced per token, these look almost free — fractions of a cent per request. That framing misleads in both directions.
Upward: an agent looping over a large codebase can consume millions of tokens in an afternoon, and reasoning models charge for the thinking you never see. Downward: if a model saves you an hour, almost any per-request price is irrelevant next to an hour of your time.
The number worth watching is not cost per request. It is cost per problem actually solved — and by that measure the expensive model is frequently the cheap one, because three cycles with a fast model that never gets there costs more than one that does.
None of this requires knowing an exact price, and it will keep being true after every price changes. A wrong answer costs you the time to notice it was wrong, plus the time to redo it. A slower, pricier answer only has to beat that combined cost once to be worth reaching for — it does not have to be cheap, it has to be cheaper than being wrong.
Finding out for yourself
Benchmarks tell you about benchmarks. What you want to know is how a model does on your code. Keep two or three problems from your own project that you have already solved, and re-run them whenever you are evaluating something new:
Here is a bug I already fixed, and the code before the fix.Do not look for my solution — diagnose it yourself, explainthe root cause, and propose a fix.Because you know the real answer, you can judge the reasoning rather than being impressed by the confidence. That is worth more than any leaderboard.
Key takeaways
- Two axes: how much it can hold at once, and whether it thinks before answering.
- Most prompts should use the fast model — much of the work is typing, not thinking.
- Escalate on the second failure. The first is usually a prompt problem.
- Judge cost per problem solved, not cost per request.
- Evaluate models on problems from your own codebase where you already know the answer.
Quick check
Answer these to unlock the next chapter — 3 of 4 to pass. You can retake it anytime.
Answer every question to check.
Make a free account to read on
Every chapter is free — an account is how your progress, XP, and streak follow you from your laptop to your phone, and how you show up on the leaderboard. No payment, no trial.