Claude Opus 4: The Complete Guide for Coding and Reasoning

This is for: developers, technical founders, and product teams deciding whether Claude Opus 4 is worth the extra cost over Sonnet or Haiku, and how to get the most out of it once you commit to it.

Claude Opus 4 is Anthropic's top-tier reasoning and coding model, and the honest answer to "should I use it" is: for anything with real complexity, real stakes, or a long time horizon, yes — and for everything else, no. This guide covers what the model is actually good at, how its extended thinking works in practice, concrete prompting patterns that move the needle, and the decision rule I use with clients before reaching for it over a cheaper model.

What Claude Opus 4 actually is

Opus is the top tier in Anthropic's current lineup, sitting above Sonnet and Haiku on capability and price. As of mid-2026 the current shipping version is Claude Opus 4.8, with Opus 4.7 and 4.6 still active for teams that haven't migrated yet. Pricing across the Opus 4.x line has held at $5 per million input tokens and $25 per million output tokens — roughly 1.7x Sonnet's list price and 5x Haiku's. Context window is 1 million tokens across the whole family, with up to 128K tokens of output per request (streaming required above roughly 16K output tokens to avoid client-side timeouts).

The practical distinction that matters more than benchmark scores: Opus is trained for long-horizon autonomous work. It holds a plan across many tool calls, self-corrects instead of drifting, and does not need the task re-explained every few turns the way weaker models sometimes do. That's the entire value proposition. If your task fits in one prompt-response cycle, you are paying for a strength you aren't using.

Where the 4.x line stands right now

If you're maintaining code that still references "Opus 4" as a single entity, treat it as a family — the version number matters for API behavior (see the breaking-changes section below), not just capability.

What it's actually good at

Three things separate Opus from Sonnet in real project work, not benchmark PDFs:

• Long-horizon coherence. On a multi-hour refactor or a large migration, Opus keeps the original goal in view across dozens of tool calls. Sonnet is very good here too, but Opus degrades slower as the task gets longer and messier.
• Judgment under ambiguity. When a spec is incomplete or contradictory, Opus is more likely to notice the contradiction and ask (or flag it) rather than silently pick one interpretation and run with it. This matters enormously for legacy-code work where the "spec" is whatever the previous developer's code implies.
• Bug-finding depth. In code review, Opus catches more real bugs with fewer false positives than Sonnet, particularly on concurrency issues, off-by-one errors in loop boundaries, and cases where a fix in one file silently breaks an assumption in another.

None of this means Opus writes better boilerplate. For a CRUD endpoint, a form component, or a straightforward API integration, Sonnet is equally correct and meaningfully cheaper. Opus earns its price on the 20% of tasks that are actually hard.

Extended thinking: what changed and how to use it

If you learned extended thinking as thinking: {type: "enabled", budget_tokens: N}, that's now dead weight on current models. Opus 4.7 and 4.8 (and Fable 5) reject budget_tokens outright with a 400 error. The replacement is adaptive thinking, where you stop specifying a token budget and instead tell the model how much effort to spend:

response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    thinking={"type": "adaptive"},
    output_config={"effort": "high"},  # low | medium | high | xhigh | max
    messages=[{"role": "user", "content": "Refactor this module to remove the circular import, keep all existing tests passing."}],
)

The effort parameter is the real lever now. Five levels exist on Opus 4.7/4.8: low, medium, high (the default), xhigh, and max. For coding and agentic work specifically, xhigh is the sweet spot — it's what Claude Code defaults to internally. Reserve max for genuinely hard, latency-insensitive problems; in practice it shows diminishing returns and can overthink simple sub-problems within a larger task.

One quiet but important default change: on Opus 4.7 and 4.8, thinking content is omitted by default — the thinking block exists in the response but its text field is empty. If you're rendering Claude's reasoning to users or logging it for debugging, you must opt in explicitly:

thinking={"type": "adaptive", "display": "summarized"}

Without display: "summarized", a UI that streams reasoning to the user will show a long silent pause before the answer appears — the model is thinking, you just can't see it.

