[BUG] thinking.adaptive.block_binding.prefix_mismatch_behavior: Extra inputs are not permitted

[januaryjon]

Description

After upgrading from OpenCode 1.18.25 to 1.18.26, requests to amazon-bedrock/global.anthropic.claude-opus-5 fail before producing output:

The model returned the following errors: thinking.adaptive.block_binding.prefix_mismatch_behavior: Extra inputs are not permitted

The same Bedrock model and configuration worked before 1.18.26. There is no custom thinking or reasoningConfig override.

1.18.26 introduced block_binding for Claude 5 in #46653. That PR notes that live verification against Bedrock was still outstanding. The Bedrock Opus 5 route appears to reject the injected field despite the accompanying beta configuration.

Expected: Claude Opus 5 requests succeed, dropping stale thinking blocks when necessary.

Actual: the request is rejected due to the injected prefix_mismatch_behavior field.

Plugins

• oh-my-opencode-slim
• @datadog/opencode-plugin

OpenCode version

1.18.26

Steps to reproduce

1. Configure the amazon-bedrock provider in ap-southeast-1.
2. Use model amazon-bedrock/global.anthropic.claude-opus-5 with variant high.
3. Send a prompt through the primary agent.
4. Observe the request fail with the validation error above.

Screenshot and/or share link

No share link available. The exact error is included above.

Operating System

Ubuntu 24.04 on WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2, x86_64)

Terminal

tmux (TERM=tmux-256color)

[mimi1vx]

same problem with Sonnet5 on google vercell endpoint

[mgberg]

Same problem with the Anthropic-compliant endpoint I'm using

[dkindlund]

Confirming this on a third provider path — not Bedrock, not Vertex, but @ai-sdk/anthropic pointed at an Anthropic-compatible endpoint (LiteLLM in front of Anthropic). Same commit, same field, same failure. Between this thread's reports that's now Bedrock, Google Vertex, and the plain Anthropic provider, so the blast radius looks like "every provider path except vanilla api.anthropic.com".

thinking.adaptive.block_binding: Extra inputs are not permitted

Regression window confirmed by our own logs: 1.18.22 worked, 1.18.26 fails. First release containing 3f39a32 is 1.18.26.

The discriminating detail: it's adaptive specifically, and the beta header doesn't help

I probed the endpoint directly with curl, no opencode in the path, model claude-opus-5:

Request body	Result
thinking: {"type":"adaptive"}	OK
thinking: {"type":"adaptive", "block_binding":{"prefix_mismatch_behavior":"drop_block"}}	rejected
…same, plus anthropic-beta: thinking-binding-controls-2026-08-01	rejected
…same, plus both betas from the vendored patch	rejected
thinking: {"type":"enabled","budget_tokens":1024, "block_binding":{…}}	OK
thinking: {"type":"disabled"}	OK

Two things fall out of that:

1. block_binding is refused under thinking.adaptive but accepted under thinking.enabled. The API's adaptive variant appears not to carry the field at all, which is consistent with the error naming the path thinking.adaptive.block_binding.
2. Adding thinking-binding-controls-2026-08-01 does not rescue it, so this isn't purely a missing-beta-passthrough problem at the proxy layer.

Why this is hard to work around

anthropicBlockBinding() in packages/opencode/src/provider/transform.ts applies unconditionally to any Claude model whose thinking type is adaptive or enabled, with no flag:

const ANTHROPIC_BLOCK_BINDING = { prefixMismatchBehavior: "drop_block" }
// Models that do not run the check accept the field, so it is safe on every Claude.

That comment is the assumption that breaks. There's no config knob to disable it, so on a managed/locked-down install (ours ships a root-owned config that wins the merge) there is genuinely no user-side escape hatch — you can't override options.thinking.type and you can't register a corrected provider.

Workaround for anyone blocked right now

Set the model's thinking to the non-adaptive shape. block_binding still gets injected, but under enabled the API accepts it:

"claude-opus-5": {
  "options":  { "thinking": { "type": "enabled", "budgetTokens": 32000 } },
  "variants": { "max": { "thinking": { "type": "enabled", "budgetTokens": 64000 } },
                "off": { "thinking": { "type": "disabled" } } }
}

Verified working for claude-opus-5 (default / max / off) and claude-sonnet-5. Cost is losing adaptive thinking.

One data point I can't explain

claude-opus-4-8 is configured identically ({"thinking":{"type":"adaptive"}}) and by my reading of anthropicBlockBinding() should also receive blockBinding — but it works fine against the same endpoint. Either anthropicThinksByDefault()/anthropicOmitsThinking() interact in a way I've misread, or the upstream validates the field only for Claude 5. Flagging rather than guessing, in case it narrows the fix.

Suggested direction

Make blockBinding opt-out-able rather than unconditional — either a provider/model config flag, or skip injection when the user has set thinking explicitly. Happy to send a PR for whichever shape maintainers prefer.

[rekram1-node]

I cannot reproduce any issues with bedrock, I did see that it was being too aggressive and was sending the param for older models like haiku. Merged a fix.

As for endpoints that don't support it I think best bet is to just make it an optional thing U can disable like @dkindlund suggested...

Will investigate the vertex claims

Also will release the changes I made and his changes shortly too. For now downgrade the prior version to avoid errors.

[rekram1-node]

1.18.27 contains the fixes mentioned, there is a known issue with opencode zen not accepting these parameters, that's an inference bug and we will fix.

[rekram1-node]

Okay inference side for zen is fixed.