## Summary

In the Bedrock SigV4 request path, LiteLLM signs the current request body with `sigv4.add_auth(request)`, then replays caller headers back onto the signed request.

On retry/fallback paths, those caller headers can include stale SigV4 headers from a previous request, such as `Authorization`, `x-amz-date`, or `x-amz-security-token`. Replaying them after signing can make AWS validate a different canonical request than the one LiteLLM signed.

## Trigger

We observed this in a Claude CLI session using LiteLLM routing/fallbacks.

The conversation history included Anthropic thinking blocks. A request hit the invalid-thinking-signature retry path, where LiteLLM stripped historical `thinking` / `redacted_thinking` blocks before retrying. The retried request then reached a Claude model routed through Bedrock, for example:

```text ageneric_api_call_with_fallbacks(model=claude-haiku-4-5-20251001) ```

The Bedrock request was freshly signed, but stale SigV4-related headers from the caller headers were replayed onto the signed request afterward. AWS then validated the actual request headers against the current body and rejected the signature.

This was not caused by invalid AWS cr…