Skip to content

bedrock: Opus 5.5 thinking blocks rejected as 'bound to a different conversation' in subagent sessions #51481

Closed

Description

@guss77

Summary

With Claude Opus 5.5 on Amazon Bedrock, longer sessions that run subagents fail with a 400 Invalid signature in thinking block. The block is bound to a different conversation. The native Anthropic Messages route automatically sets thinking.block_binding.prefix_mismatch_behavior: "drop_block" and sends the thinking-binding-controls-2026-08-01 beta. The Amazon Bedrock route does neither, so the session gets a hard error and can't continue.

This report was generated by opencode running Claude Opus 5.5

Environment

  • opencode version: 2.0.16
  • OS: Linux 7.2.5-200.fc44.x86_64 (x86_64)
  • Terminal: TERM=xterm-256color (running inside GNU Screen, inside a container with "-ti")
  • Shell: /bin/bash
  • Install/channel: latest (~/.opencode/bin/opencode)
  • Active plugins: none found in config

Reproduction

  1. Configure "model": "amazon-bedrock/global.anthropic.claude-opus-5-5" on an AWS account where the Anthropic prefix check is enforced by default (accounts created on or after 2026-08-31).
  2. Run a prompt that makes the primary agent spawn one or more subagents and do a long, multi-step turn with tool calls.
  3. On a later step of the same session, the request fails.

Expected Behavior

The session keeps going. OpenCode should either send history whose thinking blocks still match their original conversation, or do what the Anthropic route already does: send block_binding.prefix_mismatch_behavior: "drop_block" plus the thinking-binding-controls-2026-08-01 beta. On Bedrock, that beta goes in additionalModelRequestFields.anthropic_beta.

Actual Behavior

Error: The model returned the following errors: messages.3.content.95: Invalid `signature` in `thinking` block. The block is bound to a different conversation. Remove the block, or set `thinking.block_binding.prefix_mismatch_behavior` to "drop_block". That setting requires the `thinking-binding-controls-2026-08-01` value in the `anthropic-beta` header. The `thinking` block that preceded this one when it was created is missing from this request.

The last sentence says a thinking block earlier in the history was removed, so the remaining blocks have a gap.

Additional Context

What I found by reading the bundled 2.0.16 code:

  • Anthropic Messages route: the request builder wraps thinking so it adds block_binding: { prefix_mismatch_behavior: "drop_block" } for models that pass supportsThinkingBlockBinding (Claude 5.1+, which includes opus-5-5). The beta list then adds thinking-binding-controls-2026-08-01 whenever thinking.block_binding is present.
  • Bedrock Converse route: no equivalent. additionalModelRequestFields only gets thinking from the reasoning variant settings. There is no block_binding and no anthropic_beta entry for binding controls.
  • Probable cause of the gap: Bedrock Converse lowerMessages turns an assistant reasoning part that has no signature (or an empty one) into a plain text block. If a thinking block's signature is lost, which may happen with interrupted or parallel subagent steps, the thinking chain has a gap and every later thinking block fails the prefix check.

Workaround (verified): this model config fixes it on the default model and on #max:

{
  "providers": {
    "amazon-bedrock": {
      "models": {
        "global.anthropic.claude-opus-5-5": {
          "settings": { "anthropicBeta": ["thinking-binding-controls-2026-08-01"] },
          "body": {
            "additionalModelRequestFields": {
              "thinking": { "block_binding": { "prefix_mismatch_behavior": "drop_block" } }
            }
          }
        }
      }
    }
  }
}

Without the beta, the same body returns thinking.adaptive.block_binding: Extra inputs are not permitted. That shows the fields reach Bedrock and the beta has to be sent explicitly there.

Suggested fixes:

  1. Apply the same block_binding default and beta (via anthropic_beta in additionalModelRequestFields) on the Bedrock route. Google Vertex Messages probably needs the same check.
  2. Don't turn signature-less reasoning into text in the middle of the history, because that creates the gap. Drop it instead, or keep the thinking chain unbroken.

Reference: https://platform.claude.com/docs/en/build-with-claude/preserved-thinking

Frequency: happens repeatedly in sessions that use subagents.

Activity

  1. github-actions commented on Sep 26, 2026

    @github-actions
    Contributor

    This issue does not fully meet our contributing guidelines.

    What needs to be fixed:

    • The Bug Report template requires a Description field, but this issue uses a Summary heading instead. Please use the bug report template and include the problem description in its required field.
    • The report identifies itself as AI-generated and is lengthy. Please edit it into a concise description in your own words; reproduction steps and relevant diagnostic details can remain.

    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:

    • #46729: reports Bedrock rejecting the block_binding setting.
    • #48637: reports the same invalid thinking-signature / different-conversation error.
    • #16246: reports thinking-signature replay failures in multi-turn Anthropic subagent sessions.

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

  2. github-actions commented on Sep 26, 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.

  3. guss77 commented on Sep 26, 2026

    @guss77
    Author

    The fact that you don't like ai generated reports, and also give the human in charge just 2 hours to respond - is ridiculous! Humans need to sleep and visit their parents - they can't respond in 2 hours.

  4. ndeybach commented on Sep 29, 2026

    @ndeybach

    seeing the same problem here...

    Insane to close PRs after 2hr. Like what world are the maintainers living in ??? Do they even sleep ??

  5. rekram1-node commented on Oct 1, 2026

    @rekram1-node
    Contributor

    28e13d9

    For a while we dealt with such an onslaught of spam that we were forced to put extra aggressive rules in place. I've loosed them to 72 hrs, the 2hr window is far too aggressive and I apologize for that. We are going to be a lot better at managing github.

    We have also fixed this issue as of v2.0.20: #51959

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