How the choice is actually made
- Name the constraintwhat would make this unacceptable?
- Pick a starting pointcheapest that might work, or most capable
- Test on real workyour prompts, your data, your edge cases
- Move one stepupgrade if it fails, downgrade if it passes easily
Re-test when the task, the volume or the model lineup changes
Find the binding constraint
Cost, speed and quality trade against each other, but in any real task one of them is usually the thing that would sink it. A customer-facing autocomplete that takes eight seconds is useless however good the text is. A once-a-quarter regulatory analysis that costs three times more is a rounding error. A pilot running on a limited allowance fails if it exhausts the allowance in a week. Naming that constraint out loud converts a vague preference into a decision you can defend.
| If the scenario stresses… | The binding constraint is | Which points to |
|---|---|---|
| “within two seconds”, “while the caller waits” | Speed | The fastest tier, with effort kept low |
| “40,000 a day”, “every document in the archive” | Cost at volume | The cheapest tier that passes your test |
| “the regulator will read this”, “contradictory records” | Quality on hard reasoning | The capability tier, effort raised |
| “our allowance ran out on Wednesday” | Usage budget | Lighter model and lower effort for routine work |
| “nobody knows if this will work yet” | Learning cheaply | Prototype on the efficient tier, then decide |
When two constraints genuinely bind — high volume and high stakes together — that is a signal to split the work rather than to compromise on one model. More on that below.
Two documented ways in
Anthropic’s guidance on choosing a model offers two starting strategies rather than a single ranking, and which one you take depends on what you are optimising. Starting efficiency-first means beginning with the fastest, cheapest model — Claude Haiku 4.5 in the current lineup — testing thoroughly and upgrading only if it falls short; it suits prototyping, tight latency requirements, cost-sensitive work and high-volume tasks. Starting capability-first means beginning with the most capable model, optimising your prompts, then downgrading if you can; it suits complex reasoning, accuracy-critical work and advanced technical tasks.
Start cheap and climb, or start strong and trim
Efficiency-first
- Start with the fastest, cheapest model
- Test thoroughly against your own cases
- Upgrade only where it visibly falls short
- Fits prototypes, volume and tight latency
Capability-first
- Start with the most capable model
- Optimise the prompt until quality is right
- Then downgrade and see what survives
- Fits complex, accuracy-critical work
The capability-first route has a subtlety worth naming. Optimising the prompt on the strong model and then downgrading often works, because much of what looked like a capability gap was a clarity gap. That is also the honest reason to try it: it separates “this task is genuinely hard” from “my brief was vague”, which is the distinction lesson 1.3 is built on.
Test rather than assume
The documented upgrade-and-downgrade process is not a matter of taste. Create benchmark tests specific to your use case, run them with your actual prompts and data, compare accuracy, quality and handling of edge cases, and weigh the difference against the cost. For a non-technical team this does not require tooling: twenty real examples with known good answers, run on two models, scored on a sheet, will settle an argument that would otherwise run for a month.
Choose the twenty deliberately. Include the awkward ones — the ambiguous invoice, the email in two languages, the case where the right answer is “we cannot tell”. Models diverge most at the edges, and a test set made of easy cases will tell you the tiers are indistinguishable, which is true only of easy cases.
Scoring two tiers on the same twenty cases
- Passes: Straightforward invoices (12 cases)identical output on both tiers
- Passes: Multi-currency invoices (3)both correct; cheaper tier slightly faster
- Check: Missing purchase-order number (2)cheaper tier guesses; stronger tier flags it
- Fails: Contradictory line totals (2)cheaper tier picks one silently
- Passes: Scanned, poor quality (1)both decline and ask for a re-scan
Mix models rather than compromise
When volume and difficulty both bind, the documented answer is not to split the difference but to use more than one model. Anthropic describes two patterns. In the executor pattern, a lower-cost model does the work and escalates hard decisions to a frontier model. In the orchestrator pattern, a frontier model plans and delegates the bulk work to lower-cost workers. Both exist to reduce token costs without giving up quality where quality matters.
In an office setting without any code, the same logic appears as a manual routing rule: run the routine pass on the light tier, and send anything it flags as uncertain to a conversation on the capable tier. The decision that makes this work is defining “uncertain” in advance, not after you have seen the output.
The dial inside the model
In the Claude apps there is a second lever that often matters more day to day than the tier. The effort setting controls how thorough a response is and how much of your usage it consumes: low and medium work well for routine tasks and stretch your usage further, high is the default and is described as offering the best overall balance of quality and speed, and extra high and max exist for long-running and deeply demanding work. Thinking is a separate toggle, and on the most capable current models it cannot be switched off.
So the practical version of “align model selection with task requirements” inside the apps is a pair of choices: which model, and how hard it should work. Simple questions and general writing need neither a heavy model nor high effort. Genuinely difficult analysis, planning and technical problems are where raising effort — and, if needed, the tier — is worth the usage it costs. Usage itself is a live constraint: heavy conversations consume allowance faster, Research can consume it faster still because it retrieves many sources, and very long conversations cost more per turn as earlier messages are summarised to keep going.
One last discipline. A model decision is not permanent. Lineups change, prices change, your volumes change, and a choice made against last year’s constraint may now be wrong in both directions. Re-run the twenty cases when something material moves — and keep them, because the test set is the durable asset, not the answer it produced.
Traps the wrong answers are built from
| Tempting but wrong | Do this instead |
|---|---|
| Ranking models by quality and always taking the top one | Name the binding constraint first, then choose against it. |
| Deciding between tiers by argument | Run twenty real cases on both and compare on accuracy, edge cases and cost. |
| Building a test set out of easy cases | Include the ambiguous, contradictory and awkward ones, where tiers actually diverge. |
| Compromising on one model when volume and stakes both bind | Route routine work to the light tier and escalate defined hard cases. |
| Changing the model when the allowance is the problem | Lower effort on routine work, shorten conversations, move standing context into a Project. |
You should now be able to
- Identify the binding constraint — cost, speed or quality — from a described task.
- Choose between an efficiency-first and a capability-first starting strategy and justify it.
- Design a small benchmark of real cases, including edge cases, to compare two models.
- Apply executor and orchestrator style routing when volume and difficulty both bind.
- Use the effort setting as the within-model dial for thoroughness against usage.
- Recognise when a usage problem calls for effort and context hygiene rather than a model change.