Claude Opus 5 Explained: Effort, Context, and Cost for Engineers

Anthropic shipped Claude Opus 5 on July 24, 2026, and the framing is unusual for a model launch. Anthropic isn't claiming it's the smartest model they've built — that's still Claude Fable 5.

Instead, Opus 5 is pitched as the model you should default to for most day-to-day engineering work: coding, agentic tool use, and long-running enterprise tasks, at roughly half of Fable 5's per-token price and the same price as its own predecessor, Opus 4.8.

That's the marketing pitch. Strip it away and the engineering story gets more interesting — it's the part most launch posts skip.

Opus 5 changes how you control cost and capability through a single parameter, flips a default that will silently break existing max_tokens budgets, and ships two new mechanisms for keeping your prompt cache alive across longer sessions. This post walks through all of it: what changed at the API level, why it changed, and how to build against it without re-learning Opus 5's behavior in production.

What Actually Shipped on July 24

The model itself is straightforward to reference:

Under the hood, three specs define most of what changes for you as a caller: a 1M-token context window that is both the default and the maximum (there's no smaller variant to opt out into), a 128k max output token ceiling per request, and thinking turned on by default. Pricing is unchanged from Opus 4.8: $5 per million input tokens and $25 per million output tokens.

Anthropic describes Opus 5 as a step-change over Opus 4.8 rather than an incremental bump, with the largest reported gains in deep reasoning, agentic and long-horizon tasks, and test-time compute scaling — meaning the model converts additional inference-time compute into measurably better output more reliably than earlier Opus versions did.

On Anthropic's own Frontier-Bench v0.1 and GDPval-AA evaluations, they report Opus 5 as their new state of the art among generally available models, trailing only Mythos 5 on cybersecurity-specific tasks. Treat those numbers as vendor-reported until you've run your own evals — which, if you're migrating a production workload, you should do regardless of what any benchmark says.

There's a methodological wrinkle worth knowing before you cite the Frontier-Bench number specifically: Anthropic's own footnote for that chart states Opus 4.8 served as the fallback whenever a safety classifier refused a request from Opus 5 or Fable 5 during the eval run. Part of both models' reported scores therefore reflects an older model finishing some of the tasks, not a clean single-model result — a direct consequence of the same fallback mechanism covered later in this post.

The part that actually changes your integration code is the effort parameter, and that's worth its own section.

The Effort Parameter: One Knob for Cost and Capability

Most model providers give you separate levers for "how much should the model think" and "how verbose should the output be" and "how many tool calls should it make." Anthropic collapsed all three into one parameter on Opus 5: output_config.effort.

This matters architecturally, not just ergonomically. Effort affects every token category in the response — thinking, tool-call arguments, and the visible text — as a single coordinated setting. Instead of reasoning about three independent cost dimensions, you reason about one dial.

Lower it, and Claude combines operations into fewer tool calls, skips pre-action narration, and gives terser confirmations. Raise it, and it explains its plan before acting, produces more thorough summaries, and calls tools more liberally when the task warrants it.

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const response = await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  messages: [
    {
      role: "user",
      content:
        "Analyze the trade-offs between microservices and monolithic architectures for a 12-person team.",
    },
  ],
  output_config: { effort: "medium" },
});

for (const block of response.content) {
  if (block.type === "text") {
    console.log(block.text);
  }
}

Five levels are available on Opus 5:

Setting effort to "high" produces exactly the same behavior as leaving the field out entirely — that's the documented default, not an assumption you need to verify empirically.

Here's the detail that trips people up: effort is a behavioral signal, not a hard budget. At low effort, Claude will still think through a genuinely hard problem — it just thinks less than it would at high for that same problem.

If you need an actual ceiling on token spend, pair effort with max_tokens (or the beta task-budgets feature) rather than assuming a low effort setting caps anything by itself.

Anthropic's own guidance for Opus 5 specifically is to start at high, then run an effort sweep against your evals: step down to low or medium wherever quality holds, and reserve xhigh or max for work that has demonstrated headroom at those levels.

