WebSearch fails at effort xhigh with a misleading error: "thinking is disabled on this model" (Opus 5 cannot disable thinking)

Status Fixed / completed
Maintainer reply None cached
Activity 1 comment · opened Jul 29, 2026 · closed Aug 20, 2026

Summary

On Claude Opus 5, the built-in WebSearch tool fails immediately when effort is set to xhigh, with an error that states the opposite of what is actually wrong:

API Error: 400 output_config.effort 'xhigh' is not supported when thinking is disabled
on this model. Use effort 'high' or below, or enable thinking.

The message tells the user that thinking is disabled and suggests enabling it. On Opus 5, thinking is always on and cannot be disabled or enabled by the user — /config correctly shows Thinking mode: true. So the suggested remedy does not exist, and the stated cause is impossible.

Per the docs, what the API actually rejects is the opposite: Opus 5 accepts thinking: {type: "disabled"} only at effort high or below; combining it with xhigh or max returns 400. So something in the harness appears to send thinking: {type: "disabled"} for the WebSearch sub-request (reasonable in itself — a search query needs no reasoning), which then collides with xhigh.

Reproduction

  1. Claude Code CLI, model opus[1m]
  2. /effort xhigh
  3. Call WebSearch with any query
  4. → immediate 400, no results

Scope

Only WebSearch is affected. Bash, Read, Write, Edit and WebFetch all worked fine at xhigh in the same session — consistent with WebSearch being the one tool that issues its own model/backend request carrying output_config.

Workaround

/effort high — WebSearch then works immediately.

Why this is worth fixing

The error is not just cosmetic, it actively misdirects:

  • It names a state (thinking is disabled) that this model cannot be in.
  • It suggests an action (enable thinking) that has no corresponding setting.
  • A user who trusts it goes looking in settings.json and /config, finds nothing, and concludes their configuration is broken.
  • The natural fallback is WebFetch, which does run — but returns only the JS landing page for many sites. The user then concludes the source has no data, when in fact the tool was blocked. A failed measurement gets mistaken for a finding.

Suggested fix

Either don't send thinking: {type: "disabled"} for the WebSearch sub-request when effort is xhigh/max (let it inherit), or make the error say what is actually true, e.g.:

effort 'xhigh' cannot be combined with thinking: {type: "disabled"} on this model. Use effort 'high' or below.

Environment

  • Claude Code CLI, model opus[1m]
  • .claude/settings.json: model: opus[1m], effortLevel, switchModelsOnFlag: false — no thinking key
  • Env: CLAUDE_EFFORT
  • Linux (LMDE 7 / Debian 13)

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