Claude Opus 5 on Run BiOS

What's new in Claude Opus 5

Overview of new features and behavior changes in Claude Opus 5.

---

Claude Opus 5 is a step-change improvement over Claude Opus 4.8, with the largest gains in deep reasoning, agentic and long-horizon tasks, and test-time compute scaling. This page summarizes everything new in Claude Opus 5, including thinking on by default, mid-conversation tool changes, and a breaking change to when thinking can be disabled.

New model

Model	API model ID	Description
Claude Opus 5	claude-opus-5	For complex agentic coding and enterprise work

Claude Opus 5 has a 1M token context window (1M tokens is both the default and the maximum; there is no smaller context variant), 128k max output tokens, and thinking on by default.

For complete pricing and specs, see the models overview.

New features

Mid-conversation tool changes (beta)

You can add or remove tools between turns of a conversation while preserving the prompt cache, instead of resending a fixed tool list for the life of a session. Mid-conversation tool changes are in beta: include the mid-conversation-tool-changes-2026-07-01 beta header in your requests. See Mid-conversation tool changes for usage.

Default fallbacks mode

The fallbacks parameter supports a new "default" mode, which applies Anthropic's recommended fallback models by refusal category instead of a model list you maintain yourself. The entire fallbacks parameter is in beta. Use the server-side-fallback-2026-07-01 beta header, which supports both the "default" mode and explicit model lists (the earlier server-side-fallback-2026-06-01 header accepts only explicit lists). See Refusals and fallback.

Lower prompt cache minimum

The minimum cacheable prompt length on Claude Opus 5 is 512 tokens, down from 1,024 tokens on Claude Opus 4.8. Prompts that were too short to cache on Claude Opus 4.8 can now create cache entries with no code changes. See Prompt caching for per-model minimums.

Fast mode

Fast mode (research preview) is available for Claude Opus 5 on the Claude API only; it is not currently available on Amazon Bedrock, Google Cloud, or Microsoft Foundry. Fast mode for Claude Opus 5 is priced at $10 per million input tokens and $50 per million output tokens. See Fast mode for access, supported models, and pricing.

Behavior changes

Thinking on by default

On Claude Opus 4.8, requests run without thinking unless you set thinking: {"type": "adaptive"}. On Claude Opus 5, the same requests run with thinking on: the model decides when and how much to think on each turn, and the effort parameter is the control for thinking depth. The wire value is unchanged; thinking: {"type": "adaptive"} remains valid and equivalent to the default.

Because max_tokens is a hard limit on total output (thinking plus response text), revisit it for workloads that ran without thinking on Claude Opus 4.8.

The API keeps the option to disable thinking, subject to the effort restriction below.

Effort matters more

Claude Opus 5 converts additional effort into better results more reliably than any earlier Opus model, so the effort level you choose carries more weight. The full ladder is available: low, medium, high, xhigh, and max, with max as the top tier for the deepest possible reasoning. Start at the default, high, and adjust in either direction based on your evals: step down where quality holds to save tokens and latency, or step up for the most demanding work. When running at xhigh or max effort, set a large max_tokens so the model has room to think and act across subagents and tool calls.

This request turns effort all the way up to max:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 64000,
    "stream": true,
    "output_config": {
      "effort": "max"
    },
    "messages": [
      {
        "role": "user",
        "content": "Explain why the sum of two even numbers is always even."
      }
    ]
  }'

# 64k max_tokens can run past the non-streaming time limit; stream the events.
ant messages create --stream --format jsonl <<'YAML'
model: claude-opus-5
max_tokens: 64000
output_config:
  effort: max
messages:
  - role: user
    content: Explain why the sum of two even numbers is always even.
YAML

client = anthropic.Anthropic()

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "max"},
    messages=[
        {
            "role": "user",
            "content": "Explain why the sum of two even numbers is always even.",
        }
    ],
) as stream:
    response = stream.get_final_message()

print(response)

const client = new Anthropic();

const stream = client.messages.stream({
  model: "claude-opus-5",
  max_tokens: 64000,
  output_config: {
    effort: "max"
  },
  messages: [
    {
      role: "user",
      content: "Explain why the sum of two even numbers is always even."
    }
  ]
});

const response = await stream.finalMessage();
console.log(response);

AnthropicClient client = new();

var parameters = new MessageCreateParams
{
    Model = Model.ClaudeOpus5,
    MaxTokens = 64000,
    OutputConfig = new OutputConfig
    {
        Effort = Effort.Max
    },
    Messages = [new() { Role = Role.User, Content = "Explain why the sum of two even numbers is always even." }]
};

var response = await client.Messages.CreateStreaming(parameters).Aggregate();
Console.WriteLine(response);

client := anthropic.NewClient()