If you're carrying effort settings over from Opus 4.7 or 4.8, don't reuse them blindly — Opus 5 responds more decisively to effort changes than earlier Opus models, so a setting tuned for 4.8's behavior may over- or under-shoot on 5.

Thinking On by Default: The Breaking Change Hiding in Plain Sight

This is the change most likely to bite you silently during migration.

On Claude Opus 4.8, a request runs without thinking unless you explicitly set thinking: {"type": "adaptive"}. On Opus 5, the same request runs with thinking on: the model decides when and how much to think on each turn, and effort is your control over how deep that thinking goes.

The wire-level value hasn't changed — thinking: {"type": "adaptive"} still works and is now equivalent to doing nothing — but the default flipped underneath you.

Why make this change at all? Because the capability gains Anthropic is claiming for Opus 5 — deep reasoning, long-horizon agentic work, test-time compute scaling — depend on the model actually using inference-time compute. Shipping a step-change reasoning model with reasoning off by default would undercut the entire premise of the release.

The practical consequence: max_tokens is a hard ceiling on total output, thinking plus visible response combined. If you had a workload running on Opus 4.8 with max_tokens sized only for response text — because thinking was off and didn't need budget — that same max_tokens value can now truncate Opus 5 mid-thought.

// Opus 4.8: thinking is off by default, so max_tokens only needs to
// cover the visible response.
const before = await anthropic.messages.create({
  model: "claude-opus-4-8",
  max_tokens: 2048,
  messages: [{ role: "user", content: "Summarize this incident report." }],
});

// Opus 5: thinking is on by default, so max_tokens must cover thinking
// tokens too. Reusing 2048 here risks truncation before the model
// finishes reasoning. Bump it, and go generous at xhigh/max.
const after = await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 8192,
  messages: [{ role: "user", content: "Summarize this incident report." }],
});

The second gotcha is a genuine breaking change, not just a tuning issue: on Opus 5, thinking: {"type": "disabled"} is only accepted when effort is high or below. Setting it alongside xhigh or max effort returns a 400 error.

// Valid — effort at or below "high" permits disabling thinking.
await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  thinking: { type: "disabled" },
  output_config: { effort: "medium" },
  messages: [{ role: "user", content: "Classify this support ticket." }],
});

// Invalid — throws a 400. xhigh/max effort requires thinking to stay on.
await anthropic.messages.create({
  model: "claude-opus-5",
  max_tokens: 64000,
  thinking: { type: "disabled" },
  output_config: { effort: "xhigh" },
  messages: [{ role: "user", content: "Refactor the billing module." }],
});

On Opus 4.8, disabling thinking was independent of effort level. On Opus 5, it isn't. If your integration disables thinking at high effort levels today, you have two options going forward: keep thinking disabled and cap effort at high, or drop the thinking field and let the model reason.

One more integration detail worth knowing before you reach for thinking: {"type": "disabled"} as a cost-saving move: with thinking off, Opus 5 can occasionally write a tool call into its visible text instead of emitting a proper tool_use block, or leak internal XML tags into the response. Where you have the choice, prefer lowering effort over disabling thinking outright — you get the token savings without the parsing edge cases.

Context Window and Output Budgets

Opus 5 has a 1M-token context window that is simultaneously the default and the maximum — there's no smaller base window and no beta header to opt into a larger one. That's a genuine simplification if you've previously had to branch your client code around a context-1m-2025-08-07-style beta flag depending on which model you were calling. With Opus 5, one context-length code path covers every request.

Max output per request on the synchronous Messages API is 128k tokens. If you're running bulk workloads through the Message Batches API, Opus 5 supports up to 300k output tokens per item with the output-300k-2026-03-24 beta header — the same header used for Opus 4.8, 4.7, 4.6, and both current Sonnet models.

