v2.1.116 fails with Bedrock: output_config.effort not permitted

This is a clean regression boundary: same Bedrock deployment path, newer Claude Code version, immediate failure on any prompt because the client is sending a parameter the Bedrock side rejects. The error text is especially useful because it points to a concrete schema mismatch rather than a vague connectivity problem.

That makes this less about Bedrock generally and more about client compatibility discipline. If v2.1.114 works and v2.1.116 fails on the same enterprise setup, then the newer client likely started emitting request shape that Bedrock does not accept.

From the operator perspective, this is severe because it blocks the entire product at input 1. Enterprise users do not get degraded quality or a missing feature, they get a dead-on-arrival upgrade.

Looking at the v2.1.116 release notes, this is likely related to:

Thinking spinner now shows progress inline ("still thinking", "thinking more", "almost done thinking"), replacing the separate hint row

The output_config.effort parameter is probably how Claude Code now communicates thinking effort level to the API for these new progress indicators. Bedrock's API validation appears to reject this parameter.

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/30795
2. https://github.com/anthropics/claude-code/issues/30760
3. https://github.com/anthropics/claude-code/issues/50100

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This appears related to #50100 but in the opposite direction:

• #50100: Opus 4.7 on Bedrock requires output_config.effort (Claude Code wasn't sending it)
• This issue: Opus 4.5 on Bedrock rejects output_config.effort (Claude Code now sends it)

The fix for 4.7 appears to have broken 4.5 on Bedrock. The parameter may need to be conditionally sent based on model version.

Also related to #30760 (closed) - same underlying issue of effort parameter being sent to models that don't support it. That fix addressed model switching; this appears to be the same parameter now being sent unconditionally on session startup.

This is a recurring regression. Same issue occurred in v2.1.68 (#30795) with Sonnet 4.5 on Bedrock GovCloud - effort parameter sent to models that don't support it.

Pattern: updates that add/modify thinking features break Bedrock deployments where the model version doesn't support the new parameters.

This also affects subagent dispatches in mixed-model workflows, not just session startup.

When the parent session runs on Opus (which accepts effort), subagents dispatched with model: haiku in their agent definition frontmatter inherit the effort setting and immediately fail with 400 output_config.effort: Extra inputs are not permitted. The subagent never starts — it bombs on the first API call.

Reproduction path:

1. Parent session on Bedrock Opus (effort accepted, works fine)
2. Dispatch a subagent via the Agent tool with model: haiku (e.g. agent definition frontmatter or inline)
3. Subagent sends output_config.effort to Haiku endpoint → 400

This is distinct from the global session scenario in the OP because the parent model supports effort — it's the per-subagent model resolution that needs to conditionally strip it.

The workaround is to avoid Haiku entirely and run those agents on Sonnet, but that defeats the cost optimisation of using Haiku for trivial tasks.

#51059 proposes a modelEffort block in settings.json which would be the proper declarative fix for this. At minimum, Claude Code should strip output_config.effort for models that don't support it, regardless of the global setting.

Previously reported as #30795 (v2.1.68, Sonnet 4.5 on GovCloud) — same root cause, now resurfacing on Haiku.

Thanks for flagging. Fix should be in the upcomming v2.1.117 release

Confirmed. This is fixed for my use case. No longer getting 400 errors.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.