stream := client.Messages.NewStreaming(context.TODO(), anthropic.MessageNewParams{
	Model:     anthropic.ModelClaudeOpus5,
	MaxTokens: 64000,
	OutputConfig: anthropic.OutputConfigParam{
		Effort: anthropic.OutputConfigEffortMax,
	},
	Messages: []anthropic.MessageParam{
		anthropic.NewUserMessage(anthropic.NewTextBlock("Explain why the sum of two even numbers is always even.")),
	},
})

response := anthropic.Message{}
for stream.Next() {
	event := stream.Current()
	if err := response.Accumulate(event); err != nil {
		log.Fatal(err)
	}
}
if err := stream.Err(); err != nil {
	log.Fatal(err)
}

fmt.Println(response)

AnthropicClient client = AnthropicOkHttpClient.fromEnv();

MessageCreateParams params = MessageCreateParams.builder()
    .model(Model.CLAUDE_OPUS_5)
    .maxTokens(64000L)
    .outputConfig(OutputConfig.builder()
        .effort(OutputConfig.Effort.MAX)
        .build())
    .addUserMessage("Explain why the sum of two even numbers is always even.")
    .build();

MessageAccumulator accumulator = MessageAccumulator.create();
try (var streamResponse = client.messages().createStreaming(params)) {
    streamResponse.stream().forEach(accumulator::accumulate);
}

Message response = accumulator.message();
IO.println(response);

$client = new Client();

$stream = $client->messages->createStream(
    maxTokens: 64000,
    messages: [
        ['role' => 'user', 'content' => 'Explain why the sum of two even numbers is always even.']
    ],
    model: Model::CLAUDE_OPUS_5,
    outputConfig: ['effort' => Effort::MAX],
);

$accumulator = MessageAccumulator::forMessages();
foreach ($stream as $event) {
    $accumulator->accumulate($event);
}

echo $accumulator->message();

client = Anthropic::Client.new

response = client.messages.stream(
  model: Anthropic::Model::CLAUDE_OPUS_5,
  max_tokens: 64000,
  output_config: {
    effort: :max
  },
  messages: [
    { role: "user", content: "Explain why the sum of two even numbers is always even." }
  ]
).accumulated_message

puts response

Thinking is on by default on Claude Opus 5, so no thinking field is needed.

Disabling thinking requires effort high or below

On Claude Opus 5, thinking: {"type": "disabled"} is accepted only when the effort level is high or below. Setting thinking: {"type": "disabled"} with effort xhigh or max returns a 400 error. This is generally available behavior on Claude Opus 5 onward, enforced on each request, and it is a breaking change from Claude Opus 4.8, where disabling thinking was independent of the effort level. If you disable thinking at high effort levels today, either keep thinking disabled and set effort to high or below, or keep the effort level and remove the thinking field.

With thinking disabled, Claude Opus 5 can occasionally write a tool call into its text output instead of emitting a tool_use block, or include internal XML tags in its visible response. Where possible, keep thinking enabled and control token cost with lower effort levels; for integrations that must keep thinking disabled, see Running with thinking disabled for prompting mitigations.

Model behavior differences

Beyond the API changes above, Claude Opus 5 behaves differently from Claude Opus 4.8 in ways you may notice without changing any code. Default user-facing responses and written deliverables run longer. In agentic sessions, the model narrates its progress to the user more often. In multi-agent frameworks, it delegates to subagents more readily. It also verifies its own work without being told to, so remove verification instructions carried over from earlier models ("include a final verification step," "use a subagent to verify"); they cause over-verification on Claude Opus 5. For prompting patterns that tune each of these behaviors, see Prompting Claude Opus 5.

Capability improvements

Compared with Claude Opus 4.8, Claude Opus 5 is a step-change improvement rather than an incremental one, and it delivers frontier intelligence at half the cost of Claude Fable 5. The largest gains are in:

• Deep reasoning, sustaining multistep analysis across long problem chains.
• Agentic coding and long-horizon tasks, staying on task across extended tool-use loops and completing multi-file features, larger refactors, and end-to-end feature work without leaving stubs or placeholders.
• Test-time compute scaling, converting additional effort (up to the max level) into better results.
• Efficiency at lower effort levels, with low and medium effort producing strong quality at a fraction of the tokens and latency of higher settings.
• Code review and bug-finding, surfacing real bugs at a high rate per pass with few false positives, and staying accurate at lower effort levels.
• Vision, understanding charts, documents, and diagrams and replicating UI and frontend visuals, strongest when given tools to iteratively analyze, crop, and verify its work.
• Long-context work, with a 1M token context window as both the default and the maximum, and consistent instruction following, tool calling, and reasoning throughout the window.
• Office and document tasks, generating and editing complex multi-sheet spreadsheets with non-trivial formulas, and producing well-structured slide decks.
• Multi-agent coordination, running teams of subagents with effective writer-verifier patterns and few cases of agents overwriting each other's work.