Practical tip: don't reach for max effort as your default. Sweep medium, high, and xhigh against your own eval set first. Higher effort often reduces total turns and cost on genuinely agentic work by planning better up front — but on routine tasks it's pure waste.

When Opus wins vs. when it doesn't

The rule of thumb I actually use with clients: if you can fully specify the task in one paragraph and verify the output in under a minute, use Sonnet. If the task requires the model to hold context across many steps, notice things you didn't explicitly ask about, or make judgment calls with real consequences, use Opus. Don't default to Opus everywhere — for our own tooling and most client sites, Sonnet handles the bulk of work at a fraction of the cost, and we reserve Opus for the genuinely hard 10-20%.

Prompting patterns that actually move the needle

Give the full task spec up front, not progressively

Opus performs best when you hand it the complete goal, constraints, and relevant context in the first turn rather than dribbling it out over several messages. This isn't a stylistic preference — Opus's long-horizon planning quality depends on knowing the destination before it starts. Underspecified prompts revealed over multiple turns measurably reduce both token efficiency and output quality.

I'm migrating a Node.js API from callback-based MongoDB driver calls to
the async/await Mongoose ODM. The codebase is in src/routes/ (14 files).
Constraints: keep the existing REST response shapes unchanged, don't
touch the test files, and flag any route where the migration changes
error-handling behavior. Work through the files in dependency order —
check imports first.

Ask for coverage, not judgment, in code review

A review prompt like "only report high-severity issues" is followed more literally by Opus 4.7/4.8 than by older models — which paradoxically can lower your measured recall, because Opus finds the bugs and then declines to report the low-severity ones you told it to skip. Separate finding from filtering:

Report every issue you find, including ones you're uncertain about or
consider low-severity. Don't filter for importance at this stage — a
separate pass will do that. For each finding, include your confidence
level and an estimated severity.

Grant autonomy on the small stuff

Opus 4.8 is more deliberate than 4.7 and will pause to ask about minor decisions — variable names, default values, which of two equivalent approaches to take — that it would previously just make. If that's not the interaction style you want:

For minor choices (naming, formatting, default values, choosing between
equivalent approaches), pick a reasonable option and note it rather than
asking. Still ask first for scope changes or destructive actions.

Don't over-specify design/frontend requests

Opus 4.7+ has a default visual house style (warm cream backgrounds, serif display type, terracotta accents) that shows up whenever a design brief is vague. Rather than fighting it with negative instructions ("don't use cream"), either give exact hex values and typefaces, or ask for options:

Before building, propose 4 distinct visual directions for this brief
(bg hex / accent hex / typeface, one-line rationale each). I'll pick
one, then implement only that direction.

Migrating existing Opus code without breaking it

If you have code written against Opus 4.5 or earlier, three changes will break it on 4.7/4.8:

1. thinking: {type: "enabled", budget_tokens: N} now 400s. Replace with thinking: {type: "adaptive"} plus output_config.effort.
2. temperature, top_p, and top_k are rejected outright. Remove them. If you relied on temperature=0 for determinism, note that it never guaranteed identical outputs anyway — use a lower effort level and tighter prompt instead.
3. Assistant-turn prefills return a 400. If you were prefilling the last assistant message to force JSON output, switch to output_config.format with a JSON schema instead:

# Before (breaks on Opus 4.6+)
messages=[
    {"role": "user", "content": "Extract the invoice total."},
    {"role": "assistant", "content": '{"total": '},
]

# After
response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=1024,
    output_config={"format": {"type": "json_schema", "schema": INVOICE_SCHEMA}},
    messages=[{"role": "user", "content": "Extract the invoice total."}],
)

Also worth knowing: the tokenizer changed with Opus 4.7 and produces roughly 1x-1.35x more tokens than Opus 4.6 for the same text if you're coming from an older model. Re-run count_tokens() on representative prompts before assuming your cost estimates still hold — don't apply a blanket multiplier.

Cost control without downgrading quality

Opus at $5/$25 per million tokens adds up fast on high-volume workloads. Three levers that don't require switching models:

