Disabling thinking can 400 your Opus 5 calls

A migration that looks like a one-line model change can fail before your agent writes a token. The sharp edge is the interaction between Opus 5 effort levels and disabled thinking.

Which Opus 5 API setup triggers the HTTP 400?

The Opus 5 API setup that triggers HTTP 400 is disabling thinking while also requesting xhigh or max effort; Anthropic says disabled thinking is accepted only at high effort or below . In practical terms, an Opus 5 migration should treat output\_config.effort and thinking as coupled controls, not independent toggles.

Quick Answer: Opus 5 calls can return HTTP 400 when thinking is set to disabled and effort is set above high, specifically xhigh or max. Opus 5 launched on July 24, 2026 with adaptive thinking on by default .

Claude Opus 5 is Anthropic’s production model target for complex coding and agentic work, launched on July 24, 2026 with the API model ID claude-opus-5 . The model overview lists a 1M-token context window, 128k maximum synchronous output tokens, and adaptive thinking enabled by default .

That is why Opus 5 is not a plain model-name swap from Opus 4.1. Existing Messages API code can start by changing the model field, but production agents still need fresh tests for effort, thinking behavior, tool use, refusal handling, and token budgets . The risky shortcut is to carry over an old “disable reasoning to save tokens” habit without checking the new effort contract.

"Disabling thinking can impact tool call behavior," — Anthropic, Claude effort guidance (source: Anthropic)

Anthropic also warns that disabled thinking can make tool calls appear as visible text instead of structured tool invocations . Use disabled thinking only after an eval shows the agent still calls tools correctly.

The following snippet is illustrative and was not executed; it shows the kind of request shape you can use to reproduce or inspect the failure path with your own API key.

import json
import os
import sys
import urllib.error
import urllib.request

api_key = os.environ.get("ANTHROPIC_API_KEY")
if not api_key:
    print("Set ANTHROPIC_API_KEY to run this against the Anthropic API.")
    sys.exit(2)

payload = {
    "model": os.environ.get("ANTHROPIC_MODEL", "claude-opus-5-20260729"),
    "max_tokens": 64,
    "thinking": {"type": "disabled"},
    "messages": [{"role": "user", "content": "Say hello."}],
}

req = urllib.request.Request(
    "https://api.anthropic.com/v1/messages",
    data=json.dumps(payload).encode(),
    headers={
        "x-api-key": api_key,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
    },
    method="POST",
)

try:
    with urllib.request.urlopen(req, timeout=30) as r:
        print(r.status, r.read().decode())
except urllib.error.HTTPError as e:
    print(e.code, e.read().decode())

Opus 5 API setup prerequisites

Opus 5 API setup requires an Anthropic API key, a current Anthropic SDK or direct HTTPS client, the Messages API, and the model field set to claude-opus-5. Anthropic lists Claude Opus 5 as available through the Claude API and major cloud channels, so production teams should confirm their actual account, region, and deployment path before sending traffic .

The minimum local checklist is simple: set ANTHROPIC_API_KEY, install or update the official SDK you already use, keep the request on the Messages API, and change the model selector to claude-opus-5. Anthropic’s API primer documents the Messages API as the standard request path for Claude application calls .

Before changing production routing, verify Opus 5 availability in the channel you actually run: Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry, or another managed Claude deployment. Anthropic’s Opus 5 release notes state that access spans the Claude API and cloud partner deployments, but cloud model IDs, regions, quotas, and enablement steps can differ by provider .

Set your limits before implementation, because Opus 5 is not just a model-name swap. Anthropic documents a 1M-token context window as both the default and maximum, 128k maximum synchronous output tokens, and a 512-token minimum for prompt-cache entries . Those limits should drive request validation, logging, cache chunking, and budget alerts before the first live rollout.

Numbered Opus 5 rollout steps for Claude Code routing

Claude Code routing for Opus 5 should be explicit, measured, and split by task type: pin the model, sweep effort levels, reserve Opus for high-uncertainty work, and benchmark fast mode separately. Claude Code supports model selection through interactive, CLI, environment, and settings-based controls, while Anthropic documents high as the default effort level for Opus 5 .

1. Pin model selection before testing. In Claude Code, set Opus 5 intentionally with /model, claude --model, ANTHROPIC_MODEL, the settings model field, or family override variables such as ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL, and CLAUDE_CODE_SUBAGENT_MODEL . This avoids a rollout where one developer is testing Opus while another is silently using a provider default.
2. Sweep effort levels instead of copying Opus 4.1 settings. Test low, medium, high, xhigh, and max against the same task set; Anthropic lists high as the default, but that does not make it the right cost-quality point for every repository task .
3. Route by job, not prestige. Use Opus 5 for planning, diagnosis, review, architecture, and ambiguous debugging. Send routine edits, test loops, and cheaper execution paths to Sonnet or Haiku when your evals show no quality loss; Claude Code’s documented model controls and cost guidance support this kind of tiered routing .
4. Benchmark fast mode as a separate lane. Opus 5 fast mode is Claude API only, priced at $10 per million input tokens and $50 per million output tokens, and Anthropic says it can deliver up to 2.5x higher output tokens per second . Treat it as a throughput option, not a drop-in replacement for standard routing.

Routing decision	Recommended starting point	What to measure
Planning, diagnosis, architecture review	Opus 5 with high effort	Accepted plan rate, review accuracy, follow-up edits, cost per completed task
Long refactors or difficult debugging	Opus 5 with xhigh, then compare against high	Regression count, tool-call discipline, wall-clock time, retry count
Routine edits and test loops	Sonnet or Haiku where repository evals pass	Pass rate, edit churn, token spend, developer intervention rate
High-volume API output	Opus 5 fast mode, tested separately from standard mode	Output tokens per second, cache-hit impact, retry rate, final cost

