Claude Opus 4.8: the effort dial, fast mode and token math

Anthropic released Claude Opus 4.8 yesterday, on 28 May 2026: an upgrade over Opus 4.7 (which shipped only six weeks earlier, on 16 April) at unchanged pricing of USD 5 per million input tokens and USD 25 per million output tokens. The headline capability gains matter, but for teams running agentic workloads in production the more consequential news is economic: a user-selectable effort control on all plans, a fast mode that runs up to 2.5x faster at USD 10/USD 50 per million tokens (three times cheaper than fast inference cost before), a "dynamic workflows" research preview in Claude Code that fans out hundreds of parallel subagents, and a quiet but important Messages API change that accepts system entries inside the messages array, so you can update instructions mid-task without invalidating your prompt cache. Swedish and EU enterprises that are Azure-first increasingly meet Claude inside Microsoft's ecosystem; Microsoft announced in March that the latest Claude Sonnet model is coming to Microsoft 365 Copilot. For those teams, this release changes the cost model for high-volume agent deployments enough to warrant a fresh calculation.

What actually shipped on 28 May

The capability story first, briefly, because it frames the cost story. Anthropic positions Opus 4.8 as a reliability upgrade for long-running agentic work. The claim that stands out for engineering teams: the model is about four times less likely than Opus 4.7 to let flaws in its own code pass unremarked, with a stronger tendency to flag uncertainty rather than assert unsupported claims. Early testers reported 84% on Online-Mind2Web (a meaningful jump over both Opus 4.7 and GPT-5.5 on browser-agent tasks) and gains on CursorBench across every effort level. Anthropic's applied research team reported the highest score yet recorded on their Legal Agent Benchmark, the first model to break 10% on its strict all-pass standard.

Alongside the model, four platform changes landed:

Effort control on all plans. Users of claude.ai, Cowork and Claude Code can now select how much effort the model spends: high (the default), an extra-high setting, and max. Higher settings spend more tokens for better results; Anthropic notes that coding tasks at the default setting use a similar token count to Opus 4.7 while performing better.
Fast mode at a third of the old price. A research preview that runs Opus 4.8 up to 2.5x faster at USD 10 per million input tokens and USD 50 per million output. That is double standard pricing, but three times cheaper than fast inference previously cost.
Dynamic workflows in Claude Code. A research preview for Enterprise, Team and Max plans that lets a single session fan out hundreds of parallel subagents. Anthropic's example is a codebase migration across hundreds of thousands of lines with test-suite verification.
Cache-preserving system updates in the Messages API. System entries are now accepted inside the messages array, so mid-task instruction changes (permission updates, token budget changes, environment context) no longer force a rebuild of the top-level system prompt.

Pricing for standard inference is unchanged. That is the point: the levers that moved are all about matching spend to workload shape, not about a cheaper sticker price. Which means the savings are only real if you actually do the matching.

The token math that actually drives agentic cost

Before evaluating any of the new controls, it helps to be precise about where money goes in an agentic workload. A chat request is one API call. An agent task is dozens or hundreds of calls, and each call re-sends the accumulated context: system prompt, tool definitions, and the full conversation so far. Input tokens, not output tokens, dominate.

A worked example (illustrative numbers, standard Opus 4.8 pricing of USD 5/25 per million tokens). Say an agentic coding task runs 50 model requests. The context grows over the session; assume an average of 60,000 input tokens per request and 1,500 output tokens per request:

Input:  50 requests x 60,000 tokens = 3,000,000 tokens x $5/M  = $15.00
Output: 50 requests x  1,500 tokens =    75,000 tokens x $25/M =  $1.88
Total (no caching):                                              ~$16.90

Now the same session with prompt caching working properly. Anthropic's standard caching economics apply: cache reads bill at roughly a tenth of the input price, cache writes at 1.25x. If 90% of each request's input is a stable, cached prefix (system prompt, tools, earlier turns) and only 10% is new content:

Per request: 6,000 fresh tokens  x $5.00/M = $0.030
           + 54,000 cached reads x $0.50/M = $0.027
Input over 50 requests:                     ~$2.85 (+ modest write premiums)
Total (well-cached):                        ~$5.00

