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

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

Configure the amazon-bedrock provider in ap-southeast-1.
Use model amazon-bedrock/global.anthropic.claude-opus-5 with variant high.
Send a prompt through the primary agent.
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)

same problem with Sonnet5 on google vercell endpoint

feat: introduce options section for opencode.json template

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

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:

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.
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.

fix(opencode): let config opt out of Anthropic thinking blockBinding

@dkindlund

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.

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.

Okay inference side for zen is fixed.

I see the same issue for Fable 5.1 now:

Bad Request: {"error":{"message":"{\"type\":\"error\",\"error\":{\"type\":\"invalid_request_error\",\"message\":\"thinking.adaptive.block_binding: Extra inputs are not permitted\"},\"request_id\":\"xxx\"}. Received Model Group=claude-fable-5-1\nAvailable Model Group Fallbacks=None","type":"None","param":"None","code":"400"}}

@lwasyl

@lwasyl need more info.

Opt out of block_binding for Opus 5.5 in opencode

Navigation Menu

Repository navigation

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

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

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

Why this is hard to work around

Workaround for anyone blocked right now

One data point I can't explain

Suggested direction

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

mimi1vx commented on Sep 2, 2026

mgberg commented on Sep 2, 2026

dkindlund commented on Sep 2, 2026

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

Why this is hard to work around

Workaround for anyone blocked right now

One data point I can't explain

Suggested direction

rekram1-node commented on Sep 2, 2026

rekram1-node commented on Sep 2, 2026

rekram1-node commented on Sep 3, 2026

lwasyl commented on Sep 16, 2026

rekram1-node commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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