Opus 5 benchmarks and cost controls to measure before rollout

Opus 5 benchmarks are useful migration signals, but they are not enough to approve a production rollout by themselves. Anthropic reported Opus 4.1 at 74.5% on SWE-bench Verified , while Opus 5 materials report 96.0% on SWE-bench Verified, 79.2% on SWE-bench Pro, 89.5% on SWE-bench Multilingual, and 59.4% on SWE-bench Multimodal . Treat those numbers as a reason to test Opus 5 in your own coding-agent harness, not as a substitute for repository-level evidence.

The practical eval should look less like a leaderboard and more like a release gate. Track pass rate, regression count, tool-call discipline, wall-clock time, retry count, and cost per completed task. SWE-bench Verified is a useful public reference point, but Claude Code routing decisions should be based on your codebase, your tools, and your failure modes, especially if subagents, long sessions, or custom model overrides are part of the workflow .

"Use Opus for complex tasks and Sonnet for routine work," — Anthropic Claude Code documentation (source: Anthropic Support)

Cost needs the same treatment. Opus 5 is listed at $5 per million input tokens and $25 per million output tokens , which is far below Opus 4.1’s $15 per million input tokens and $75 per million output tokens . That lower unit price can still produce a larger bill if agents use the 1M-token context window aggressively or run high-effort attempts repeatedly .

• Set strict max_tokens for every production route, then raise it only where evals show truncation.
• Sweep effort levels instead of assuming higher effort is always worth the latency and token cost .
• Route routine implementation, tests, and mechanical edits to cheaper models when your repository evals show no quality loss.
• Use prompt caching for large repeated context; cache reads are priced at 0.1x base input cost .
• Move asynchronous workloads to Batch API where appropriate, because Anthropic lists a 50% input and output discount for batch processing .
• Use Console usage as the billing source of record, then compare it with your own per-task telemetry .

A good rollout decision is boring: Opus 5 should win on completed work per dollar, not just on benchmark percentage. If the model solves harder planning and review tasks with fewer retries, it earns the premium route. If it only improves already-passing routine tasks, keep those loops on Sonnet or Haiku and reserve Opus 5 for the jobs where the measured delta is visible.

Fallback plan for Opus 4.1 and refusal handling

A workable Opus 5 fallback plan should remove Opus 4.1 from any long-term production path, because Anthropic deprecated Claude Opus 4.1 on June 5, 2026 and scheduled Claude API retirement for August 5, 2026 . Treat Opus 4.1 as a temporary regression-comparison target only; production fallback should route by task value, cost, and failure class.

The practical routing pattern is simple: send high-uncertainty planning, diagnosis, review, architecture, and difficult agent loops to Opus 5; keep cheaper execution paths on Sonnet or Haiku when your evals show no quality loss; and use Opus 4.8 only as a short-term compatibility fallback where legacy Opus behavior still matters . Claude Code supports explicit model selection through settings, environment variables, slash commands, and model override controls, so fallback should be configured intentionally instead of left to whichever default happens to be installed .

Server-side fallback is useful, but it solves a narrow problem. Anthropic’s fallback beta uses the server-side-fallback-2026-07-01 header and accepts either default fallbacks or an explicit list of up to three fallback models . That path applies to supported refusal categories, not every failed request.

• Refusal path: handle HTTP 200 responses with stop_reason: "refusal" as policy or safety outcomes, not network failures .
• Reliability path: handle 429s, overloads, and 5xx errors with client-side retry, exponential backoff, telemetry, and possibly model or provider failover .
• Cost path: track completed tasks per dollar, because Claude Code cost guidance points teams to usage dashboards, model tiering, compacted sessions, and spend limits rather than one-model routing .

The takeaway: make Opus 5 the premium route for work that benefits from deeper reasoning, keep routine loops on cheaper models, and split refusal handling from transport reliability. A fallback that still depends on Opus 4.1 is already carrying a retirement deadline.

Frequently asked questions

Why does disabling thinking return HTTP 400 with Opus 5?

Disabling thinking can return HTTP 400 with Opus 5 because Anthropic permits thinking: {"type":"disabled"} only when effort is set to high or below; xhigh and max require thinking behavior to remain enabled . In practice, the fix is to either lower output_config.effort to high, medium, or low, or keep thinking enabled for the higher-effort run.

Can I migrate from Opus 4.1 by changing only the model name?

A basic Messages API call can start by changing the model ID to Opus 5, but a production migration should retest effort settings, token limits, tool behavior, refusal handling, latency, and spend before rollout . Opus 5 changes the operational surface because effort is now a central quality, latency, and cost control, with supported values from low through max .

Is Opus 5 cheaper than Opus 4.1?

Opus 5 is cheaper than Opus 4.1 on listed token price: Anthropic lists Opus 5 at $5 per million input tokens and $25 per million output tokens, while Opus 4.1 was listed at $15 per million input tokens and $75 per million output tokens . Actual spend can still rise if you use larger context windows, higher effort, longer outputs, weak prompt caching, broad retries, or route routine work to Opus by default.

Should Claude Code use Opus 5 for every task?

No. Claude Code should use Opus 5 for planning, diagnosis, review, architecture, and difficult reasoning, while routine implementation loops, tests, mechanical edits, and subagent work should move to cheaper models when repository evals show no quality loss. Claude Code supports explicit model routing through settings, environment variables, model overrides, and subagent model controls .

What should replace Opus 4.1 as a fallback?

Use Opus 4.8 as a short-term compatibility fallback where needed, and use Sonnet or Haiku for lower-cost execution paths when evals support the route. Opus 4.1 should only remain in temporary regression comparisons because Anthropic lists it as deprecated on June 5, 2026 and scheduled for Claude API retirement on August 5, 2026 .