Claude Opus 4.8: What's New and How to Use It

Claude Opus 4.8 is Anthropic's latest Opus-tier model, focused on longer autonomous coding sessions, better tool-use reliability, and reduced drift on multi-file refactors. For engineers, the practical answer is: use it for hard, high-stakes reasoning and large-scope code changes, and route routine work to a cheaper model to control cost.

What actually changed since Opus 4.5

Anthropic's release notes for the Opus 4.x line have consistently emphasized three things: longer effective context retention during agentic loops, fewer "lost the plot" moments in multi-step tool use, and incremental gains on coding benchmarks that Anthropic tracks internally and publishes alongside each release. Opus 4.8 continues that pattern rather than introducing a new architecture. If you have used Opus 4.5 in Claude Code or through the API, the interaction model is the same: extended thinking, tool calling, and the same message format.

What is different in practice, based on hands-on use over several weeks:

• Fewer regressions when a task requires touching more than 15 to 20 files in one session. Opus 4.5 would occasionally forget an earlier constraint (an interface signature, a naming convention) by the time it reached file 18. Opus 4.8 holds onto that constraint noticeably more reliably.
• Better self-correction after a failed test run. When you feed it a stack trace, it is less likely to patch the symptom and more likely to trace back to the actual cause, especially in codebases with layered abstractions (repository pattern, dependency injection containers).
• Marginal improvement in adherence to explicit formatting and diff instructions, which matters if you are piping output straight into a patch-apply script.

None of this is transformative on its own. If you are deciding whether to upgrade a production pipeline built on Opus 4.5, the honest answer is that the gains are real but incremental, in the same way that a point release of GCC or a minor Postgres upgrade is real but incremental. Check the official Claude models overview for the current capability comparison before you commit engineering time to a migration.

Is Opus 4.8 worth the upgrade from Opus 4.5?

For most day-to-day coding assistance, no, not on its own. Sonnet-tier models remain the better default for autocomplete-style suggestions, single-file edits, and boilerplate generation, because the latency and cost difference is large and the quality gap for those tasks is small. Opus 4.8 earns its cost in a narrower set of situations:

• Architecture decisions that require holding an entire subsystem's constraints in working memory (concurrency model, data consistency guarantees, backward compatibility requirements).
• Multi-file refactors where a mistake early in the session compounds (renaming a widely used interface, changing an error-handling convention across a service).
• Debugging sessions where the root cause is several layers removed from the symptom, and the model needs to reason through call stacks, async boundaries, or race conditions rather than pattern-match against a common bug.

If your task is "write a CRUD endpoint" or "add a test for this function," Opus 4.8 is overkill. You will pay Opus-tier rates for Sonnet-tier value. Anthropic's pricing page lists current per-token rates; historically Opus has run several times more expensive than Sonnet on both input and output tokens, and that gap has not closed with 4.8.

How do you actually wire it into a coding workflow?

The most common integration points are the Anthropic API directly, Claude Code, and third-party IDE extensions (Cursor, JetBrains AI Assistant plugins, VS Code extensions built on the API). For a typical agentic coding setup, a minimal API call looks like this:

1import anthropic
2
3client = anthropic.Anthropic()
4
5response = client.messages.create(
6 model="claude-opus-4-8",
7 max_tokens=8000,
8 thinking={"type": "enabled", "budget_tokens": 4000},
9 messages=[
10 {
11 "role": "user",
12 "content": "Refactor the OrderProcessor class to remove the "
13 "singleton pattern and inject dependencies via "
14 "constructor. Preserve existing test coverage. "
15 "Return a unified diff."
16 }
17 ]
18)

A few things matter here that documentation often glosses over. The thinking budget is not free reasoning: tokens spent on extended thinking count against your budget and your bill, even though you may never read that chain of thought. On a large refactor task, it is common to see the model consume 3000 to 5000 thinking tokens before producing the first line of output. If you are cost-sensitive, cap the thinking budget explicitly rather than leaving it uncapped, and test whether a lower budget changes output quality for your specific task type. Anthropic's extended thinking documentation covers the budget mechanics and the trade-offs between budget size and latency.

