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
Anthropic protocol never sends effort variant payloads (built + displayed, dropped at request construction) #46314
For custom providers using @ai-sdk/anthropic, reasoning-effort variants are computed, synced and displayed - but selecting one produces a request body containing neither effort nor thinking. The payload never reaches the wire.
Evidence (2026-08-31, current build)
Variants are built for Anthropic-protocol models.packages/opencode/src/provider/transform.tsreasoningEffort() returns anthropicEffort(model, effort) ?? { effort } - for models without adaptive thinking that is { effort: "<value>" }.
Config-declared variants load correctly. A custom provider model declaring
shows them in opencode models <provider> --verbose and in the effort selector of the desktop/TUI.
Selecting one sends nothing. With --variant high (CLI) and with high selected in the desktop UI, the outgoing request body contains exactly the usual keys - model, system, messages, tools, tool_choice, stream, max_tokens - and no effort and no thinking. Verified by tracing the HTTP body at a gateway between OpenCode and the upstream, on multiple turns, across both the CLI and desktop paths.
Root cause.packages/llm/src/protocols/anthropic-messages.tsfromRequest() builds the body from a fixed key list and only lowers thinking via lowerThinking() - which returns undefined unless thinking.type === "enabled". The effort provider option is never read, and adaptive payloads ({thinking: {type: "adaptive", ...}, effort}) are dropped too, since lowerThinking discards non-enabled types.
Impact
Every effort variant on every @ai-sdk/anthropic model is a silent no-op - the UI says the effort changed; the model always runs at its provider default. OpenAI-protocol models are unaffected (openai-chat/openai-responses lower reasoningEffort), which makes the asymmetry easy to miss.
Suggested fix
In fromRequest(), lower the effort provider option into the request body (pass-through is enough for gateway-style upstreams), and/or map effort → thinking budget for native Anthropic models. Passing the option through would also un-break adaptive payloads, which currently lose both halves.
The issue is explicitly stated to be AI-generated ("Drafted and filed by Claude."). We do not accept AI-generated issue reports — please rewrite this in your own words, describing what you actually observed and reproduced yourself.
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
I can't explain the issue any better than what Claude already did above, but I already verified and reproduced it myself.
When using a custom wrapper built on the Anthropic SDK inside OpenCode; the effort level is a no-op. It does not take any effect. So it is actively misleading; users think they chose an effort, but the backend drops the effort, and so the model defaults to its default effort.
Issue #42876 is indeed closely related, but if AI-generated issues aren't accepted, I'd at least appreciate a human dev/contributor to acknowledge the issue since it's an active bug.
Activity
github-actions commentedon Aug 30, 2026
This issue does not fully meet our contributing guidelines.
What needs to be fixed:
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
providerOptionsschema filtering intransform.ts), including on@ai-sdk/anthropic.If you believe this was flagged incorrectly, please let a maintainer know.
AnshulJ999 commentedon Aug 30, 2026
I can't explain the issue any better than what Claude already did above, but I already verified and reproduced it myself.
When using a custom wrapper built on the Anthropic SDK inside OpenCode; the effort level is a no-op. It does not take any effect. So it is actively misleading; users think they chose an effort, but the backend drops the effort, and so the model defaults to its default effort.
Issue #42876 is indeed closely related, but if AI-generated issues aren't accepted, I'd at least appreciate a human dev/contributor to acknowledge the issue since it's an active bug.
github-actions commentedon Aug 31, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.
Feel free to open a new issue that follows our issue templates.