For the prompting patterns that get the most out of these capabilities, see Prompting Claude Opus 5.

Pricing

Claude Opus 5 is priced at $5 per million input tokens and $25 per million output tokens, unchanged from Claude Opus 4.8.

See Pricing for complete pricing, including batch processing, prompt caching, and fast mode rates.

Availability

Claude Opus 5 is available on:

• Claude API: available to all customers, as claude-opus-5.
• AWS: available through Claude in Amazon Bedrock, as anthropic.claude-opus-5. Claude Opus 5 is also reachable through the InvokeModel API on bedrock-runtime, served by the same infrastructure; the Claude on Amazon Bedrock (legacy) integration does not include it in its ARN-versioned model ID table.
• Google Cloud: available through Claude on Google Cloud, as claude-opus-5.
• Microsoft Foundry: available through Claude in Microsoft Foundry.

Claude Opus 4.8 remains available on all of these platforms.

Migration guide

To migrate from Claude Opus 4.8, update your model ID:

model = "claude-opus-4-8"  # Before
model = "claude-opus-5"  # After

let model = "claude-opus-4-8"; // Before
model = "claude-opus-5"; // After

var model = Model.ClaudeOpus4_8; // Before
model = Model.ClaudeOpus5; // After

model := anthropic.ModelClaudeOpus4_8 // Before
model = anthropic.ModelClaudeOpus5    // After

Model model = Model.CLAUDE_OPUS_4_8; // Before
model = Model.CLAUDE_OPUS_5; // After

$model = Model::CLAUDE_OPUS_4_8; // Before
$model = Model::CLAUDE_OPUS_5; // After

model = Anthropic::Model::CLAUDE_OPUS_4_8 # Before
model = Anthropic::Model::CLAUDE_OPUS_5 # After

Then review the two behavior changes: thinking is on by default, and disabling thinking with effort xhigh or max returns a 400 error. See the migration guide for step-by-step instructions.

Next steps

Complete specs and pricing for all current Claude models.

Behavioral differences and prompting patterns specific to Claude Opus 5.

Control how many tokens Claude uses when responding, from low to max.

How thinking works when it's on by default, and when it can be disabled.

Give Claude an advisory token budget to pace its work against.

Guide for migrating to the latest Claude models from previous Claude versions.

Get higher output tokens per second from Claude Opus models at premium pricing.

Prompting Claude Opus 5

Behavioral differences and prompting patterns for Claude Opus 5, covering response verbosity, agentic narration, task scoping, subagent delegation, self-correction, and output artifacts when thinking is disabled.

---

This guide covers the prompting patterns specific to Claude Opus 5. For the model's capabilities and API changes, see What's new in Claude Opus 5. For techniques that apply across all current Claude models, see Prompting best practices.

Claude Opus 5 is built for complex agentic coding and enterprise work, with particular strengths in long-horizon agentic tasks. It performs well out of the box on existing Claude Opus 4.8 prompts. The following patterns cover the behaviors that most often require tuning.

For API changes when migrating from Claude Opus 4.8 (thinking on by default, and disabling thinking capped at high effort), see the migration guide.

Capability improvements

Compared with Claude Opus 4.8, the improvements most relevant to prompting are:

• Agentic coding: Claude Opus 5 is strongest on difficult coding tasks: multi-file features, larger refactors, and end-to-end feature work. It completes full tasks rather than leaving stubs or placeholders, and it performs best when given the complete task specification up front and left to run. It also performs well on easier tasks like single-turn edits, where the difference from prior models is smaller.
• Code review and bug-finding: Claude Opus 5 reviews code with high precision and recall: it finds real bugs at a high rate per pass, and its additional findings are mostly real issues rather than false positives. Accuracy holds at lower effort settings, which supports a fast pass at review time and a more thorough pass later. If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead.
• Efficiency at lower effort: low and medium effort produce strong quality at a fraction of the tokens and latency of higher settings. Start with the default (high) and adjust based on your evals: use low and medium liberally as your primary control for token cost and response time wherever quality holds, and step up to xhigh for demanding coding and agentic work. If you carried effort defaults over from a prior model, re-run an effort sweep on your own evals. See Effort for the full recommendations.
• Vision: Claude Opus 5 is strong on chart, document, and diagram understanding, and on UI and frontend visual replication. Re-validate any prompt-side vision workarounds you tuned for prior models; they may no longer be needed. Vision performance is strongest when the model has tools to iteratively analyze, crop, and visually verify its work, and tool use is a more cost-effective lever than thinking alone.
• Long-context work: Claude Opus 5 has a 1M token context window as both the default and the maximum, and its instruction following, tool calling, and reasoning stay consistent throughout the window.
• Office and document tasks: Claude Opus 5 generates and works with complex, multi-sheet spreadsheets with non-trivial formulas, and it produces well-structured slide decks. Prompt it with any specific styles or templates it needs to follow.
• Multi-agent coordination: Claude Opus 5 coordinates teams of subagents well, with effective writer-verifier patterns and few cases of agents overwriting each other's work. For cost-sensitive workloads, cap delegation; see Controlling subagent spawning.

