Agent/model launches request effort=xhigh against thinking-disabled model, crash with 400

Bug report: agent/model launches request effort=xhigh against a thinking-disabled model, crash with 400

Summary

Claude Code agent dispatches (both fresh Agent()-tool subagent launches and
SendMessage-resumed ones) intermittently but frequently fail at startup with:

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.

This happens despite the account's local settings capping effort at "high" with thinking
explicitly disabled — so xhigh should never be requested in the first place. The crash
occurred 28 times in a single session transcript and is not isolated to one session: three
other concurrently-running peer sessions on the same machine independently hit the identical
error string.

Environment

• Claude Code version: 2.1.233
• Platform: Windows 11 Pro (win32 x64)
• Shell: PowerShell 7 (primary) + Git Bash
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set (global settings.json env block)

Relevant local configuration (confirmed, not guessed)

~/.claude/settings.json:

"alwaysThinkingEnabled": false,
"effortLevel": "high",

~/.claude.json (account-level, not project-level):

"unpinOpus47LaunchEffort": true,
"unpinOpus48LaunchEffort": true,
"unpinFable5LaunchEffort": true,

No project-level or per-agent-definition file (.claude/agents/*.md, project/local
settings.json) sets effort or thinking to anything — confirmed by direct grep across all
of them; only two agent definitions in the project even set a model field (model: haiku),
and neither touches effort.

Reproduction (observed, not deliberately isolated)

Not yet reduced to a minimal repro — observed as a side effect of normal work: dispatching
subagents via the Agent tool (subagent_type: general-purpose and others) during a multi-hour
multi-agent session. Both of the following failed with the identical error:

1. Fresh dispatch, no explicit model override — crashed at least twice.
2. SendMessage to an already-idle/previously-run agent name (asking it to resume/continue)

— crashed 100% of the time across 4+ separate attempts, even after being told explicitly to
stop waiting and proceed rather than wait on a peer.

One dispatch pattern got past the crash and completed normally: a fresh Agent() call with
model: "sonnet" explicitly passed. This is a single data point, not a confirmed fix — logged
as a workaround, not a root-cause fix.

Scale (measured from session transcript, not estimated)

Grepped one session's .jsonl transcript directly:

• "effort":"xhigh" appears 666 times.
• "effort":"high" appears 11 times.
• The exact crash string ("not supported when thinking is disabled") appears 28 times.

So xhigh is the dominant effort value being requested against this account, not an
occasional misfire — despite effortLevel: "high" being the configured ceiling.

Suspected mechanism (unconfirmed — flagging as a lead, not a diagnosis)

The unpin*LaunchEffort flags in ~/.claude.json look like they let specific model launches
(notably ones resolving to claude-fable-5[1m] per additionalModelOptionsCache, and possibly
Opus 4.7/4.8 launches) bypass the settings.json effortLevel ceiling and resolve to a
higher, server-side default launch effort (xhigh) instead. If that default effort is xhigh
while the account also has alwaysThinkingEnabled: false, every launch that takes this
"unpinned" path would hit exactly this crash. This is a plausible read of the config shape, not
a confirmed root cause — no file was found on this machine that explicitly writes xhigh
anywhere, so how a given dispatch gets routed onto the "unpinned" path (vs. respecting the
effortLevel: "high" ceiling) is not understood from the client side.

Impact

On the task that motivated this report, 5 consecutive dispatch attempts on a single simple task
(a subagent fixing one well-scoped GitHub issue — untracking build output and updating
.gitignore) all crashed identically before any of them could create a worktree, write a file,
or do any work at all. The 6th attempt, using the fresh-dispatch + explicit model workaround,
succeeded. That is a 5x cost multiplier on trivial work, with each failed attempt also
consuming a full round-trip before the failure surfaces.

Ask

• Confirm whether this is a known issue with the unpinFable5LaunchEffort /

unpinOpus47LaunchEffort / unpinOpus48LaunchEffort mechanism, and if so what triggers a
given launch to take the "unpinned" path.

• If it's not intended behavior: either honor effortLevel/alwaysThinkingEnabled from

settings.json for all launches regardless of the unpin flags, or have the unpinned path fall
back to high (or enable thinking) rather than requesting xhigh against a
thinking-disabled model and hard-failing.

• If a client-side workaround exists (e.g. explicitly disabling the unpin flags, or always

passing model on every dispatch), documenting it would help — the "always pin model"
practice is currently based on one successful data point, not a confirmed fix.