The practical guidance from Anthropic, and it's worth taking seriously: when you run Opus 5 at xhigh or max effort, set a large max_tokens — starting around 64k and tuning from there — so the model has room to think and act across subagent calls and tool loops without hitting the ceiling mid-task.

Prompt Caching and Cache-Safe Mid-Conversation Changes

Prompt caching hashes your request prefix in a fixed order: tools, then system, then messages. A cache hit requires that prefix to match a prior request byte-for-byte up to the cache breakpoint.

Miss anywhere in that chain, and everything downstream reprocesses at full input-token price — a cache hit is effectively O(1) against the cached span, a miss is O(n) against however much of the prefix changed.

That ordering is why editing your top-level system field mid-session is expensive: it sits near the very front of the hashed prefix, so appending even one sentence invalidates the cache for the system prompt and every cached message that follows it.

The existing fix, available on several current models including Opus 4.8, is to append a message with "role": "system" at the point in the conversation where the new instruction becomes relevant, instead of editing the top-level field. Everything before that point stays byte-identical, so the cache still hits.

flowchart LR
    subgraph prefix["Cached prefix (unchanged)"]
        T[tools] --> S[system]
        S --> M["messages 1..n"]
    end
    M --> MS["role: system — appended mid-conversation"]
    MS --> MN["later turns, now part of the stable history"]

A mid-conversation system message must immediately follow a user turn — including one carrying tool_result blocks — and either end the array or be followed by an assistant turn.

That placement rule matters for agentic loops specifically: it means you can drop an operator-level fact in right after a tool result and before Claude's next turn, which is exactly where you'd want to relay something like "the remaining token budget just dropped below threshold" without derailing the turn in progress.

// Example shape for a mid-conversation instruction inserted after a
// tool result, so the cached prefix before it is untouched.
const messages = [
  { role: "user", content: "Run the test suite and fix any failures." },
  {
    role: "assistant",
    content: [{ type: "tool_use", id: "toolu_01", name: "run_tests", input: {} }],
  },
  {
    role: "user",
    content: [
      { type: "tool_result", tool_use_id: "toolu_01", content: "12 passed, 0 failed" },
    ],
  },
  {
    role: "system",
    content: "From now on, every suggestion must include explicit type annotations.",
  },
];

Phrase mid-conversation system content as a stated fact ("the user sent this while you were working," "the budget is now X"), not as a command that overrides the user — Claude is trained to resist instructions that read as working against the end user, and that resistance applies to the system role too.

New with this release: mid-conversation tool changes, in beta behind the mid-conversation-tool-changes-2026-07-01 header. It applies the same idea to your tools array — you can add or remove tools between turns without resending (and re-hashing) the full tool list for the life of the session.

Think of an agent that only gets access to a deploy tool after its tests pass: previously, changing the available tool list meant eating a cache miss on the entire prefix from that point forward. This closes that gap.

The exact request shape is still settling as the feature is in beta, so check the current docs before wiring it into a critical path — but the mechanism it's solving for is the same cache-preservation problem as mid-conversation system messages, just applied to tool availability instead of instructions.

One more win worth flagging: the minimum cacheable prompt length on Opus 5 dropped to 512 tokens, down from 1,024 on Opus 4.8. If you run a lot of short, high-frequency requests — subagent calls, classification passes — some of those now become cacheable that simply couldn't be cached before.

Safety Classifiers and the Fallback Mechanism

Anthropic's frontier-tier models run safety classifiers that can decline a request outright. When that happens, you get a normal HTTP 200 response with stop_reason: "refusal" — not an exception, not a 4xx error.

That's a deliberate design choice: it keeps refusals out of your error-handling and retry-on-failure code paths, where they'd otherwise get silently retried against the same model and refuse again.

Billing follows the same 200-response logic: a refusal that arrives before any output isn't charged, even though token counts still appear in usage. A refusal that happens mid-stream bills the input tokens plus whatever output already streamed.

