Choosing a model

The model matrix has the numbers. This page is how to decide, and the decision is smaller than the matrix makes it look.

Start at the default

Claude Opus 5 is the default for a reason: it is the tier most work belongs on, and starting elsewhere means optimising before you know what you are optimising for. Move only when you have a specific reason, and the reasons are few.

Move down when the step is mechanical and high-volume. Classification, extraction, reformatting, bulk reading, sub-agents doing the boring half of a task. A smaller model does these at a fraction of the cost and the output is frequently indistinguishable.

Move up when you have genuinely hit a ceiling: you tried the default at high effort, the reasoning was the failure, and the task justifies the cost. "It made a mistake" is not a ceiling. "It cannot hold this problem" might be.

Move sideways for context. Every current model carries a 1M context window except Haiku 4.5, which carries 200K. If a task genuinely needs the large window, that rules one option out and the choice makes itself.

Effort is often the better lever

Before changing model, try changing effort. Lower effort on the same model means less thinking, fewer tool calls, less preamble, and materially lower cost — often with no visible quality loss on routine work.

The order worth trying: right model, wrong effort → adjust effort. Right effort, still failing → then change model. Most people reach for the model first because it is the more visible knob.

Do not pick one model for the project

The instinct is to choose a model the way you choose a framework, once, at the start. Real workloads have steps with very different requirements. A pipeline that reads a hundred documents with a small model and reasons about the results with a large one costs a fraction of one that uses the large model throughout, and is no worse.

Try this

Take a task you currently run entirely on the default model. Split it in your head into the reading half and the reasoning half. Run the reading half on the cheapest model available and compare the final result. If you cannot tell the difference, you have just found a permanent saving.

What goes wrong

Choosing on benchmarks rather than on your task. Benchmark deltas rarely survive contact with a specific workload. Test on your own inputs.

Downgrading to save money on the part that needed the quality. The saving is real and so is the damage. Downgrade the mechanical steps, not the judgement.

Pinning a date-suffixed model id from memory. Current ids are complete as written in the matrix. Appending a date produces a model that does not exist.

Assuming a newer model is a drop-in. Newer models have removed parameters that older ones accepted. Read what changed before swapping an id.

How to check it worked

Run the same twenty representative inputs through both candidates and compare the outputs side by side, not the benchmark scores. If you cannot tell which is which, take the cheaper one — and if you can, you now know exactly what you are paying for.