Roughly a 3.5x difference on the same task, same model, same output. Cache hit rate is the single biggest cost lever in agentic workloads — bigger than model choice between adjacent tiers, and bigger than any effort setting. Which is exactly why the least glamorous item in yesterday's release may be the most valuable one.

Why the mid-task system update matters more than it sounds

Prompt caching is a prefix match: change any byte in the system prompt and every cached token after it is invalidated. Until now, an application that needed to update instructions mid-task had two bad options: rebuild the top-level system prompt and pay full price to re-process the entire context on the next request, or smuggle the instruction into a user turn, which weakens its authority and invites prompt-injection ambiguity. And mid-task updates are routine in practice: tightening permissions after an approval, telling the agent its token budget shrank, injecting fresh environment state.

Consider the failure mode in numbers. With the 60,000-token context above, an application that edits its system prompt every few turns never sustains a warm cache. Every request pays the full USD 0.30 of input instead of USD 0.057, which over 50 requests is USD 15 instead of under USD 3. Multiply by hundreds of daily agent sessions and the difference funds an engineer. The new mechanism appends a system entry inside the messages array, placing the update after the cached prefix so the cache survives. If you operate long-running agents that adapt instructions mid-flight, this one API change probably does more for your invoice than anything else in the release. Action item: audit your agent harness for anywhere it mutates the system prompt between requests, and check your usage metrics. If cache-read tokens are near zero across a long session, you are paying the uncached rate for the whole context on every call.

Fast mode: when 2x the price per token is the cheap option

Fast mode costs exactly double standard pricing per token and delivers up to 2.5x the speed. Naively that looks like paying more for the same work. The right frame is different: for supervised, interactive workloads, the binding cost is the person waiting, not the tokens.

Take a supervised agentic session that produces 200,000 output tokens over an afternoon of iterative work. At standard pricing that output costs USD 5; at fast-mode pricing, USD 10. The USD 5 premium buys up to 2.5x faster generation. If the session is generation-bound and wall-clock time drops from, say, 100 minutes to roughly 40, you have bought back an hour of an engineer's attention. At typical Nordic consulting or senior engineering rates, that hour is worth two orders of magnitude more than the token premium. The maths only ever goes one way for interactive work.

The inverse holds just as firmly. Unattended workloads (overnight refactors, scheduled report generation, bulk classification) gain nothing from speed, so fast mode is pure waste there. The previous fast-inference price made even interactive use a hard sell; at a third of that cost, the calculation flips for most human-in-the-loop scenarios, which is why this price cut materially changes deployment patterns rather than just trimming a line item. Two cautions: it is a research preview, so treat it accordingly in anything production-adjacent (more on that in the EU section), and remember that doubling per-token price also doubles the cost of a poor cache hit rate. Fix caching first, then buy speed.

The effort dial: capability on demand, spend on demand

Effort control is the second half of right-sizing. The default (high) is tuned so that coding tasks consume roughly what Opus 4.7 did while performing better: an effective price cut in quality-per-token terms, for free. The higher settings spend more tokens to reason longer and verify more; Anthropic's CursorBench results show the model beating prior Opus models at every effort level, which is the important detail: the dial trades cost against quality on a curve that has shifted upward across its whole range.

The practical implication for teams is to stop treating effort as a global setting. Route by task class instead: routine transformations, summaries and well-specified edits run at lower effort; hard multi-file refactors, architectural work and anything where a wrong answer is expensive gets the higher settings. And measure. The correct effort level for your workload is an empirical question; answer it with a sweep over a representative task set against your own acceptance criteria, not with a default carried over from the previous model.

Dynamic workflows: parallelism is a multiplier, not a discount

The dynamic workflows preview in Claude Code is the release's most striking demo: hundreds of subagents attacking a large migration in parallel, with the test suite as the arbiter. Two cost observations before your team tries it. First, parallelism compresses wall-clock time; it does not reduce token spend. A migration that fans out across 200 subagents consumes roughly the tokens of 200 sequential agent runs, just faster. Budget accordingly, and note that Opus 4.8's improved honesty about its own code flaws matters here precisely because nobody reviews 200 parallel workstreams by hand. Second, fan-out amplifies whatever cost hygiene you already have: subagents that share a well-cached common prefix are dramatically cheaper than subagents that each pay cold-start context costs. The preview is limited to Enterprise, Team and Max plans, so for most Swedish organisations this lands as a procurement question before it lands as an engineering one.