• Prompt caching. A large system prompt or repeated context (a codebase summary, a style guide) can be cached — cached reads cost roughly a tenth of the base input price. The catch is that caching is a strict prefix match: any byte change anywhere upstream of your cache breakpoint invalidates everything after it, so keep timestamps and session IDs out of the system prompt.
• Effort tuning per route, not globally. Run your hardest agentic tasks at xhigh, routine subagent calls at medium or low. Don't set one global effort level for an entire application.
• Route by task, not by product. A single application can call Sonnet for 90% of requests and only escalate to Opus for the subset flagged as complex — a triage step (even a cheap Haiku classifier) deciding which model handles which request is often the single highest-leverage cost optimization available.

For a broader look at how Claude's pricing stacks up against competitors, see AI model pricing compared, and for the mechanics of prompt caching in more depth, see prompt caching guide.

How this fits into a coding workflow

Opus is the model, not the workflow. If you're doing agentic coding — letting the model read, edit, run, and iterate over a codebase rather than one-shot completions — the harness matters as much as the model choice. Claude Code is Anthropic's own CLI harness and defaults to Opus-tier reasoning for hard tasks; see Claude Code for business if you're evaluating it for a non-technical team, or Claude Code vs Cursor if you're comparing it against an IDE-integrated alternative. Whichever harness you choose, the effort-level and prompting guidance above applies unchanged — it's a property of the model, not the tool wrapping it.

If you're deciding between Opus and GPT-tier models for a coding-heavy pipeline, the comparison in GPT vs Claude for coding covers the practical differences beyond raw benchmark scores. And if none of this is worth the API integration overhead for your team yet, vibe coding: when to use it covers the lower-friction on-ramp.

FAQ

Is Claude Opus 4 worth the extra cost over Sonnet?

For most day-to-day coding tasks, no — Sonnet handles well-scoped work at roughly 60% of Opus's price with comparable quality. Opus earns its cost on long-horizon agentic work, ambiguous specs, and deep code review, where its judgment and coherence over many steps produce measurably fewer errors. Route by task complexity rather than defaulting to one model everywhere.

What's the difference between Opus 4.6, 4.7, and 4.8?

They share the same request API surface (adaptive thinking only, no sampling parameters, no assistant prefill), so migrating between them is mostly a model-ID swap. The practical differences are behavioral: 4.7 tokenizes text differently (more tokens for the same input than 4.6), and 4.8 is warmer in tone, more autonomous on long tasks, but also more likely to pause and ask about minor decisions than 4.7. Unless you have a reason to pin an older version, use the current one, claude-opus-4-8.

Does Claude Opus 4 support a fixed thinking budget in tokens?

No, not on current versions. budget_tokens was deprecated on Opus 4.6 and is rejected outright with a 400 error on Opus 4.7 and 4.8. Use adaptive thinking (thinking: {type: "adaptive"}) combined with an effort level (low through max) instead — effort controls depth and cost, and the model decides how much to actually think per request.

How big is the context window on Opus 4?

1 million tokens across the current Opus 4.x line (4.6, 4.7, 4.8), at standard API pricing with no long-context premium. Maximum output per request is 128,000 tokens, but you need to use streaming for anything above roughly 16,000 output tokens to avoid client-side HTTP timeouts.

Can I use Opus 4 for a chatbot on my website?

You can, but it's usually the wrong tool. A customer-facing chatbot answering FAQs or routing inquiries rarely needs multi-step reasoning — Sonnet or even Haiku will answer just as well at a fraction of the cost and lower latency. Reserve Opus for the harder tail: complex troubleshooting flows, or backend agents doing multi-step work the user never directly waits on.

Talk to us

If you're deciding which Claude model fits your product or want help wiring up a cost-effective routing strategy between Opus, Sonnet, and Haiku, we do this for a living. Book a free 30-minute call through the contact form or reach us directly on WhatsApp.

Sources

• Claude models overview — current model IDs, context windows, and pricing
• Extended thinking documentation — adaptive thinking and effort parameters
• Anthropic pricing — per-model token pricing
• Model migration guide — breaking changes between Opus versions
• Anthropic API status — service status and incident history