issue: context compaction injects the summary into the system role, invalidating the provider prompt cache for tools + system prompt on ever

问题场景

用户在 Open WebUI 中启用 Context Compaction，并连接带有 prompt caching 的 Anthropic Claude 模型（经 OpenAI 兼容代理转发，如 LiteLLM → Bedrock 或 Anthropic）。当对话超过 token 阈值触发压缩——包括工具循环内触发的压缩——压缩摘要会以 system role 消息的形式注入请求，用户因此观察到供应商侧的缓存创建量与读取量异常。

报错原文

issue: context compaction injects the summary into the system role, invalidating the provider prompt cache for tools + system prompt on ever

Issue 中描述的实际表现：

The summary lands inside the system section. The cached tools + system prefix misses, and the whole prefix is written again, even when the previous cache entry is still well inside its TTL.

原因分析

压缩摘要的注入位置与供应商缓存前缀的划分方式不匹配：

• 轮次开始时（utils/middleware.py，dev 约 L2173），通过 add_or_update_system_message(f'[CONVERSATION SUMMARY]\n{context_summary}', ..., append=True) 把摘要追加到聊天的 system message 中。
• 工具循环中（utils/middleware.py，dev 约 L6021–6027），摘要被作为独立的 {'role': 'system', ...} 消息插入到索引 1、即已有 system message 之后。
• 支持前缀缓存的供应商把 system 内容视为前置缓存前缀的一部分。Anthropic 的顺序是 tools → system → messages，因此 system 内容的任何变化都会改变包含 system prompt 与工具定义的那段前缀。
• 即使摘要作为“独立”system 消息存在，OpenAI 兼容 → Anthropic/Bedrock 的转换层也会把前导的所有 system-role 消息合并进同一个 system 段。例如 LiteLLM 的 Bedrock Converse 转换（_transform_system_message）会把每条前导 system 消息提升进 system content-block 数组，摘要最终仍落在 system 段内。

维护者在讨论中给出的补充判断是：该摘要随聊天保存，两次压缩之间保持不变，因此只在压缩发生的那一轮产生一次缓存写入，而非每个请求都丢失缓存；同时压缩本身已经替换了对话部分，system 段之后的缓存本来就会失效。据此该行为被判定为 expected behaviour，Issue 关闭。

相关历史：#26710（经 #26713 / #26727 修复）涉及压缩覆盖 system prompt 的问题，本 Issue 只讨论摘要应放在哪里，不主张撤回该修复；#28527 则是 {{CURRENT_TIME}} / {{CURRENT_DATETIME}} 导致的同类 system 内容变动问题。

环境排查

• 确认 Open WebUI 版本（Issue 报告于 v0.12.4，并称最新 release 与 dev 分支均可复现）；Issue 未给出其他已确认版本。
• 确认安装方式（Issue 使用 Docker）。
• 确认操作系统（Issue 使用 Ubuntu 24.04）。
• 确认是否经 OpenAI 兼容代理接入 Anthropic/Bedrock，并核对代理侧的 system 消息合并逻辑。
• 确认供应商侧 prompt caching 是否启用、缓存断点位置（工具定义之后还是 system 段末尾）以及缓存 TTL。
• 确认 Context Compaction 是否开启、token 阈值设置，以及是否在工具循环内触发压缩。
• Issue 未提供 Python、CUDA、PyTorch、显卡、Ollama 版本，无需据此排查。

解决步骤

1. 先确认现象范围：对比压缩前后请求的 cache_creation_input_tokens 与 cache_read_input_tokens。如果只有压缩那一轮出现缓存写入激增、其余轮次正常读取，说明符合维护者描述的预期行为，而非逐请求失效。
2. 检查稳定前缀的大小与压缩触发频率。压缩越频繁、system prompt 与工具定义越长，每次压缩带来的重复缓存写入成本越高。
3. 在代理或供应商侧调整缓存断点位置（可优先尝试）：将断点放在工具定义之后而非 system 段末尾，使 system 内容变化时工具前缀仍可命中。
4. 减少 system 内容的非必要变动（可优先尝试）：例如关闭 {{CURRENT_TIME}} / {{CURRENT_DATETIME}} 这类每请求变化的占位符，避免在前缀中引入额外变动。该方向参考 #28527，未在本 Issue 中验证。
5. 若仍认为需把压缩摘要移出 system role，属于功能变更，需另开 Issue 讨论；本 Issue 未提供已验证的配置或代码修复方案。

验证方法

在开启 prompt caching 与 Context Compaction 的条件下，对比压缩前后若干轮请求的供应商用量：确认两次压缩之间各轮次能稳定读取缓存（cache_read_input_tokens 正常增长），仅在压缩发生的那一轮出现一次前缀重写（cache_creation_input_tokens 上升）。若调整了缓存断点或移除了时间占位符，还应确认 system prompt 与工具定义在相邻请求间保持字节一致（byte-identical）。

参考来源

open-webui/open-webui #33319

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。