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

[dkindlund]

Issue for this PR

Closes #46729

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

#46653 added blockBinding to every Claude request whose thinking type is adaptive or enabled. Its comment says "Models that do not run the check accept the field, so it is safe on every Claude", but that turns out not to be true — #46729 has reports of it being rejected on Bedrock, on Google Vertex, and on Anthropic-compatible endpoints:

thinking.adaptive.block_binding: Extra inputs are not permitted

I hit this on the third of those. To work out whether it was opencode or my endpoint, I sent requests with curl directly, no opencode involved. thinking: {"type":"adaptive"} is accepted on its own; adding block_binding to it gets rejected; adding the thinking-binding-controls-2026-08-01 beta header does not change that. But block_binding under thinking: {"type":"enabled", "budget_tokens": N} is accepted. So the field is only refused under the adaptive variant, which lines up with the error naming the path thinking.adaptive.block_binding.

Since the injection is unconditional there's no way for an affected user to avoid it short of pinning 1.18.25. That's worse on managed installs — where a root-owned config wins the merge, overriding options.thinking.type doesn't take, and registering a corrected provider doesn't either because enabled_providers can't be extended from user config. So there's no escape hatch at all.

The change makes anthropicBlockBinding respect an explicit blockBinding in config instead of always overwriting it:

• blockBinding: false → omit the field
• blockBinding: {...} → use the caller's value
• absent → inject ANTHROPIC_BLOCK_BINDING, exactly as today

The default path is unchanged, so deployments where the field works keep getting it and the prefix-mismatch problem #46653 fixed stays fixed. I pulled the logic into a small applyBlockBinding helper so the @ai-sdk/anthropic, vertex, and bedrock reasoningConfig branches all behave the same way.

Affected users can then do:

"claude-opus-5": { "options": { "thinking": { "type": "adaptive", "blockBinding": false } } }

One thing I could not explain, in case it matters to you: claude-opus-4-8 is configured identically ({"thinking":{"type":"adaptive"}}) and by my reading of anthropicBlockBinding should also get the field — but the same endpoint that rejects claude-opus-5 accepts it. Either I've misread how anthropicThinksByDefault/anthropicOmitsThinking interact, or the API only validates this for Claude 5. I'd rather flag it than pretend I know.

If you'd prefer a different shape — a provider-level flag, a capability check, or retrying without the field on rejection — I'm happy to redo it.

How did you verify your code works?

Added 4 tests to packages/opencode/test/provider/transform.test.ts: opt-out on adaptive, opt-out on a think-by-default model, preserving an explicit value rather than overwriting it, and the bedrock reasoningConfig path.

Checked red/green rather than just green — with the test changes in place but transform.ts reverted to dev, those 4 fail; with the fix they pass:

without the source change:  440 pass, 4 fail
with the source change:     444 pass, 0 fail

All 440 pre-existing tests in that file still pass. Run with bun test test/provider/transform.test.ts from packages/opencode.

I also confirmed the underlying behaviour end to end outside the test suite: switching the model to thinking: {"type":"enabled", budgetTokens} unblocked claude-opus-5 and claude-sonnet-5 (default, max, and off variants) against the endpoint that was failing, which is the same code path this flag now lets you control.

Screenshots / recordings

N/A — not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