Skip to content

Anthropic protocol never sends effort variant payloads (built + displayed, dropped at request construction) #46314

Closed as not planned

Description

@AnshulJ999

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)

  1. Variants are built for Anthropic-protocol models. packages/opencode/src/provider/transform.ts reasoningEffort() returns anthropicEffort(model, effort) ?? { effort } - for models without adaptive thinking that is { effort: "<value>" }.

  2. Config-declared variants load correctly. A custom provider model declaring

    "variants": { "high": { "effort": "high" }, "max": { "effort": "max" } }

    shows them in opencode models <provider> --verbose and in the effort selector of the desktop/TUI.

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

  4. Root cause. packages/llm/src/protocols/anthropic-messages.ts fromRequest() 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.

Drafted and filed by Claude.

Activity

  1. github-actions commented on Aug 30, 2026

    @github-actions
    Contributor

    This issue does not fully meet our contributing guidelines.

    What needs to be fixed:

    • 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:

    If you believe this was flagged incorrectly, please let a maintainer know.

  2. AnshulJ999 commented on Aug 30, 2026

    @AnshulJ999
    Author

    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.

  3. github-actions commented on Aug 31, 2026

    @github-actions
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions