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