The most useful thing I can tell you about Claude Opus 4.8 is not a benchmark number. It is that the effort setting now decides which model you experience — and that Anthropic quietly changed the default. Opus 4.7 defaulted to xhigh effort; Opus 4.8 defaults to high. If you upgraded, felt the new model was somehow lazier, and could not square that with the glowing charts, you were almost certainly comparing 4.7 at its maximum default against 4.8 at a lower one. The dial moved under you. Learning to drive that dial deliberately is the entire review, and it is a skill I exercise daily, because most of my heavy Laravel work runs at the top tier.
What Shipped on May 28
Claude Opus 4.8 arrived May 28, 2026 as a direct successor to 4.7, available on the Claude API, Bedrock, Vertex AI, and Microsoft Foundry. Two pricing facts frame everything: standard per-token cost did not move ($5 input / $25 output per million tokens), and fast mode — the 2.5x-speed tier — dropped to $10/$50 per million, roughly a third of what fast mode cost on previous Claude models. Anthropic also raised Claude Code rate limits specifically to make room for higher-effort usage, which tells you how they expect the model to be driven: spend more thinking tokens on hard tasks, and the headroom is there for it.
The published benchmarks are strong and mostly honest about their one asterisk. SWE-bench Pro jumped from 64.3 to 69.2 percent — a real gap over GPT-5.5's 58.6 and Gemini 3.1 Pro's 54.2. Humanity's Last Exam with tools reached 57.9 percent, OSWorld-Verified 83.4, GDPval-AA 1890 against GPT-5.5's 1769. The asterisk is Terminal-Bench: 74.6 for Opus 4.8 against GPT-5.5's 78.2 (higher still inside OpenAI's own Codex harness). If your day is raw terminal agentic work — long shell chains, CI orchestration — the competitor still has an edge there, and I can feel that edge when I run Codex and Claude Code against the same repo. Six categories won, one lost. Fine. The chart is not the story.
Effort Levels, Straightened Out
Here is where most coverage garbles the details, so let me lay out the actual mechanics.
The API exposes effort levels — low, medium, high, max-tier reasoning — that control how much the model thinks before it responds. Claude Code then adds a top gear of its own called ultracode, and this is the distinction worth being precise about: ultracode is not a new API effort level. It is a Claude Code setting that pairs the highest reasoning effort (xhigh) with dynamic workflows, where the model plans a large task, spins up parallel sub-agents — tens to hundreds of them — executes the pieces concurrently, verifies its own outputs, and reports back. Reviews that present "ultra" as just a fifth notch on the API dial are describing the wrong mechanism; the top tier changes how the work is organized, not merely how hard one model instance thinks. I went deeper on the orchestration side in my dynamic workflows explainer.
The mental model that survives contact with daily use: effort is a thinking budget, and the budget determines failure mode. Too low, and the model terminates early or reasons shallowly — which now reads as "4.7-style laziness" except it is a setting you chose. Too high, and it meditates over a config lookup, burning tokens and minutes to produce what a grep would have. Same price per token at every level; effort multiplies how many tokens a task consumes. The bill is a function of the dial.
The Refactor That Made Me Trust the Top Tier
My standing test for any Claude release is the kind of work my own codebase generates: a Laravel service class that has absorbed months of feature creep, the file where changing one method turns three unrelated tests red. On 4.7, my experience with this genre was mixed — ambitious starts, then a declaration of "substantially complete" with a half-extracted class and a failing suite.
Running the same genre of refactor on 4.8 at the top tier is where the release earns its keep. The extraction gets carried through — new classes, container bindings updated in the service provider, tests migrated, suite run, self-introduced edge cases caught on the verify pass. But the moment that actually changed my posture was the model telling me what it had not done: it left the caching layer untouched because the original behavior was ambiguous and it declined to guess. That sentence is the release. Anthropic tuned explicitly for honesty about progress — the model is roughly four times less likely than 4.7 to let a flaw in its own code pass unremarked, with a larger reduction in overconfident claims — and in practice that shows up as fewer phantom "done!" reports and more precise statements of the remaining risk. For anyone who runs agents unattended, that trust delta is worth more than five benchmark points.
The behavioral changes underneath the dial are consistent with a week of daily driving: 4.8 reasons before reaching for tools instead of flailing through speculative tool calls, calibrates response length to the question, and holds a goal across a long task instead of satisfying the literal text of the last message. It asks fewer questions than 4.7 did, but the ones it asks are the ones that actually unblock work.
How I Actually Match Effort to Task
This is the tactical part, and it is where I will be prescriptive, because the default-high setting is wrong for about half of a working day in both directions.
Low or medium: anything you could answer with a search. Config lookups, "what does this function do," small single-file edits, commit message drafting. High effort on these is pure waste — slower and no better.
High (the default): the honest middle of development. Feature work in familiar territory, moderate refactors, test writing, review passes. This is where the quality-per-token curve is best, which is presumably why Anthropic parked the default here even though 4.7 defaulted higher.
Max: the tasks you would otherwise babysit. Gnarly single-objective problems — the 600-line untangle, the concurrency bug, the migration with ambiguous edge cases. The tell that you under-dialed: the model "finishes" with visible loose ends. The tell that you over-dialed: you are waiting minutes for answers a mid-tier would have nailed.
Ultracode: repo-scale work with a verifiable definition of done. My sessions at this tier are the ones where the instruction is a paragraph, not a sentence — rewrite this module family, migrate its tests, update the docs, verify the build — and the sub-agent fan-out plus self-verification genuinely pays for itself. Two cautions from living at this tier: dynamic workflows are new and occasionally rough, and the token consumption is enormous by design, so the raised rate limits are load-bearing. Do not park your daily driver here out of enthusiasm; parallelism without a crisp goal produces expensive noise. When I do run long top-tier sessions, the token management habits I use are what keep the spend proportionate to the outcome.
The meta-skill, and I mean this literally: before each task, spend five seconds deciding what failure would cost. Effort should track the cost of being wrong, not the prestige of the task. A one-line change to a payment webhook deserves max; a 200-line scaffold of throwaway UI deserves medium. Most people dial by size. Dial by stakes.
Where This Leaves 4.8 in the Lineup
My verdict after using it as the daily driver: Opus 4.8 is the first Claude release where the model selection question mostly dissolved into the effort question. Same price as its predecessor, materially better agentic completion, a large honesty improvement — and one real weakness in terminal-heavy loops where the competition still leads. The durable lesson outlasts the version number, though. Anthropic has made reasoning depth a first-class user decision, and every release since has kept that shape — when Opus 5 arrived, the effort discipline transferred wholesale. Learn the dial once and it compounds across model generations; that is a better investment than memorizing any benchmark table, including the one above.
The prompt patterns I pair with each effort tier — planning preambles, verify-before-done clauses, scope fences — are written up in my prompt library, organized by task type. Lift the ones that match your work, rewrite the ones that don't, and skip the weeks of deriving them from failed runs.