Opus 5's own classifier posture is notably looser than Fable 5's. Anthropic reports expecting roughly 85% fewer classifier interventions on Opus 5 compared to Fable 5. Its cyber classifiers block binary-based vulnerability scanning, penetration testing, and exploit generation, but allow source-code vulnerability discovery to proceed.

Flagged requests fall back to Opus 4.8 by default inside Claude.ai, Claude Code, and Claude Cowork, and you can wire the same fallback into your own API calls. Teams doing legitimate offensive-security work can apply for Anthropic's Cyber Verification Program to get a version of Opus 5 with fewer restrictions.

On the biology side, requests that Fable 5 would have blocked now route to Opus 5 instead of Opus 4.8, reflecting Opus 5's position as Anthropic's strongest generally available model for scientific research.

const response = await anthropic.beta.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  messages: [{ role: "user", content: userPrompt }],
  fallbacks: [{ model: "claude-opus-4-8" }],
  betas: ["server-side-fallback-2026-07-01"],
});

// A fallback_message entry in usage.iterations means a fallback model
// ran; pair it with stop_reason to confirm it actually served the reply.
const fallbackRan = response.usage.iterations?.some(
  (i) => i.type === "fallback_message",
);
const servedByFallback = fallbackRan && response.stop_reason !== "refusal";

fallbacks accepts up to three models tried in order, and each entry must be a permitted fallback target for the model you called — that list is published per-model on the Models API.

A fallback only fires on a safety-classifier decline; a rate limit, overload, or server error on the primary model comes back to you unmodified, so your existing retry logic for those cases doesn't change.

flowchart TD
    A[Request to claude-opus-5] --> B{Classifier check}
    B -->|Clear| C[Model reasons, calls tools, responds]
    B -->|Flagged| D["stop_reason: refusal, category set"]
    D --> E{fallbacks configured?}
    E -->|Yes| F[Next model in chain runs on the same request]
    E -->|No| G[Empty content returned to caller]
    F --> H[Response reports the model that actually answered]
    C --> I[stop_reason: end_turn / tool_use / max_tokens]
    H --> I

Two pitfalls worth calling out explicitly: fallback configuration on a top-level request does not propagate into model calls your tools make internally, so subagent invocations need their own fallback setup.

And because a refusal is a 200, not a 5xx, dashboards built purely on HTTP error rates never see it — emit a dedicated event per refusal and per fallback-served response if you want visibility into how often your traffic is hitting classifiers.

Claude Opus 5 vs. the Rest of the Family

Pick Opus 5 as your default for coding agents, code review, document and spreadsheet generation, and enterprise workflows where near-frontier quality at half of Fable 5's price is the right trade — and note that on Frontier-Bench v0.1 and GDPval-AA specifically, Anthropic reports Opus 5 actually leading Fable 5, not just approaching it.

Reach for Fable 5 when a task genuinely needs the highest general-capability ceiling Anthropic offers — particularly cybersecurity and biology work — and you can handle classifier refusals as a normal response type in your integration.

Sonnet 5 is worth benchmarking against Opus 5 for high-volume, latency-sensitive pipelines — Anthropic positions it as landing close to Opus 4.8 on agentic work at a meaningfully lower price, so for some workloads it may be the better cost-performance point even against Opus 5.

Keep Opus 4.8 in your model roster even after migrating, since it's the documented fallback target when Opus 5's own classifiers fire. Full, current rate cards for every tier live on Anthropic's pricing page.

Best Practices

• Start every workload at effort: "high" (the default) and run an evaluation sweep before stepping down — don't guess at the right level.

• Hold effort constant within a single cached, multi-turn conversation. Vary it across workload types, not within one session, since changing it invalidates the cached prefix.

• Size max_tokens for thinking plus response, not response alone, especially if you're migrating a workload that ran with thinking off on Opus 4.8.

• Go generous with max_tokens — 64k as a starting point — whenever you run xhigh or max effort.

• Configure fallback on every code path that calls the model, including retry handlers and subagent invocations, since it doesn't propagate automatically.

