[Bug] Anthropic prompt cache hit rate still low: cache_control lands on dynamic datetime block

[vcvcvcvcvcvcvcvcvc]

What happened

PR #9197 added cache_control to the last system block. But in practice the cache hit rate remains near 0% because the last system block is always the dynamic datetime reminder: 当前时间是: 2026-08-10 16:16:11

This block changes every single request, so Anthropic detects a cache miss and re-creates the entire cache each time. The large static portions (persona, behavior rules — ~8000+ tokens) that should be cached never actually get read from cache.

Root cause

_apply_explicit_prompt_cache_breakpoints unconditionally picks system_blocks[-1]. But AstrBot assembles system blocks with dynamic content (desire_state, daily_briefing, datetime) at the END. The cache_control lands on the datetime block, invalidating the entire cache every request.

Suggested fix

Scan system blocks from end backwards, skip short blocks containing 当前时间 / Current datetime markers, and place cache_control on the last substantial static block instead. This would increase cache hit rate from ~0% to 80%+.

Version

v4.27.2 (Docker)

Willing to PR?

Yes

[dosubot]

@vcvcvcvcvcvcvcvcvc 感谢详细的 bug report！不过有一个关键细节值得核实——你描述的根因可能不准确。

_append_system_reminders 并不写入 system blocks

当前代码中，_append_system_reminders 把 datetime 等动态内容追加到 req.extra_user_content_parts（作为 <system_reminder> TextPart），而不是 req.system_prompt [1]。在 Anthropic 适配器的 assemble_context() 中，extra_user_content_parts 会被注入到最后一条 user message 里，不会出现在 payloads["system"] 中 [2]。这正是 PR #8139 专门做的设计——把动态内容从 system prompt 移到 user turn，以避免 system prompt 前缀缓存失效。

因此 _apply_explicit_prompt_cache_breakpoints 中的 system_blocks[-1] 拿到的并不是 datetime block。

真正需要核查的是：你实际请求中 payloads["system"] 最后一个 block 到底是什么？

可以在 _apply_explicit_prompt_cache_breakpoints 里加一行临时 debug 日志来确认：

logger.debug("cache_control will be placed on: %s", last_block.get("text", "")[:100])

如果确认最后一个 system block 是某种其他动态内容（比如插件注入的内容），那你的修复方向——从末尾往前扫跳过动态块——是合理的。另外 issue #9388 已经提出了更全面的缓存优化方向（消息历史断点、4 个断点用满、TTL 可配等），你的 PR 可以参考那里的分析 [3]。

如果你有兴趣提 PR，建议跳过条件用 block text 长度阈值（比如 < 200 chars）或包含特定标签来判断，而不仅仅是匹配固定字符串，这样更健壮。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[vcvcvcvcvcvcvcvcvc]

@dosu 感谢核实。你说得对——<system_reminder> 在 PR #8139 之后已经移到 user turn 了，不是我说的那个问题。

但 system prompt 末尾确实还有一个动态块：provider_settings 里的 datetime_system_prompt: true 会在 system blocks 最后追加当前时间，我的实际请求 payload 最后一个 system block 就是：

所以 system_blocks[-1] 确实是动态的。我从反代侧的 usage stats 验证过——加了跳过逻辑后 cache_read 从 0 跳到 ~80%。

另外 #9388 我看过了，消息历史的 4 断点策略确实是更完整的方案。我先提个小 PR 把 system 层的断点修了，消息历史那边留给 #9388。

[dosubot]

感谢验证！你的反代数据（cache_read 从 0 跳到 ~80%）是最直接的证据，说明 system_blocks[-1] 确实存在动态内容导致 cache 断点失效的问题。

不过需要澄清一点：从代码来看，datetime_system_prompt: true 生成的时间信息实际上是写入 req.extra_user_content_parts（即 user turn），而不是直接注入 system blocks [1]。所以如果你的场景里 system_blocks[-1] 确实是动态的，可能是其他路径（插件注入、workspace extra prompt 等）往 system prompt 末尾追加了变化内容，值得在 PR 里一并排查一下实际来源。

小 PR 的建议：跳过条件用 block text 长度阈值（比如 < 200 chars）会比字符串匹配更健壮，避免硬编码语言相关的标记。大致逻辑：

for block in reversed(system_blocks):
    if isinstance(block, dict) and len(block.get("text", "")) >= 200:
        if "cache_control" not in block:
            block["cache_control"] = dict(cls._PROMPT_CACHE_CONTROL)
        break

这样即使末尾有多个短动态块也能正确跳过，落到实质性的静态内容上。另外 #9388 里也提到了断点应放在 _sanitize_assistant_messages 之后，以及原地修改 block 可能导致 cache_control 泄漏进持久化历史的问题 [2]，你的 PR 可以一并考虑。

期待你的 PR！

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.