bug: Bedrock models that don't support adaptive thinking reject `thinking.type: "adaptive"` requests

[blinkagent]

Summary

When using AI Bridge with Amazon Bedrock in regions where only older Claude models are available (e.g. GovCloud us-gov-west-1), requests from Claude Code fail with a 400 error because the thinking parameter is passed through unmodified to models that don't support "type": "adaptive".

Error

API Error: 400 {"error":{"message":"POST \"https://bedrock-runtime.us-gov-west-1.amazonaws.com/v1/messages\": 400 Bad Request {\"message\":\"thinking: Input tag 'adaptive' found using 'type' does not match any of the expected tags: 'disabled', 'enabled'\"}","type":"api_error"},"request_id":"","type":"error"}

Root Cause

Claude Code now sends "thinking": {"type": "adaptive"} by default (introduced with Opus 4.6 / Sonnet 4.6). The augmentRequestForBedrock() function in intercept/messages/base.go only remaps the model name — it does not transform or validate the thinking parameter for the target model's capabilities.

In GovCloud, the most advanced FedRAMP-authorized Claude model is Claude Sonnet 4.5, which only supports "thinking": {"type": "enabled", "budget_tokens": N} or {"type": "disabled"}. The "adaptive" type is only supported by Opus 4.6 and Sonnet 4.6.

Expected Behavior

augmentRequestForBedrock() should transform the thinking parameter based on the target Bedrock model's capabilities:

• If the model supports adaptive thinking (Opus 4.6, Sonnet 4.6): pass through as-is
• Otherwise: convert "adaptive" to "enabled" with a sensible budget_tokens default, or fall back to the model's supported thinking configuration

Impact

This is currently blocking usage of Claude Code through AI Bridge with Bedrock in GovCloud regions (and any other Bedrock deployment using models that predate adaptive thinking support).

References

• Anthropic Adaptive Thinking docs
• AWS Bedrock Adaptive Thinking docs
• AWS GovCloud Bedrock model availability
• Related prior fix for adaptive thinking being stripped: fix: Use requests byte payload in messages interceptor #185 / AIGOV-19

---

Created on behalf of @uzair-coder07

[uzair-coder07]

I have reviewed the content of this issue myself.

[blinkagent]

Good catch — pushed a follow-up commit (252e414) that addresses this.

budget_tokens is now derived from the request's max_tokens instead of being hardcoded:

• 80% of max_tokens is used as the budget (leaves room for the response)
• Clamped to Bedrock's minimum of 1024 when 80% falls below that
• Falls back to max_tokens / 2 when max_tokens is so small that even the minimum would violate the budget_tokens < max_tokens constraint
• Default of 10000 is used only when max_tokens is absent from the request

Test cases cover all branches: normal derivation, absent max_tokens, minimum clamping, and the very-small max_tokens edge case.

[openmarmot]

Good catch — pushed a follow-up commit (252e414) that addresses this.

budget_tokens is now derived from the request's max_tokens instead of being hardcoded:

• 80% of max_tokens is used as the budget (leaves room for the response)
• Clamped to Bedrock's minimum of 1024 when 80% falls below that
• Falls back to max_tokens / 2 when max_tokens is so small that even the minimum would violate the budget_tokens < max_tokens constraint
• Default of 10000 is used only when max_tokens is absent from the request

Test cases cover all branches: normal derivation, absent max_tokens, minimum clamping, and the very-small max_tokens edge case.

this generated commit does not resolve the core issue, which is that {"type": "adaptive"} is invalid for the govcloud bedrock api