A right-sizing decision framework

Pulling this together into something a team can apply this week. For each agentic workload, ask four questions in order:

1. Is the cache working? Check cache-read token counts in your usage data. If a long session shows near-zero cache reads, find the invalidator: usually a mutating system prompt, a timestamp in the prefix, or a shifting tool list. With the new in-messages system entries, mid-task instruction changes are no longer an excuse. Fix this before touching any other lever; it is typically a 2-4x saving on input-heavy agent loops.

2. Is a human waiting? Yes: fast mode is a candidate, because the token premium is small against the wall-clock value of an attended session. No (batch, overnight, scheduled): standard mode, always.

3. What does a wrong answer cost? Cheap to detect and retry (tests catch it, output is validated downstream): run at default or lower effort. Expensive or hard to detect: pay for higher effort. Verification tokens are cheaper than production incidents.

4. Does the task decompose? Independent sub-tasks with a mechanical success check (a test suite, a schema validator) are fan-out candidates. Price the fan-out as N full agent runs before you launch it, and cap N.

A useful habit alongside the framework: record effort setting, mode, cache hit rate and total tokens per task class for a couple of weeks. Right-sizing is a portfolio exercise: most teams discover that a small number of task classes consume most of the spend, and that those classes were running at settings chosen by default rather than by decision.

The Swedish and EU angle

Why should an Azure-first team in Stockholm or Gothenburg care about an Anthropic release the day after it happens? Three reasons.

Claude is arriving inside the Microsoft stack you already license. On 9 March 2026, Microsoft announced that the latest Claude Sonnet model is being made available to Microsoft 365 Copilot users. The direction of travel is clear: Claude models are becoming part of the default toolset in environments Swedish enterprises already run, which means evaluating Anthropic's model line is no longer a niche exercise for API-first teams. Whether and when Opus-tier models with these specific controls surface through Microsoft channels is a question to put to your account team. Capabilities, previews and pricing that exist on Anthropic's first-party API do not automatically appear on partner platforms at the same time, and your cost model should assume the conservative case until confirmed.

Data residency and processing need the usual diligence. If you consume Claude through Anthropic's first-party API, your data protection review (transfer mechanisms, DPA terms, retention behaviour) is between you and Anthropic. If Claude reaches you through Microsoft's stack, the processing sits inside your existing Microsoft agreements, which is often the shorter path through a Swedish enterprise's procurement and DPO review. For agentic workloads specifically, remember that the context you re-send on every request is the data being processed: an agent with access to a repository or a document store is transmitting that material to the model provider on each turn. That is not new with this release, but fan-out patterns that multiply requests by hundreds deserve a fresh look from whoever signed off the original assessment.

Previews are previews, and your governance docs should say so. Both fast mode and dynamic workflows shipped as research previews, and dynamic workflows is additionally gated to specific plans. Under the EU AI Act's risk-management expectations, and plain operational prudence, preview features belong in evaluation and internal-tooling contexts, not in systems with availability commitments or in anything customer-facing without an explicit risk acceptance. The effort control and the Messages API caching change, by contrast, are ordinary platform capabilities you can adopt now. Keeping a record of which model version, mode and effort setting served each workload is cheap to implement today and increasingly looks like table stakes for AI system documentation in the EU.

Where to start

Opus 4.8 is a better model at the same price, which is welcome but routine. The shape of the release is not routine: nearly everything new is a mechanism for matching spend to workload. Effort can be dialled per task class. Speed can be bought when a human is waiting. Parallelism can be invoked when a task decomposes, and the cache now survives mid-task instruction changes. Set these levers deliberately, per task class, with measurement behind each choice. Run the cache audit first; it is the least exciting item on the list and the one most likely to pay for itself. If you want help right-sizing an agentic workload on Azure, or working out what Claude's arrival in the Microsoft stack means for your architecture and procurement, that is exactly the kind of engagement we do.