• Prefer lowering effort over disabling thinking when you need cheaper responses; disabling thinking has real parsing edge cases at high effort levels.

• Use mid-conversation system messages (and, once stable, mid-conversation tool changes) for anything you discover mid-session, instead of editing the top-level system or tools fields.

Common Mistakes

• Treating effort as a token ceiling. It's a behavioral signal — Claude still reasons through hard problems at low effort, just less than at high. Pair it with max_tokens for an actual cap.

• Reusing Opus 4.7/4.8 effort presets on Opus 5 without re-testing. Opus 5 responds more decisively to effort changes, so old presets may over- or under-shoot.

• Assuming thinking can always be disabled. It can't at xhigh or max effort on Opus 5 — that combination returns a 400.

• Carrying over a max_tokens value sized for a thinking-off Opus 4.8 workload. Thinking is on by default now, and it shares the same budget as the visible response.

• Editing the top-level system field for a mid-session instruction. It quietly kills your cache hit rate for everything downstream; use a mid-conversation system message instead.

• Handling a refusal in exception-handling code. It's a normal 200 response with stop_reason: "refusal" — check the field, don't wrap the call in a try/catch expecting an error.

• Forgetting that fallback config doesn't reach into tool-triggered model calls. Subagents need their own fallbacks setup.

Performance Considerations

The effort ladder is your primary lever for cost and latency — reach for low or medium before considering a smaller model entirely, since Anthropic's benchmarks show Opus 5 holding strong quality at lower effort levels relative to its own higher settings.

Changing effort between requests in the same session breaks prompt caching, because effort shapes the rendered prompt. If a long agentic session relies on cache hits, pick one effort level at the start and keep it there for the life of that session.

A 1M-token context window doesn't make long context free. Uncached input still bills at full input-token rates on every request that includes it. For repeated large context — a repository, a document corpus, a long system prompt — enable caching explicitly (it's opt-in via cache_control) rather than assuming a large context window implies cheap reuse.

Fast mode is a genuine trade-off, not a free win: it's a research preview available for Opus 5 on the Claude API only (not Bedrock, Google Cloud, or Microsoft Foundry), running at roughly 2.5x the default token throughput for twice the base price — $5/$25 becomes $10 input / $50 output. Reach for it on latency-bound user-facing paths, not on cost-bound batch jobs.

For bulk, asynchronous workloads — nightly runs, large evals — the Message Batches API with the output-300k-2026-03-24 beta header raises your per-item output ceiling to 300k tokens, which is the better fit than pushing a synchronous request past its 128k limit.

Security Considerations

Safety classifiers are a defense-in-depth layer on Anthropic's side, not a substitute for your own sandboxing. If you're giving Opus 5 access to bash, computer-use, or code-execution tools, you still own the blast radius of what those tools can actually do — the classifier governs what Claude will attempt to generate, not what your tool implementation is capable of executing.

Handle stop_reason: "refusal" explicitly rather than letting it fall through generic error handling. A category: "cyber" refusal retried unmodified against the same model will refuse again; route it to your configured fallback instead, and log the category for visibility into what your traffic is actually triggering.

If your product does legitimate security research that keeps tripping the cyber classifier, Anthropic's Cyber Verification Program exists specifically to reduce those restrictions for vetted enterprises and researchers — that's the intended path, rather than trying to prompt around the classifier.

Mid-conversation system messages carry operator-level authority: Claude treats system-role content as coming from you, the application, not the end user. Never place raw tool output, retrieved documents, or other untrusted content directly in a system message — that hands it the same trust level as your own instructions, which is a textbook prompt-injection vector. Keep that content in tool_result blocks, where it's treated as data rather than instruction.

Consistent with prior Opus models, Opus 5 carries no data retention requirement for general API access. That's a reasonable default for most integrations, but confirm the specifics against Anthropic's current data processing agreement and trust center documentation for your actual compliance posture rather than treating it as a blanket guarantee.

