You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
google-vertex-anthropic: claude-sonnet-5 fails on every message in v1.18.26 ("Extra inputs are not permitted" / thinking.block_binding) — works in v1.18.20 #46777
Every message sent to Claude Sonnet 5 (and the Haiku 4.5 title-generation call) via the google-vertex-anthropic provider fails immediately with:
AI_APICallError: thinking.enabled.block_binding.prefix_mismatch_behavior: Extra inputs are not permitted
AI_APICallError: thinking.adaptive.block_binding.prefix_mismatch_behavior: Extra inputs are not permitted
This happens on the very first message of a brand-new session, not just after long conversations, so it looks unconditional for these models on this provider.
The same model works fine through the desktop app, including when configured to use Vertex too, so the model/backend itself isn't broken — something in the request opencode builds is different.
Likely cause: the 1.18.26 release note "Claude 5 sessions now tolerate stale thinking blocks instead of failing after prompt or tool changes" appears to add a thinking.block_binding.prefix_mismatch_behavior field to requests for the newest Claude generation (Sonnet 5, Opus 4.7/4.8/5, Fable 5). Google Vertex rejects that field as unrecognized.
Downgrading to v1.18.20 fixes it completely — same config, same model, same provider, nothing else changed. A colleague on 1.18.20 has no issue with the exact same setup.
Plugins
superpowers, code-simplifier (unrelated — same result with both disabled)
OpenCode version
Broken on 1.18.26 (haven't bisected 1.18.21–1.18.25). Confirmed working on 1.18.20.
Steps to reproduce
Configure the google-vertex-anthropic provider.
Select claude-sonnet-5@default as the model.
Start a new session, send any message.
Request fails immediately (both the title-gen call on claude-haiku-4-5 and the main response on claude-sonnet-5).
Screenshot and/or share link
No response
Operating System
macOS 26.5 (arm64)
Terminal
Warp
Reacted by Michał Kowalewski, Marcus Burghardt and Davis Kirkendall
Is it? From what I see the issue seems to be that Claude Fable requires a new value, VertexAI rejects this unknown value. Also, if this field is needed for Claude Fable, why are submitting this field for Claude 4 models? Also Bedrock and VertexAI may handle this differently. One might support this field for all models, the other might only support it for Fable?
I would argue that these changes broke Claude 4 models which appears to be a bug on itself.
Deleted my Bug Report as duplicate as it is propably the same underlying issue.
Issue is NOT fixed with Opencode v1.18.27 using Opencode Zen and Fable 5.1
Activity
github-actions commentedon Sep 2, 2026
This issue might be a duplicate of existing issues. Please check:
thinking.block_binding.prefix_mismatch_behaviorfield introduced in v1.18.26 is rejected by cloud provider backends (Bedrock in that case, Vertex here) as an unrecognized field.feat: introduce options section for opencode.json template
DaanBiesterbos commentedon Sep 2, 2026
Same error for Claude 4. I cannot use claude models because VertexAI rejects thinking.block_binding.prefix_mismatch_behavior.
DaanBiesterbos commentedon Sep 2, 2026
Is it? From what I see the issue seems to be that Claude Fable requires a new value, VertexAI rejects this unknown value. Also, if this field is needed for Claude Fable, why are submitting this field for Claude 4 models? Also Bedrock and VertexAI may handle this differently. One might support this field for all models, the other might only support it for Fable?
I would argue that these changes broke Claude 4 models which appears to be a bug on itself.
FG-RVT commentedon Sep 2, 2026
Deleted my Bug Report as duplicate as it is propably the same underlying issue.
Issue is NOT fixed with Opencode v1.18.27 using Opencode Zen and Fable 5.1
rekram1-node commentedon Sep 2, 2026
That's a separate issue actually @FG-RVT
that's a bug on our inference. We will address it tho.