Skip to content
PD
Claude Code

Models in Claude Code: Which One to Pick per Task

How model tiers differ in agent work, what to use for routine and what for hard problems, how the choice affects spend, and why the most capable model is not the default answer.

All articles in the guide Claude Code · 13

Model choice is the most direct lever on speed, quality and the invoice. Even so, “always take the strongest” is a poor default: it does not win everywhere, and you pay for it everywhere.

How the tiers differ

Three differences matter in practice.

Reasoning depth. How well the model handles work where many relations must be held at once. The gap between tiers is widest here: a subtle bug with a non-obvious cause gets found by a top-tier model while a smaller one circles it.

Speed. A fast model changes the character of the work. When answers arrive in seconds you work in dialogue; when they take half a minute you wait and context-switch.

Price per token. The gap between tiers is a multiple. Invisible on one task, quite visible across a hundred tasks a month.

Worth saying plainly: the difference between models is smaller than the difference between a good and a bad brief. A precise file address and a clear definition of done buy more than moving up a tier.

What to use for routine

The fast, cheap model. The signs of such a task:

  • The solution is known and just needs applying carefully.
  • The edit is mechanical: renaming, formatting, the same change across a list.
  • There is an unambiguous automatic check: the test passes or it does not.
  • The task is short and local.

Reconnaissance belongs here too: find the file, see what calls what, build a list. That is work measured in reading volume rather than thinking depth, and it is better delegated to a subagent on a fast model.

What to use for hard problems

The top tier. The signs:

  • The cause is unknown and has to be reasoned out rather than searched for.
  • Many constraints must be held together: architecture, a migration, a refactor with dependencies.
  • The cost of a mistake is high and no automatic check exists.
  • The task requires choosing between options rather than executing a known one.

A working pattern: analysis and planning on the strong model, execution of the plan on the fast one. The plan is short, expensive to think through and cheap to apply.

The effect on spend

Three things worth knowing before the invoice surprises you.

Context matters more than model. Every request resends the accumulated history. A long, dirty conversation on a cheap model easily costs more than a short session on an expensive one - see limits and context.

A bad loop costs more than a bad model. An agent restarting failing tests twenty times spends more than the gap between tiers. A step limit in non-interactive mode is insurance against exactly that.

Spend grows non-linearly. It is not “twice the tasks, twice the money”: inside a long session, each step costs more than the last.

If cost control is a standing concern rather than a one-off, the routing approach is covered on the blog: the model router that cut our costs.

Choosing in practice

TaskModel
Find a file, build a listFast
Uniform edits across a listFast
Write tests for existing codeFast or mid
Find the cause of a subtle bugTop
Design a schema changeTop
Refactor with dependenciesTop
Apply a finished planFast

Next

How the model is set at launch and switched mid-session is in the CLI commands article. The overview is in the Claude Code guide.

FAQ

Is the most capable model always the right choice?

No. On unambiguous tasks the difference in result is close to zero while the difference in price and speed is obvious. The top tier pays off where many constraints have to be held at once: architecture, a non-obvious bug, a refactor with dependencies. On routine work it is simply more expensive.

Can I switch models mid-task?

Yes, the model can be changed inside a session and context is preserved. A useful pattern: work the hard part out on an expensive model, then finish the mechanical edits from the resulting plan on a fast one.

What drives spend more, the model or context size?

Context. Changing model changes the price per token by a multiple, but a bloated context multiplies the number of tokens on every step of the conversation. A cheap model with a dirty context easily costs more than an expensive one with a clean context.

More on this topic