Choosing a model for the task

fast, strong, and when to use which

What it is

Every AI service has several models: fast and cheap, slow and strong. The choice between them affects the result as much as the wording of the prompt does.

There are no model names in this article. They change every few months, and a book with specific names would go stale faster than you could finish reading it. The principle of choosing, however, does not change — and that is what is described below.

How to choose

Models differ along two axes: how fast they answer and how well they hold a complex line of reasoning. Those two axes usually pull against each other.

A rule that makes it easy to remember: a fast model is good at what you already know how to check in a minute. A strong one is for where you are not sure yourself.

Signs the wrong model was chosen

Too weak for the task:

• the solution is literal: exactly what was asked, with no regard for the surrounding code;
• it doesn't notice a contradiction in your own prompt;
• asked "what could break", it answers "nothing".

Too strong for the task:

• the answer to a rename takes three paragraphs of reasoning;
• a small edit comes with improvements nobody asked for;
• you wait longer for the answer than it would have taken by hand.

The second mistake is the more harmless one, but it is real: unnecessary reasoning on a simple task costs both time and extra changes in the code.

What to tell the AI

Choosing a model happens in the interface, not in the prompt. But there is a related technique that works with any model: ask it to think before answering.

Before proposing a solution, analyse the task:
what are the options and what are the drawbacks of each.
Then choose and explain the choice.

This gives a noticeably better result on hard tasks even from a fast model — for the same reason the plan-first technique works (article 3.10).

The reverse technique, for simple tasks:

Briefly, no explanations: just rewrite this function
with the new name.

What to look for

One model for everything. If the strong one is chosen "just in case" for good, half the work goes slower than it needs to. If the fast one is, architectural decisions get made superficially.

Changing the model instead of fixing the prompt. If the task is badly stated, a strong model gives a bad answer more convincingly. Article 3.2 first, model switch second.

Limits not taken into account. Models have different context limits and different speeds. On a large project that is felt immediately (article 5.3).

Choosing by yesterday's experience. Models get updated; what was a weak spot a year ago may have changed. Check on your own tasks rather than from memory.

Cheat sheet