[BUG] Invalid Cache Point Injection in BedrockModel

[jmorgan-restrata]

Checks

• I have updated to the lastest minor and patch version of Strands
• I have checked the documentation and this is not expected behavior
• I have searched ./issues and there are no duplicates of my issue

Strands Version

1.29.0

Python Version

3.11

Operating System

Debian 11

Installation Method

pip

Steps to Reproduce

1. Create a BedrockModel (us.anthropic.claude-sonnet-4-6) with cache_config=CacheConfig(strategy="auto")
2. Send messages that contain assistant messages ending with reasoningContent blocks
3. Invoke the model's stream method
4. Observe Bedrock API validation error: "Cache point cannot be inserted after reasoning block"

Expected Behavior

Cache points should be inserted before reasoning blocks to comply with Bedrock's API constraints, allowing successful model invocation with automatic caching enabled.

Actual Behavior

The _inject_cache_point method appends cache points to the end of assistant messages without checking if the last content block is a reasoning block, causing API validation failures when reasoning content is present.

Additional Context

The auto-injection occurs in _format_bedrock_messages when cache_config.strategy == "auto" . The ReasoningContentBlock type contains reasoningText and redactedContent fields that must come before any cache points.

Possible Solution

Modify _inject_cache_point to detect reasoning content blocks and insert cache points before them:

#Check if the last block is reasoningContent if content and "reasoningContent" in content[-1]: # Insert cache point before the reasoning block content.insert(len(content) - 1, {"cachePoint": {"type": "default"}}) else: # Append cache point at the end (original behavior) content.append({"cachePoint": {"type": "default"}})

This ensures cache points are positioned correctly while maintaining backward compatibility for messages without reasoning blocks.

Related Issues

No response

[kevmyung]

Hi @jmorgan-restrata, thanks for reporting this. Adding a defensive check as you suggested makes sense.

This is an interesting case though. If reasoningContent refers to the intermediate thinking blocks from "extended thinking", the model API should return responses as [reasoningContent, text] or [reasoningContent, toolUse] since reasoning is always followed by at least one text or toolUse block.

So _inject_cache_point appends cachePoint after text or toolUse, resulting in [reasoningContent, text, cachePoint] or [reasoningContent, toolUse, cachePoint]. If an assistant turn actually ended with only reasoningContent, that would be abnormal from the model behavior standpoint.

Could you share more details about the specific message structure (or question-answer pattern) that produced this error?

[jmorgan-restrata]

@kevmyung ultimately, I'm not really sure how it got in that state. A colleague reported that the agent would not respond and showed me the issue. I checked for errors and found:

An error occurred (ValidationException) when calling the ConverseStream operation: Cache point cannot be inserted after reasoning block. Please remove the invalid cache point and try again.

This is the last interaction the user had:

Agent response ended. User prompted with no response. User prompted a second time with no response.

Our interface always displays "thinking" blocks at the end of the response. If thinking blocks appear after text a new visual segment is created - which has not happened here. So i don't believe the agent was "thinking" post response - but something has occurred here that can't be fully explained.

When i get access to AWS, I'll review the message composition.

[jmorgan-restrata]

@kevmyung I can see you made a pull request - thanks.

Just an update: I deleted the messages back to the last valid message. Executed the users last prompt and reviewed the logs. I can see the agent reaches an unrecoverable state due to max_tokens limit - this occurs during thinking.

Thinking budget_tokens was set to 2048, but the agents thinking section alone exceeded the agents max_tokens of 8092. Increasing the models max_tokens to 32768 allowed the agent to respond without error for this conversation.

In all attempts to respond before this change - agent failed due to unrecoverable state due to max_tokens limit - always during the thinking process - therefore the agent never had a chance to respond beyond thinking.

Hopefully this information is useful.

[kevmyung]

@jmorgan-restrata Got it, thanks for the update! That's the kind of issue I suspected it might be. Since there are too many variables on the assistant message side, I opened a PR to place the cache point after the last user message instead. Let's see how the review goes!

[pgrayy]

Proposed fix seems to make sense. Left one question on the PR though.

[giulio-leone]

I've submitted a fix in PR #1834.

Root cause: _inject_cache_point() unconditionally appended cache points to the end of assistant message content via content.append(). When the last content block was a reasoningContent block, this produced an invalid sequence that Bedrock rejected.

Fix: The method now walks backward over trailing reasoningContent blocks and inserts the cache point before them, producing the valid sequence: [..., text, cachePoint, reasoningContent].

All 122 Bedrock model tests pass.