Worth noting for anyone weighing model choice partly on safety grounds: Anthropic's own automated behavioral audit scores Opus 5 as its best-aligned model released so far, reporting fewer instances of dishonest behavior and a lower success rate for attempts to manipulate it into misuse compared with its current lineup.

That's a first-party audit, not an independent third-party assessment, so weigh it accordingly — but it's a relevant data point if safety posture factors into your model selection. Anthropic publishes the full methodology in the Claude Opus 5 system card.

Real-World Example: A Production PR-Review Agent

Here's a shape that pulls several of the pieces above together: an agent that reviews a pull request, adjusts effort based on diff size, caches its system prompt and tool definitions, and falls back to Opus 4.8 if a classifier flags anything mid-review.

import Anthropic from "@anthropic-ai/sdk";

const anthropic = new Anthropic();

const REVIEW_TOOLS = [
  {
    name: "get_diff",
    description: "Fetch the unified diff for the pull request under review.",
    input_schema: {
      type: "object",
      properties: { pr_id: { type: "string" } },
      required: ["pr_id"],
    },
  },
  {
    name: "post_review_comment",
    description: "Post an inline comment on a specific file and line.",
    input_schema: {
      type: "object",
      properties: {
        file: { type: "string" },
        line: { type: "integer" },
        body: { type: "string" },
      },
      required: ["file", "line", "body"],
    },
  },
] as const;

const SYSTEM_PROMPT = `You are a senior code reviewer. Flag correctness bugs,
security issues, and missing tests. Skip style nits the linter already
catches. Be specific: cite the file and line for every comment.`;

async function reviewPullRequest(prId: string, diffSizeBytes: number) {
  // Larger diffs get more room to reason; small diffs stay cheap and fast.
  const effort = diffSizeBytes > 50_000 ? "xhigh" : "medium";

  const response = await anthropic.beta.messages.create({
    model: "claude-opus-5",
    max_tokens: effort === "xhigh" ? 64000 : 8192,
    // Automatic caching: the system prompt and tool definitions form a
    // stable prefix across every PR this process reviews, so only the
    // first call in a while pays full input-token price for them.
    cache_control: { type: "ephemeral" },
    system: SYSTEM_PROMPT,
    tools: REVIEW_TOOLS,
    output_config: { effort },
    messages: [
      {
        role: "user",
        content: `Review pull request ${prId}. Start by fetching the diff.`,
      },
    ],
    // If Opus 5's classifiers flag anything in the diff or the
    // generated comments, fall through to Opus 4.8 rather than
    // dropping the review entirely.
    fallbacks: [{ model: "claude-opus-4-8" }],
    betas: ["server-side-fallback-2026-07-01"],
  });

  if (response.stop_reason === "refusal") {
    // Every fallback in the chain also declined. Surface this distinctly
    // from a normal failure so it doesn't get silently retried.
    console.warn(`Review of ${prId} was declined:`, response.stop_details);
    return null;
  }

  return response;
}

A few things this example is doing deliberately. The effort level is decided per request based on diff size, not hardcoded — that's the primary cost lever, used before reaching for a cheaper model entirely.

cache_control is set explicitly, because caching on Opus 5 (like every current model) is opt-in, not automatic; without it, every PR review reprocesses the full system prompt and tool schema at full price. And the fallback chain means a classifier flag on a security-sensitive diff degrades to Opus 4.8 instead of failing the whole review pipeline — which matters if this runs unattended in CI.

In a real deployment you'd loop this around tool_use blocks until the model stops calling tools, and you'd insert a mid-conversation system message if, say, the diff turned out to exceed your token budget partway through — appended after the next tool result, not spliced into the top-level system field, so the cache built up over the loop survives.

FAQ

What is Claude Opus 5? It's Anthropic's newest Opus-tier model, released July 24, 2026, positioned as a near-frontier model for coding and enterprise work at half the price of Claude Fable 5, Anthropic's most capable generally available model.

How much does Claude Opus 5 cost? $5 per million input tokens and $25 per million output tokens — unchanged from Opus 4.8. Fast mode, a research preview available on the Claude API only, doubles both rates to $10/$50.