Response length and verbosity

Claude Opus 5's default user-facing responses run longer than prior Opus models'. The effort parameter controls how much the model thinks rather than how much it says: lowering effort can reduce thinking volume without reliably shortening the visible response. To control response length, prompt for it explicitly.

A short conciseness instruction is effective. For example, for a user-facing multi-turn product:

Keep responses focused, brief, and concise. Keep disclaimers and caveats short, and spend most of the response on the main answer. When asked to explain something, give a high-level summary unless an in-depth explanation is specifically requested.

In a long system prompt, pair the instruction with a short reminder near the end of the prompt:

Keep outputs reasonably concise.

User-facing progress updates

Claude Opus 5 narrates readily during agentic work: it tends to announce what it is about to do, and its per-message output in agentic sessions is often longer than prior models'. It benefits from explicit guidance on how to communicate with the user during a task. To tune narration down, describe the cadence and shape you want:

Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome: your first sentence should answer "what happened" or "what did you find," with supporting detail after it for readers who want it.

To tune narration up, or change its style, the same lever applies in the other direction: explicitly describe what updates should look like and provide examples. Positive examples of the communication style you want tend to be more effective than instructions about what not to do.

Written deliverable length

Separate from conversational verbosity, files that Claude Opus 5 writes to disk (reports, Markdown documents, summaries) are often longer than on prior models. If your product includes Claude-authored documents, add explicit length calibration:

Match the length of written documents to what the task needs: cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate.

Task scope and over-verification

Claude Opus 5 verifies its own work without being told to. If your prompt contains explicit verification instructions ("include a final verification step for any non-trivial task," "use a subagent to verify"), remove them: instructions like these cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality. The same applies to legacy harness scaffolding that adds separate verification steps.

Claude Opus 5 can also expand the scope of a task, adding steps that weren't requested or applying its own judgment about what the task should be. For narrow tasks, constrain scope explicitly:

Deliver what was asked, at the scope intended. Make routine judgment calls yourself, and check in only when different readings of the request would lead to materially different work. If the request seems mistaken or a better approach exists, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it. Finish the whole task, and stop short of actions that are clearly beyond what was asked.

Controlling subagent spawning

Claude Opus 5 delegates to subagents more readily than prior models. Delegation pays off on genuinely independent, sizeable tracks of work, but it multiplies cost and time when applied to small tasks. If your harness supports subagents, give explicit guidance on which scenarios warrant delegation, or set deterministic caps on how many agents can be launched. For example:

Delegate to a subagent only for large tasks that are genuinely independent and parallelizable, such as a wide multi-file investigation. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work. If one subagent can complete the task, use one rather than several, and keep spawn counts low.

Self-correction

Claude Opus 5 catches and fixes its own mistakes well without prompting. Avoid instructing re-checks it already performs ("double-check your answer," "re-verify before responding"); like verification instructions, these compound with the model's own behavior and add cost without improving results.

The model also narrates corrections to its earlier statements more than prior models do, which can be undesirable in user-facing products. To limit correction narration to corrections that matter:

Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue the task. For slips that change nothing for the user, make the fix and move on without noting it.

Running with thinking disabled

Claude Opus 5 runs with thinking on by default, and thinking can be disabled only at effort high or below; see the migration guide. With thinking disabled, two artifacts can occasionally appear in the model's visible output. The primary mitigation for both is to keep thinking enabled and control token cost with lower effort levels instead of disabling thinking: for most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost.

Tool calls as text. With thinking disabled, the model occasionally writes a tool call into its user-facing text instead of emitting a structured tool_use block. The turn completes normally and the call never runs, and in agentic loops the leaked text stays in the conversation history, so later turns are affected as well. This is most common on tool-heavy workloads such as search.

Internal XML tags in output. With thinking disabled, the model can emit <thinking> tags or other internal XML tags into its visible response. If your system prompt contains a rule instructing the model not to think or not to reason, remove it; that kind of instruction increases tag leakage.

For integrations that must keep thinking disabled, a single combined instruction mitigates both artifacts: it gives the model explicit permission to speak before a tool call, an alternative to forcing a call when no tool fits, and a general rule against internal tags:

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

Instructions that call out thinking tags by name are less effective than the general form, so avoid naming them specifically.