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.
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.
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.