Message Cache for Single-Turn Agents (Event-Loop Caching)

[zbw1037176947-netizen]

Problem Statement

I would like Strands Agents SDK to clarify and/or support message caching inside single-turn agents, specifically those that run an internal event loop but do not involve user-facing multi-turn conversations.

Based on my current usage and experiments:

• Multi-turn conversations can successfully trigger the message cache, reducing token usage.

• Single-turn agents, even when running internal loops with multiple internal messages, do not trigger the cache.

This leads to significantly higher token consumption for deterministic internal messages, especially in production workloads where single-turn agents repeatedly process similar or identical input patterns.

At the moment, it is unclear:

1. Whether Strands intentionally does not support message cache for internal agent loops,

2. Whether there is an existing mechanism that is undocumented, or

3. Whether the feature is planned for future development.

This lack of clarity makes it difficult to design cost-efficient single-turn agents.

Proposed Solution

I would like Strands to provide one of the following:

Option A — Official Feature Support

Enable message cache for internal agent event-loop messages, including:

• Internal reasoning steps

• Repeated deterministic messages

• System → agent messages inside the same run

• Agent → model messages in function loops

This would align single-turn agent behavior with multi-turn conversation agents.

Option B — Documentation Clarification

If this feature already exists, please:

• Document the usage pattern required to activate cache

• Provide an official example

• Describe limitations, scope, and expected behavior

Option C — Development Roadmap

If internal-loop caching is not supported, please clarify:

• Whether this feature is planned

• Expected roadmap or long-term intention (if possible)

Option D — Guidance for Custom Extension

If developers need to implement this ourselves, please point out:

• Relevant code locations handling caching (e.g., BedrockModel, message history management)

• Recommended extension points for overriding caching behavior

• Any constraints or edge cases to be aware of

This would help developers safely extend the SDK without reimplementing large sections of the framework.