There is a particular kind of invoice that arrives at the end of a month running AI in production, and the reaction to it is almost always the same. Not shock at the total, exactly, but confusion about the shape of it. The workflows you thought were expensive turn out to be cheap. Something you barely think about turns out to be most of the bill. And nothing in the dashboard explains why.
Usually the answer is that a model somewhere is thinking very hard about something that did not require any thought.
Claude Opus 5 arrived on 24 July 2026 and most of the coverage went to the benchmark numbers, which are genuinely strong. But the change that will show up on an actual invoice is quieter: a five-position effort setting that lets you tell the model how thoroughly to work on each individual request.
What actually shipped
Opus 5 is priced at $5 per million input tokens and $25 per million output tokens, identical to Opus 4.8 and roughly half of Claude Fable 5. On agentic coding it posts 43.3% on Frontier-Bench v0.1, against 33.7% for Fable 5, and more than doubles Opus 4.8. On SWE-bench Pro it reaches 79.2%, within a point of Fable 5 at 80.0% and Mythos 5 at 80.3%, and well clear of Opus 4.8 at 69.2%.
Read those two paragraphs together and the interesting fact is not any single number. It is that a substantially more capable model arrived at exactly the same price as the one it replaced, which is the same pattern we traced in the AI price war. Capability per euro keeps climbing while the sticker stays still.
The effort settings are low, medium, high, xhigh, and max. They apply per request, which is the detail that makes them useful. This is not an account-level plan you pick once. It is a decision you can make differently for every single call your business sends.
What the effort dial really does
The mental model that helps here has nothing to do with tokens. Think about the difference between how you answer a colleague who asks where the office printer is, and how you answer one who asks whether you should take on a particular client.
The first question gets an immediate answer. You do not weigh options or consider second-order effects, because doing so would be strange and would not improve the answer. The second question deserves genuine consideration, and answering it in half a second would be a worse answer, not a faster one. You already run an effort dial. You have simply never had to pay for the setting.
That is precisely what the effort parameter controls. At low effort the model produces a fast, direct response with minimal internal deliberation. At max it works the problem extensively before answering, exploring approaches and checking itself. The output quality difference on a hard task is real and worth paying for. The output quality difference on an easy task is close to nothing, and you pay for it anyway.
The default matters enormously here, because most businesses never change it. Every request in your system currently receives the same amount of deliberation regardless of whether it is classifying an email as spam or drafting a contract summary. One of those is being underserved. The other is being wildly overcharged.
Why thinking costs money
The mechanism is worth understanding precisely, because it explains why the effect on your bill is larger than people expect.
Reasoning tokens bill as output tokens. When a model deliberates before answering, that deliberation is generated text, and it is charged at the output rate. On Opus 5 that is $25 per million against $5 per million for input, which means the expensive half of your bill is the half you never see. Your prompt might be four hundred tokens. The visible answer might be three hundred. The thinking in between can run to several thousand, and it costs five times what the prompt did.
This is why AI costs so often feel disconnected from usage. A business looks at its request volume, multiplies by what it assumes a request costs, and gets a number nothing like the invoice. The gap is deliberation on tasks that never needed any. A classification workflow running at high effort across ten thousand items a month is paying for ten thousand small essays that nobody will ever read, in order to produce ten thousand one-word answers.
We wrote about routing between models to cut AI costs previously, and the effort parameter is the same principle operating at a finer grain. Routing asks which model should handle this. Effort asks how hard that model should work. You want both, and effort is considerably easier to implement because it requires no additional infrastructure.
Matching effort to the job
The useful sorting question is whether the task has one correct answer that is already determined by the input, or whether it requires judgement between genuinely competing options.
Tasks with a determined answer belong at low effort. Classifying a support ticket into one of six categories, extracting a date and an amount from an invoice, deciding whether a message is a complaint or a question, tagging a lead by industry, converting between formats. In every one of these the answer is fully specified by the input. There is nothing to weigh. Additional deliberation does not improve accuracy because there was never a decision to make, only a recognition to perform.
Tasks requiring judgement belong high. Drafting a reply to an unhappy customer where the wrong tone costs you the relationship. Summarising a long contract where missing a clause has consequences. Any workflow where the model is choosing between several defensible approaches rather than identifying the one correct one. Here the deliberation is the value, and economising on it produces work you will have to redo.
The awkward middle is where most business work actually sits, and the honest guidance is to start at medium and move based on results rather than theory. What makes this tractable is that the settings are per-request, so this is not a single decision applied to everything. It is a small set of decisions applied to a small set of workflow types, and once made they mostly stay made.
When turning it down is a mistake
The failure mode of every cost-optimisation article is that it treats spending less as the goal. It is not. The goal is not paying for deliberation you do not need, which is a different thing, and confusing the two produces expensive mistakes that look like savings.
The clearest case for leaving effort high is anything customer-facing where the output is not reviewed by a person before it goes out. A slightly worse internal summary costs you nothing much. A slightly worse reply sent directly to a customer who was already annoyed can cost you the customer, and no amount of token savings covers that. Where the model is the last step before a human sees the result, the savings are almost never worth it.
The second case is anything feeding a downstream decision. If a model classifies a lead and that classification determines whether a salesperson ever calls them, the classification is not a cheap task even though it looks like one. The cost of getting it wrong is a lost deal, not a wasted token. The relevant question is never how simple the task looks, it is what happens when the answer is wrong.
The third case is anything with real reasoning depth, particularly multi-step agent work. An agent operating at low effort across a ten-step task compounds small errors at every step, and the failure arrives at step nine looking mysterious. Debugging that costs more in your own time than the setting ever saved. This is the same trap we described in why AI projects fail: the cheap configuration that produces work requiring supervision is not cheap, it has just moved the cost somewhere that does not show up on the invoice.
How to actually set this up
The realistic version of this work takes an afternoon and does not require rebuilding anything.
Begin by finding your highest-volume workflow rather than your most important one. Cost concentrates in repetition, so the thing running four thousand times a month matters more to your invoice than the thing running twice, even though the twice-a-month task feels more significant. Most businesses have one or two workflows generating the large majority of their token spend, and they are usually unglamorous: classification, tagging, extraction, routing.
Take that workflow and ask the sorting question honestly. Is the answer determined by the input, or does it require weighing options? If it is determined, drop it to low and run it against a sample of thirty real cases you already know the right answers to. Compare. In most classification and extraction work the outputs will be indistinguishable, and you have just removed a meaningful fraction of your bill without touching quality.
Then leave everything else alone for now. The instinct after one success is to turn every dial down, and that is how you end up with a customer reply that reads slightly wrong and no idea which change caused it. Change one workflow, verify against real cases, and move to the next. Boring and sequential beats clever and simultaneous, because clever and simultaneous is untestable.
What you end up with is not a dramatic transformation. It is a business where the expensive model works hard on the decisions that deserve it and answers quickly on the ones that do not, which is how you would want a competent employee to spend their attention. The invoice arriving at the end of that month is finally shaped like the work.