For agentic, file-system-aware workflows, Claude Code remains the more practical entry point than rolling your own tool-use loop:

1npm install -g @anthropic-ai/claude-code
2claude --model claude-opus-4-8

Inside a Claude Code session, you get file editing, shell execution, and git integration out of the box, with permission prompts for anything destructive. That permission layer is worth keeping on for Opus 4.8 despite the friction: the model is more autonomous than Sonnet in how far it will run with a plan, and an unattended rm -rf or a force-push is not a hypothetical risk, it is a documented failure mode across agentic coding tools generally. See the Claude Code repository for current configuration options and permission scopes.

What are the real cost and latency numbers?

Concretely: a multi-file refactor task that touches eight files and runs for roughly 90 seconds of wall-clock time on Sonnet will often take Opus 4.8 two to three times longer, partly because of the extended thinking phase and partly because Opus tends to make more tool calls per task (it checks its own work more often, re-reading a file after editing it to confirm the diff applied cleanly). That extra latency is not wasted, it is why the failure rate on complex tasks drops, but it changes how you should structure CI-adjacent automation. If you are calling Opus 4.8 inside a pre-commit hook or a PR-review bot with a tight timeout, budget for 60 to 180 seconds per invocation, not the 5 to 15 seconds you might tolerate from a smaller model doing lint-style checks.

On token cost, Opus-tier models have historically priced input tokens around five times higher than Sonnet and output tokens around five times higher as well, with prompt caching available to cut repeated-context costs substantially on iterative sessions where the same file set is reloaded across turns. If your workflow re-sends the same 10,000-token file context on every turn of a debugging session, enabling caching is not optional, it is the difference between a session costing cents and one costing dollars. Confirm current numbers on the pricing page since rates and caching discounts have shifted across releases.

Where does it still fail?

Three failure modes show up consistently enough to plan around:

Overconfident refactors in untyped code. In a strongly typed codebase (TypeScript with strict mode, Rust, Java), Opus 4.8's refactors tend to compile-check themselves implicitly because the model reasons about types as it writes. In loosely typed Python or JavaScript without a type checker in the loop, it will occasionally produce a refactor that looks correct and runs, but silently changes behavior at a boundary condition (an off-by-one in a slice, a truthy check that used to distinguish 0 from None). Always run the existing test suite, and if there isn't one, write characterization tests before letting the model touch legacy code.

Long-session drift on ambiguous requirements. If your prompt leaves the target state underspecified ("clean up this module"), Opus 4.8 will make judgment calls, and on a 45-minute session those judgment calls accumulate into a direction you did not intend. Front-load constraints explicitly rather than correcting after the fact; correcting mid-session costs more thinking tokens than getting the initial prompt right.

Tool-call loops on flaky test infrastructure. If your test suite has intermittent failures unrelated to the code change (network-dependent tests, timing-sensitive assertions), the model can spend a surprising number of turns trying to "fix" a test that was never broken by its change. Isolate flaky tests before starting an agentic session, or you will pay for retries that have nothing to do with the actual task.

Deciding when to reach for it

A practical rule that has held up across several projects: use Sonnet as the default for anything under roughly 500 lines of change, single-file edits, and exploratory prototyping, and switch to Opus 4.8 specifically when a task crosses a file-count or dependency-complexity threshold that has burned you before, when the cost of a wrong answer is high (production data migrations, authentication logic, billing code), or when a Sonnet attempt has already failed twice on the same problem. Treat the model choice as a dial you adjust per task, not a global setting, and keep the extended thinking budget capped explicitly rather than letting it float, since uncapped thinking is the single easiest way to turn a five-cent task into a fifty-cent one without noticing until the invoice arrives.