Claude Opus 5 Returns a 400 Error With Thinking Disabled: What to Do

If you updated your code to Claude Opus 5 and started getting a 400 error out of nowhere, the cause is probably one specific combination: thinking disabled together with effort xhigh or max. It's a new rule, officially documented by Anthropic, that didn't exist on Opus 4.8.

What does this 400 error on Claude Opus 5 mean?

It means your request is asking for two incompatible things at once. Anthropic's official documentation is direct about it:

"On Claude Opus 5, thinking cannot be disabled at xhigh or max effort: requests that set thinking: {"type": "disabled"} at those levels return a 400 error." (platform.claude.com/docs/en/build-with-claude/effort, checked 2026-09-09)

In other words: on Opus 5, you can only turn thinking off if effort is set to high or below. At xhigh or max, the model requires thinking to be active, and the API rejects the request before processing anything.

Why did this break right after migrating from Opus 4.8?

Because that constraint doesn't exist on Opus 4.8: disabling thinking was independent of the effort level, so you could run max with thinking off with no issue. Anyone who had that pattern in their code (common in pipelines that disable thinking to cut latency or force a fixed output format) and swapped model to claude-opus-5 without touching anything else started hitting 400s exactly on the highest-effort calls, which tend to be the most critical ones in the flow.

It's also worth noting that if you simply omit the thinking field instead of disabling it, behavior changes from model to model: on Opus 4.8 the request runs without thinking; on Opus 5, the same request runs with adaptive thinking by default. That affects the max_tokens budget, which on Opus 5 is a hard cap on thinking plus response text combined.

How to fix it now, with the right command

Two ways out, depending on what you actually need.

If you can live with thinking active (most cases), drop the thinking field from the request and leave xhigh or max as is:

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": 65536,
    "output_config": {"effort": "xhigh"},
    "messages": [{"role": "user", "content": "..."}]
  }'

The documentation itself recommends starting at 64k tokens of max_tokens for xhigh or max tasks on Opus 5, because the model needs room to think and act across tools and subagents within that same cap.

If you genuinely need thinking off (a fixed output format, for example), the fix is to lower effort to high or below instead of forcing the high level:

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": 4096,
    "thinking": {"type": "disabled"},
    "output_config": {"effort": "high"},
    "messages": [{"role": "user", "content": "..."}]
  }'

This isn't an isolated bug: wrong effort per model has broken production before

The Opus 5 case is new, but the category of problem isn't. In May 2026, the open source project TauricResearch/TradingAgents reported the exact same type of error in a different context: a pipeline that routed between Claude Haiku 4.5 (for quick tasks) and larger Opus models (for heavy reasoning) sent the effort parameter on every call, without checking whether the model on that call actually supported it. The result, straight from the issue:

{"type": "error", "error": {"type": "invalid_request_error",
"message": "This model does not support the effort parameter."}}

Same root cause in both cases: the code assumes a fixed capability per model family, while the API validates per specific model. Every release can change the rule without warning your pipeline.

Model	Supports effort?	Supports max	Supports xhigh	Thinking disabled blocked at xhigh/max
claude-opus-5	Yes, all 5 levels	Yes	Yes	Yes, returns 400
claude-opus-4-8	Yes	Yes	Yes	Not documented for this model
claude-sonnet-5	Yes	Yes	Yes	Not documented for this model
claude-sonnet-4-6	Yes	Yes	No	Not applicable (no xhigh)
claude-haiku-4-5	No	N/A	N/A	Error already happens on the effort parameter

The specific constraint blocking thinking at xhigh/max is officially documented only for Opus 5. Anthropic could extend the same rule to other models without notice, so treating this as an Opus-5-only edge case is risky.

How to check, model by model, without guessing

Instead of keeping that table in your head (or hardcoded in your code), the Models API returns each model's real capabilities, including effort:

curl https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01"

Every item in data carries a capabilities.effort object with a supported boolean per level (low, medium, high, max, xhigh). Checking that field before building the request, instead of applying the same effort to every model in your routing, avoids both error classes covered in this article at once.

Does this error happen to Verboo Code users?

Not through the CLI's own commands. Reading the source code of src/commands/effort/effort.tsx and src/utils/effort.ts in the verbeux-ai/code repository: the /effort command doesn't expose any way to disable thinking, it only picks an effort level within what the active model supports. And in native Claude account mode, that list of valid levels comes from getClaudeNativeModel(model)?.supportedReasoningLevels, fetched live from Anthropic's real Models API, the exact same capabilities.effort mentioned above.

In practice, asking for a level the active model doesn't support in Verboo Code doesn't turn into a raw 400: it becomes one of these two messages, right in the terminal:

Invalid reasoning level: max. Available for claude-haiku-4-5: , auto
Reasoning is not supported for claude-haiku-4-5

Whoever actually hits the real 400 error is usually writing their own API integration, outside the CLI, which is where the capabilities.effort check has to be done by hand.