Which Model for Which Job

The question that settles almost everything

You don't need a table with ten criteria. Before handing Claude Code a job, ask yourself one question:

"Is there something to figure out in this job, or is there just something to do?"

Sounds obvious. It's ninety percent of the choice.

When there's just something to do

There are jobs where you already know the answer, and you just need someone to execute it without mistakes:

• renaming or reorganizing lots of files according to a pattern you already have in your head;

• converting stuff from one format to another;

• listing what's inside a folder;

• repeating a change you already made on the first file across twenty more.

Here the fastest and cheapest model is the right call, not a compromise. Be careful not to confuse a lot with hard: three hundred files with a clear rule is still simple work, done three hundred times.

When there's something to figure out

Other jobs don't have a ready answer, and someone has to reason through it:

• a new problem you've never dealt with before;

• an error that keeps coming back and no one can figure out where it's from;

• two requirements that contradict each other, and you need to decide what to give up;

• setting something up from scratch that you'll be carrying forward for months.

Here you go up a rung. It's the only place where paying more gives you something back: you're not buying speed, you're buying judgment.

The practical rule, for when you're unsure

You'll doubt yourself often, especially early on. The rule is: start with the mid-tier model, the balanced one. If you see it going in circles, repeating the same mistake twice, or missing the point, move up.

The reasoning is arithmetic: starting from the middle, when you guess right you've spent the right amount, and when you guess wrong you find out fast. Starting from the top by default, on the other hand, you pay full price even on the hundreds of routine jobs you'll do — and those are the majority.

What's next

With the engine chosen, there's one more dial left that almost nobody knows they have, and it explains half of the weird behavior: how much you want it to think. That's the next lesson.

Did you get it?

Two minutes, no grade. Trying to answer — even getting it wrong — cements the concepts far more than rereading. Not in the mood? Skip it: the lesson still counts as complete.

1You need to rename three hundred files according to a pattern you've already given it. Which model?

The most capable one — that's a lot of files, better not risk it The fastest and cheapest one — there's nothing to figure out, just execution

2An error keeps coming back and no one can figure out where it's from. Which model?

The fastest one, so you can run through a lot of attempts quickly One of the capable models — here the answer isn't obvious, it needs reasoning

3What's the practical rule when you're unsure?

Start with the mid-tier model and go up only if you see it can't handle it Always start with the most capable one and scale down when you notice it was overkill Switch models on every request depending on how long it is