Claude Opus 5 for Small Business: Same Price, More Work Per Task

TL;DR

Anthropic released Claude Opus 5 today, July 24, 2026. The headline most outlets ran with is that it gets close to Fable 5, the company's most capable model, at roughly half the cost per task (Anthropic; Quartz). For a small business, that comparison is not the useful part. The useful part is quieter: Opus 5 costs the same as the model it replaces, $5 per million input tokens and $25 per million output tokens, while doing more work per task.

I want to walk through what actually changed, where it helps an operator, and where I would still be careful. I run an AI agent named Jethro on this exact model tier, and it drafts posts like this one, so this is not a spectator's read.

What did Anthropic actually launch with Claude Opus 5?

Opus 5 is Anthropic's new model in the Opus tier, available today through the Claude API as claude-opus-5, in the Claude apps on Pro, Max, Team and Enterprise, and in Claude Code (Anthropic). It also rolled out to AWS Bedrock, Google Vertex AI, and GitHub Copilot the same day (VentureBeat; GitHub).

Pricing stayed at $5 per million input tokens and $25 per million output tokens, identical to Opus 4.8 (Anthropic). On Anthropic's own coding benchmark, Frontier-Bench, the company says Opus 5 more than doubles Opus 4.8's score at a lower cost per task. It is now the default model on the Max plan and the top model on Pro (StreetInsider).

There is a faster setting too. Fast mode runs about 2.5 times the default speed for twice the base price, which matters when a workflow is latency-sensitive rather than cost-sensitive (Anthropic).

I keep saying Jethro drafts these posts. It runs inside Claude Code and picks a model per task, so a launch like this is not abstract for me. The tool I use every day changed underneath the work this morning.

Why does the flat price matter more than the benchmark scores?

Because a flat price with higher per-task performance is a price cut in disguise, and price cuts are what move automation from "nice idea" to "worth building." The leaderboard score tells you which model is smartest. The cost per completed task tells you whether automating a specific job finally pays for itself.

Here is the part I would push back on in most of the coverage. On launch day the instinct is to chase the biggest number. For an operator, the number to watch is the one that did not move: the price.

Think of it like a supplier holding last year's rate while shipping you a machine that produces twice as many units an hour. Nobody renegotiates the contract. The economics just quietly got better. Anthropic's figures point the same way: Opus 5 lands within half a percent of Fable 5 on the CursorBench coding test at half the cost per task (Anthropic; OfficeChai).

I see this directly in how Jethro is run. Every task it does picks the cheapest model that can do the job well, Haiku, Sonnet or Opus, and only reaches for the expensive tier when the work truly needs it. When the Opus tier gets cheaper per result at the same sticker price, the routing math shifts toward doing more of the hard jobs automatically. That is the same logic we lay out in The AI Operations Blueprint: match the tool to the job, then let cost decide how far you automate.

What can a longer-running agent do for a small business back office?

Opus 5 is built for complex, multi-step work: reasoning across many tool calls, making changes, then checking its own output before it hands back a result (VentureBeat). It runs with a one-million-token context window, confirmed in Anthropic's own documentation, so an agent can hold a lot of a business's records in view at once without losing the thread (Anthropic docs).

Translate that to an operator's week. An intake agent can read a new customer message, pull the matching record, draft a reply, and flag the edge cases a human should see, without dropping context halfway through. That is squarely the kind of work in our Automation & Intelligent Workflows practice.

Invoice reconciliation is another fit. Matching purchase orders to invoices to payments is a many-step, rule-heavy job that used to break when a model lost track after a handful of steps. It sits near the top of the 7 most automatable processes in every company for exactly that reason.

When we scope this kind of automation for a client, the question was never "can the model write an email." It was "can it run twenty steps in a row without a person babysitting each one." A more reliable long-running model moves that line, and moving that line is what turns a demo into something an SMB can actually run on a Tuesday.

What does the cost-per-completed-task math actually look like?

The math that matters is not the token price. It is how many attempts finish cleanly without a person redoing the work. A model that completes more multi-step tasks per ten attempts lowers the real cost per finished task, even when the price per attempt barely moves.

Here is a rounded example, not a client figure, to show the shape of it. Say an agent handles that invoice-matching job, and each attempt costs a few cents in tokens either way. With a less reliable model it finishes 6 of 10 cleanly, and a bookkeeper fixes the other 4 by hand. With a more reliable model it finishes 8 or 9 of 10.

The token cost per attempt hardly changed. The human rework, which is the expensive part, roughly halved. That is the number that crosses an ROI line: not the sticker price on the model, but how much staff time the automation still leaves on your plate after it runs.

I watch this exact ratio when I decide whether a workflow is ready to hand to Jethro. If a job still needs a person to redo half its output, it is not automated, it is supervised. The moment that share drops far enough, the same job becomes something the team can trust to run mostly on its own, and that is the moment the spend starts to pay back.

Where should a small business be cautious about Opus 5?

A more capable model is not a licence to remove the guardrails. Anthropic reports Opus 5 as its best-behaved recent model on internal alignment tests, scoring 2.3 on misaligned behavior, the lowest of its recent releases, while still sitting behind a competitor on some cybersecurity tasks (Anthropic). Capable and safe-to-run-unsupervised are not the same claim.

Two practical cautions. First, longer runs use more tokens per run even at a flat token price, so an agent left to wander is a real bill, not a rounding error.

Second, reliability across many steps is better, not perfect. The way I run Jethro, a separate checker reviews the output before anything gets published, precisely because the pipeline has no human approving each step. That pattern matters more as the agent does more on its own, not less.

If you are building your first automation, the model choice is the easy part. The workflow design, the guardrails, and knowing which steps a human still signs off on are the hard part. That is also the case we make in How to Build an AI-Ready Tech Stack: the model is one layer, and it is rarely the layer that decides whether the project works.

So what does Claude Opus 5 mean for your business?

The short version: the cost of a reliable AI "employee" fell, and the number on the invoice did not move. The same per-token budget now buys more finished work per task on agentic jobs, which lowers the bar for which of your workflows are worth automating at all.

In plain operational terms, three things shift. Money first: automations that were "almost worth it" six months ago may clear the ROI line now, because you get more completed work for the same spend. Time second: longer, more reliable agent runs mean multi-step back-office jobs can go further before a person has to step in and re-check. Growth third: a lean team can take on more customer volume without adding headcount at the same rate, because the automation layer got more capable at no extra cost.

So how do you pick that one workflow? Look for a job that runs often, follows clear rules, has inputs you can hand a computer cleanly, and fails in a way you would notice rather than one that quietly corrupts your data. Intake, scheduling, and invoice matching usually fit. A judgment call that changes with every case usually does not.

None of that happens by buying a model. It happens by picking one of those workflows, designing it properly, and putting the right guardrails around it.