What's the difference between the effort parameter and thinking?thinking controls whether Claude reasons in visible thinking blocks before answering. effort controls how much total work goes into the whole response — thinking depth, tool-call count, and text length together. On Opus 5, effort is the primary control; thinking is on by default and mostly governed through effort rather than toggled directly.

Can I disable thinking on Claude Opus 5? Yes, but only when effort is high or below. Setting thinking: {"type": "disabled"} together with xhigh or max effort returns a 400 error — this is new behavior compared to Opus 4.8.

What's the context window size? 1M tokens, and it's both the default and the maximum — there's no smaller variant and no beta header required to reach it. Max output is 128k tokens per synchronous request, or up to 300k on the Batch API with a beta header.

How does Claude Opus 5 compare to Claude Fable 5? Fable 5 remains Anthropic's highest general-capability model, and Opus 5 is priced and positioned against it: close to Fable 5's frontier intelligence at half the cost. That framing undersells one detail — on specific coding and knowledge-work evaluations like Frontier-Bench v0.1 and GDPval-AA, Anthropic reports Opus 5 as the new leader, ahead of Fable 5 on those particular benchmarks.

Fable 5 still holds the edge on the hardest cybersecurity and biology work, and it ships with classifiers that can decline requests; Opus 5 triggers roughly 85% fewer of those interventions.

Is Claude Opus 5 available outside the Claude API? Yes — Amazon Bedrock (anthropic.claude-opus-5), Google Cloud (claude-opus-5), and Microsoft Foundry all support it. Fast mode, notably, does not extend to any of those three platforms yet.

How do I migrate from Opus 4.8 to Opus 5? Change the model string from claude-opus-4-8 to claude-opus-5, then check two things: whether your max_tokens values account for thinking now running by default, and whether you disable thinking at xhigh or max effort anywhere, which will start failing with a 400. Anthropic's migration guide walks through both checks in more detail.

Conclusion

The headline number — half of Fable 5's price at near-Fable-5 capability — is the easy part of this release to explain and the least useful part to build against blindly.

The parts that actually change your integration are structural: effort as a single unified cost dial, thinking flipped on by default with a real breaking change around disabling it, and two new mechanisms for keeping your prompt cache alive as sessions get longer and tool access changes mid-flight.

None of that requires a rewrite. It requires reading the migration notes before you swap the model string, sizing max_tokens for a model that thinks by default, and treating effort as the lever you reach for before you reach for a different model entirely.

Do that, and Opus 5 is a reasonable new default for the agentic and coding workloads most teams are already running on Opus-tier models — not because it's the smartest thing Anthropic has shipped, but because it's the one built to be used every day.

Key Takeaways

• Claude Opus 5 (claude-opus-5) costs $5/$25 per million input/output tokens — the same as Opus 4.8 — while Anthropic reports it leading Fable 5 on coding and knowledge-work evaluations specifically, even though Fable 5 remains the higher general-capability model.

• The output_config.effort parameter is a single dial (low to max) that governs thinking, tool calls, and text together; it's a behavioral signal, not a hard token budget.

• Thinking runs on by default on Opus 5, unlike Opus 4.8 — revisit max_tokens on any migrated workload, since it's now a ceiling on thinking plus response combined.

• thinking: {"type": "disabled"} only works at high effort or below; combining it with xhigh or max returns a 400.

• The context window is a flat 1M tokens (default and max), with 128k max output synchronously or 300k on the Batch API via a beta header.

• Refusals are normal 200 responses with stop_reason: "refusal", not errors — configure fallbacks explicitly, including for subagent calls, since it doesn't propagate automatically.

• Mid-conversation system messages, and the new mid-conversation tool-changes beta, let you add instructions or tools partway through a session without invalidating your prompt cache.

• Keep Opus 4.8 in your model roster: it's the documented fallback target when Opus 5's own safety classifiers flag a request.