Choosing a Model

Ignore the branding. In practice you are choosing along two dimensions, and the second one is the one people miss.

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.

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.

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.

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.

1. 1
   Autocomplete while you type

   Latency matters more than depth; a slow suggestion is a useless suggestion.

2. 2
   Renaming, reformatting, mechanical edits

   There is no reasoning to do.

3. 3
   Writing a component you have described precisely

   You already did the thinking in the prompt.

4. 4
   Explaining what a piece of code does

   Reading is easier than designing.

Switch to the slower, more capable model when the difficulty is in the thinking, not the typing:

1. 1
   A bug that survived two fix attempts

   Two failures means the obvious answer is wrong, which is exactly where deliberation pays.

2. 2
   Changes that span many files

   More interacting constraints than a fast model reliably holds at once.

3. 3
   Anything with a security or money dimension

   The cost of a subtle mistake is far above the cost of the tokens.

4. 4
   Design decisions you will live with

   Schema shape, API surface, state architecture.

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.

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.