Choose for the work, not the leaderboard
The right model is the cheapest one that can carry the risk honestly.
Start with the shape of the job: how much source material it must reconcile, how many steps depend on one another and what happens if the answer is wrong. The first half of this guide answers that for a single job. The second half is for work that is bigger than one job — where the question stops being which model and becomes which model for which part.
Three simple starting points
| Effort | Claude | OpenAI | Use it for | Do not assume |
|---|---|---|---|---|
| Quick, repeated workLow effort | Claude Haiku 4.5 | GPT-5.6 Luna | Clean extraction, reformatting, short drafts and repeated work with a fixed schema. | Ambiguous documents, linked calculations, legal interpretation or competing scenarios. |
| Most professional workMedium effort | Claude Sonnet 5 | GPT-5.6 Terra | Most professional drafting, source comparison, issue lists and structured analysis. | Calling it a calculator. Important figures still need an independent recomputation. |
| Hard, multi-step analysisHigh effort | Claude Opus 5 | GPT-5.6 Sol | Multi-step scenarios, capital structures, trade-offs and analyses where assumptions interact. | Routine extraction. More reasoning time does not make unsupported inputs true. |
The order of operations
- 01
Name the miss
Decide what would make this output unsafe: a fabricated lease term, a formula error, a stale comp or an unsupported legal conclusion.
- 02
Match the context
Use long context only when the job really spans documents. Give every source a name and require page or section citations.
- 03
Buy reasoning deliberately
Raise effort when assumptions interact or scenarios branch. Do not pay for it when the job is a fixed extraction.
- 04
Verify outside the answer
Recompute material figures, trace claims to source documents and keep final approval with the named professional.
Three levers, cheapest first
Changing the model is the most expensive way to change the answer and usually the third thing worth trying. Work down this list before reaching for the tier.
- 01
The prompt and the context
Most disappointing answers are underspecified rather than under-powered. Name the sources, state the format, say what a wrong answer would look like. This costs nothing and it moves the result further than a tier change does.
- 02
The reasoning effort
Every family exposes a thinking-time setting under some name. Raising it on the model you already have is the cheap half of a tier upgrade, and on branching work it is often the whole of what was missing. It buys deliberation, not judgment the model does not have.
- 03
The tier
Move up when the work genuinely changes shape — assumptions that interact, twenty files that must agree, a decision nobody can take back. Move down for anything mechanical. A tier is not a quality dial you turn clockwise until you are happy.
An expensive model on a cheap mistake is waste. A cheap model on an expensive mistake is the mistake.
Cost is a tiebreaker, not the deciding factor, and the thing being priced is not the task — it is the consequence of getting the task wrong. That is why the rest of this guide is organised by what fails rather than by what the work is called.
When the work is bigger than one job
Real work is a chain of roles, and the tier belongs to the role.
Picking one model for a whole session is picking it for whichever step happens to be hardest and overpaying for the other four, or picking it for the average and under-serving the one step that mattered. These are roles, not products — one model can play several — but each is chosen on its own terms.
- 01
Plan
Top tierThe step that decides what the work actually is. A wrong plan executed perfectly is the most expensive output there is, and it is expensive precisely because everything downstream looks like it is going well.
- 02
Fan out
Cheap tierMany small readers, each sweeping a different corner and surfacing candidates. Breadth is the whole job and none of them has to be right on its own. This is where a cheap model earns its keep, and where paying frontier prices fifty times over buys nothing.
- 03
Implement
Mid tierWriting the code, the draft or the document once the direction is settled and the specification holds. Most of the work by volume and, when the plan is good, very little of the risk.
- 04
Judge
Top tierThe step that consumes everything the fan-out found and decides what is real. It is one call against the fleet’s fifty, so its marginal cost is small and its leverage is total. Tiering it down to match the fleet is the most common orchestration mistake and it throws away the entire fan-out.
- 05
Verify
Top tier, ideally a different familyThe last gate before something is shipped, merged or sent. A second opinion is worth most when it comes from a model that did not spend the last hour convincing itself — different families fail differently, and that difference is the only reason a second pass finds anything.
One thing overrides every row: if the session as a whole is consequential — a deploy, a migration, a security review — raise the default rather than patching individual steps upward. A high-stakes session run on a routine default is a chain whose weakest link is whichever step nobody thought to flag.
By application layer
Layers differ in what makes them dangerous, not in how difficult they feel to write. The middle column is the one to read: it is what actually decides the tier. Effort names below map to the model names in the first table.
| Layer | What decides the model | Start at |
|---|---|---|
| Frontend and visual direction | Whether the direction has been chosen yet. Deciding what a screen should be is judgment; building a screen somebody has already decided is implementation. | High to choose and to implement the choice. Medium for build-out once the pattern exists. |
| Application logic and refactors | How many files have to agree afterwards. One file is implementation. Twenty files is architecture wearing implementation’s clothes. | Medium, rising to high the moment a change spans the codebase. |
| Data, schema and migrations | Whether it can be undone. A migration that runs against real data is not a routine change, however small the diff looks. | High, regardless of size. |
| Money, auth and anything a user is trusted with | The cost of being wrong, which has almost no relationship to the size of the change. Billing logic, permissions, anything that grades or charges. | High, regardless of size. |
| Mechanical checks and wide search | Nothing. Typechecks, lint, test runs, single-file lookups and the bulk of a parallel sweep contain no judgment to buy. | Low — but never the step that decides whether those findings are trusted. |
Design is two jobs, and they want different models.
The first job is deciding what a thing should be: the register, the hierarchy, what the page is for and what it must not look like. That is open-ended, taste-bearing and genuinely hard, and it is the one place where the most capable model available is usually worth its price — asked for directions, not for code.
The second job is building the thing that was decided. That is bounded work against a stated standard, and it rewards a model that follows a brief closely and holds a codebase’s existing conventions. A frontier model set loose on it tends to improve things nobody asked it to improve, which on a surface with a house style is not improvement.
The practical split: the strongest model for direction and for the first implementation of a new pattern, the mid tier for everything that follows the pattern. And a written standard the model can be pointed at, because taste that only exists in one session gets re-litigated in the next one.
Writing code and orchestrating work are different capabilities.
Coding agents are not ranked the same on both. On the writing of code itself — a well-specified function, a self-contained fix, a file that has to compile — Codex is frequently the stronger hand, and the benchmarks that compare it against Claude split and change places every few weeks, which is itself the finding: neither family is reliably ahead for long enough to build a habit on.
On everything around the code, the gap is wider and it runs the other way. Holding a plan across twenty files, deciding what to do next, routing work to subagents, carrying a repository’s own conventions into every diff, and changing course when the plan meets the codebase — that is orchestration, and Claude Code is the more capable environment for it by a clear margin. Flexibility is most of the reason: skills, hooks, subagents and scripted workflows are an orchestration layer, and the model that reasons well is the one you want holding it.
What follows is not “use the better one”. Different model families make different mistakes, and that is the entire value of a second one. It earns its cost as an adversarial reviewer — a reader that has not spent the last hour convincing itself the approach is sound — and as fresh priors when the first model has failed the same fix twice. It does not earn its cost as the default implementer, because it arrives cold to the conventions that dominate real quality in a real repository.
A workable division: one agent plans, routes and implements. The second reviews the diff when it is large or touches money, permissions, migrations or grading, and takes a diagnosis-only pass when the first is visibly circling. Then keep a ledger of what each review actually caught — a real bug, useful context, or noise — and revisit the division on that record rather than on benchmark news.
Five ways this goes wrong
The judge was tiered down to match the fleet
Fifty cheap searches, then a cheap synthesis. The synthesis decides whether any of it was worth doing, and it is one call. Pay for it.
The tier went up because the task felt hard
The frontier tier is for long-horizon reasoning, not for “make it better”. Difficulty of the feeling is not difficulty of the reasoning, and a harder-feeling task is often just an underspecified one.
Effort was raised where a different model was needed
Thinking time compounds a model’s judgment; it does not supply judgment the model was never going to have. Try effort first, and stop pretending it is a substitute when it plainly is not.
A cheap model was trusted with text that had to survive verbatim
Quotes, citations, legal language and identifiers get quietly rewritten by models optimised to paraphrase. Anything that must come through unchanged is checked by something that did not write it.
A second model’s review was treated as authority
A reviewer arriving cold does not know the conventions, the history or the constraints. Its findings are evidence to triage, not instructions to apply — and a review that is applied blind is worse than no review, because it carries the appearance of scrutiny.
Need a different model?
These are starting points, not requirements. If your company only approves one provider, use that provider’s option. Move down a tier for cheaper routine work. Move up only when the job is genuinely harder and the better result is worth the extra cost. Lineups change faster than any guide, so check the names and the current prices at the source.