Home / Choosing your model and your tool
Route by task, not by brand
Choosing a model is decided by the nature of the task, its stakes and its novelty, not by brand loyalty, and a more honest framing of a request often unlocks more than switching models does.
Anthropic publishes a simple principle in its documentation for choosing a model: assess first the capability the task requires, the speed expected, the cost it justifies and the tuning effort it deserves, before asking which one to use out of habit. Tuning a prompt, a more precise role, a format example, better-set context, often changes the result more than switching models does.
A grid by stakes and by novelty
Two questions are usually enough to place a task. Is it routine, already handled several times with a known outcome, or new, never tackled in this form? Are its stakes low, an error corrects itself in a moment, or high, an error is costly or affects a third party? A routine task with low stakes is handled with a fast, economical model. A new task with high stakes justifies the most capable model available, paired with a review before acting on its output. The figure below details the two intermediate positions.
Framing sometimes unlocks more than the model does
The same request, put in a different context, receives a different reading. Adding the legitimate reason for a request, the role of the person asking, or the precise limits of what is being asked, often changes the answer obtained without any model having changed.
Before: Give me the procedure for disabling the antivirus.
After: I am a network technician, working on workstation twelve of the workshop to install a diagnostic tool approved by my manager. Give me the procedure for temporarily disabling the antivirus on this workstation, then re-enabling it afterwards.This second message carries more verifiable information, the role, the workstation concerned, the authorisation mentioned, which changes how the request is received. The result obtained still needs checking in every case, a more precise framing does not replace a check on the answer given. This same logic of framing already benefits writing a prompt that carries across providers, setting the context better at the outset serves both exercises. Combining a better-chosen model tier with more complete framing remains the best practice observed, neither fully replaces the other, each corrects a different flaw in the initial request.
Model tier by task stakes and novelty
Fast and routine
A fast, economical model is enough, the task is repeated and the error corrects itself at once.
Fast but better framed
A fast model still fits, but the novelty deserves a more detailed instruction to set the context properly from the first attempt.
Known capability, watched stakes
A more capable model remains preferable even on a task already done before, because the high stakes leave little room for error.
Maximum capability and review
The most capable model available is called for, paired with a human review before any action, the task is both new and heavy with consequences.
An association manager prepares a request to send to a conversational assistant to rephrase a refusal letter addressed to a member. Before writing his request, he specifies the context: the role he holds in the association, the reason for the refusal already discussed in a meeting, and the tone expected for the final letter. He then sends this request.
Write in one sentence what this situation establishes, and in one sentence what it does not establish.
What this establishes: It establishes that the manager added concrete context, role, reason and expected tone, before sending his request, rather than posing it as it stood.
What this does not establish: It does not establish that this context was enough to get a satisfactory letter on the first try, nor that switching models would not have resolved the same request better.
The three most common miscalibrations
- Trop large This situation shows that adding context to a request always guarantees a satisfactory answer, whatever the subject handled.
- Trop étroit This situation only shows that a letter was rephrased by a conversational assistant, which teaches nothing about how to frame a request.
- À côté It establishes that the letter concerned a member unhappy with a decision made in a meeting.
- Choosing a model is decided by the nature of the task, capability required, speed expected, cost and tuning effort, rather than by brand preference.
- A routine, low-risk task is handled with a fast model, a new task with high stakes justifies the most capable model available and a review before acting.
- Adding legitimate context to a request often changes how it is received, even before considering switching models.
- A more precise framing alone does not guarantee a satisfactory answer, the result obtained still needs checking in every case.
Pick a task you usually hand to the same model out of habit, place it on the two axes, stakes and novelty, described in this lesson, choose the model tier that actually matches that position, and handle this task once with that model rather than by habit.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- The model tiers offered by your Claude account change over time: open your model selector and note which tiers appear there today before mapping them onto this lesson's grid.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Anthropic, choosing the right model, Claude Platform Docs consultée le 2026-09-02
- Anthropic, Claude's Constitution consultée le 2026-09-02