Claude Opus 5 for Business: Which Tier to Actually Run

Run the cheapest tier that reliably clears the job's bar, escalate only for work that runs long or that nobody will check, and write the rule down so it survives the next release. Anthropic shipped Claude Opus 5 on July 24, 2026, four weeks after Sonnet 5 landed on June 30. If you run AI in your business, the useful question is not whether the new model is better. It is which of your jobs actually needed it.

I do not run one model. I run three, and the interesting engineering is the routing rule, not the benchmark.

Which Claude model should a business run?

Most businesses answer this once, badly, and then never revisit it. They pick a tier during a proof of concept, wire it into everything, and discover a year later that they are either paying frontier prices to reformat addresses or getting frontier-priced mistakes from a model chosen for being cheap.

Both failures come from the same move: treating model choice as a vendor decision instead of a per-job decision.

Anthropic described Opus 5 as a step change for the Opus tier, aimed at powering long-running agents while improving coding and professional work. Sonnet 5 arrived a month earlier as frontier performance across coding, agents, and professional work at scale. Read those two framings next to each other and the routing hint is right there. One is pitched at long-horizon autonomy. The other is pitched at scale.

That is a much more useful signal than a leaderboard.

What actually separates the tiers in practice?

Not raw capability on an eval you did not run. In production, three things decide which tier a job needs.

How long the task runs. A single call that returns in two seconds has almost nowhere to go wrong. An agent that runs for twenty minutes across thirty tool calls has thirty opportunities to take a wrong turn, and every turn after that inherits the mistake. Compounding is the real variable.

How many steps depend on the last one. Parallel work is forgiving. If one of fifty classifications is wrong, you have one bad row. Sequential work is not. If step three of a chain misreads the requirement, steps four through twelve are confidently building on it.

What a wrong answer costs. This is the one people skip. A wrong answer that a human reviews before acting on it costs a few seconds. A wrong answer that goes straight into a customer email, a contract summary, or a production commit costs something else entirely.

Notice that none of those are properties of the model. They are properties of the job. That is the whole point.

When is the top tier worth it?

I reach for the top tier in four situations, and I try to be honest that they are a minority of total calls.

• Long-horizon agent runs. Anything running unattended across many steps, where an early wrong turn poisons everything downstream. This is Anthropic's own stated framing for Opus 5, and I take it literally.
• Output nobody will check. If a human is going to act on the result without reading it closely, buy the better result. The savings on a cheaper call are not worth the cost of one confident error reaching a customer.
• Genuinely ambiguous judgment. Architecture decisions, gnarly debugging, reading a messy document nobody has structured. Work where the hard part is deciding what the question is.
• First passes I intend to templatize. I will often solve a problem once on the top tier, learn what good output looks like, then rebuild the routine version a tier down with the structure I discovered.

That last pattern is the most underrated. The expensive model is frequently a design tool, not a production dependency.

When is a cheaper tier the right answer?

More often than most teams assume. In my own agent stack the expensive tier does the reasoning steps and the cheaper tiers do the mechanical ones, and the overwhelming majority of calls are mechanical.

The cheaper tiers are the right call for high-volume, low-variance work: classification, extraction, tagging, routing, summarizing something short. They are also right for anything already fenced by a schema or a validator, because the structure is doing the work the model would otherwise have to do from scratch. If the output has to parse as JSON matching a schema, and it does, a lot of the capability gap simply stops mattering.

And they are right for any step where something downstream reviews the output anyway, whether that is a human, a test, or a later stage of the pipeline.

The blog pipeline I run for my own brands is a decent illustration. A researcher agent does genuine reasoning: reading what has already been published, finding a current news hook, deciding whether a topic is worth a post. That earns a strong model. The steps around it, checking whether a slug already exists, validating that a meta description is the right length, confirming a table is well formed, are not model problems at all. Several of them are not even model calls. They are a Python script that exits non-zero.

Which is the other half of the lesson. Before you ask which tier a step needs, ask whether it needs a model.

How do you write a routing rule that survives the next release?

Two frontier releases four weeks apart is the actual argument here. If your architecture needs a rewrite every time a model ships, the architecture is the problem.

Four practices make routing durable:

Route on job characteristics, not model names. Your code should ask "is this a long-horizon step or a mechanical one," not "is this the Opus call." Then a release changes a config value, not a control flow.

Keep model ids in config, never inline. This sounds obvious and is violated constantly. A model id hardcoded in six files is six files you have to find under time pressure.

Have an eval for every job that matters. This is what makes a downgrade testable instead of a gamble. Without one, "could we run this cheaper" is an argument. With one, it is a ten-minute experiment with a number at the end.

Re-test the cheap tier after every release. The floor moves up. Work that genuinely needed the top tier a year ago frequently runs fine a tier down now, and nobody notices because nobody re-checks. That is the most common source of silent overspend I see, and it is also the easiest to fix. This is a normal part of AI integration for business, not a special project.

Opus, Sonnet, and Haiku: a working comparison

This is positioning and usage, not benchmark scores. Check current pricing and specs on Anthropic's own pages before you budget against them, because those move faster than any blog post.

The row that matters most is the last one. This is not a decision you make once.

Frequently asked questions

Should we upgrade every agent to the newest model? No. Upgrade the jobs that were constrained by capability, and leave the ones that were already passing. A newer model on a job that was never failing gives you a bigger bill and an unchanged outcome, plus a re-validation you did not need to do.

How do we know if a cheaper tier is good enough? Run it against your real tasks and compare, not against a benchmark. If you cannot do that in an afternoon, the missing piece is an eval, and building one is more valuable than the model decision you were trying to make.

Does mixing tiers make the system harder to maintain? Only if you scatter model ids through the code. Centralize the routing decision in one place and mixing tiers costs almost nothing. The alternative, one model everywhere, is not simplicity, it is a bill or a quality problem you have not measured yet.

How often does this decision need revisiting? On every meaningful release, which in 2026 has meant roughly monthly. Re-testing is cheap when you have evals and nearly impossible when you do not, which is the real reason to build them.

Is any of this specific to Anthropic? The routing logic is not. Every serious provider ships a tiered lineup, and the same three questions apply: how long does it run, how much compounds, what does a wrong answer cost. What is specific is that model names and capabilities change underneath you, so routing on job characteristics is what keeps the design stable.

The takeaway

A new frontier model is not a reason to change your architecture. It is a reason to re-run your evals.

The businesses handling this well are not the ones that adopted Opus 5 fastest. They are the ones that already knew which of their jobs were long-horizon and which were mechanical, because that made the decision take an afternoon instead of a quarter.

If you want help drawing that line across your own workflows, or you would rather learn to run this yourself, get in touch. I also do 1:1 Claude training and workflow automation at /learn.