参考: opencode-acp#368 (ranxianglei/opencode-acp#368) —— 同一问题，按 owner 要求在此仓库同步提交。
问题
在长会话中，compress/skill 携带的 assistant 消息上的 reasoning 部分构成一个永久不可压缩的上下文地板。
保护是消息粒度的：filterProtectedToolMessages 把整条消息——包括 reasoning——排除出所有压缩，因此这些消息每轮都被原样重发。每次压缩轮次增加约 9 KB 无法回收的 reasoning。在真实长会话中测量，这占"从未被覆盖的残留"的 ~83.5%，是一个单调递增的反馈回路，会持续恶化长会话的可用性。
机制（代码路径）
- 保护是消息粒度：整条消息（含 reasoning）被排除出压缩选择。
- 被排除的消息不进入
byMessageId，因此 prune 每轮都重发它们（reasoning 一并重发）。
compress/skill 是默认的 compress.protectedTools；compress 在 FORCE_COMPRESS_PROTECTED 中（强制追加，用户无法关闭）。- 真实 usage 计算包含 reasoning（
input + cacheRead + cacheWrite + output + reasoning）。
影响
- 长会话的上下文占用单调上涨，且这部分无法通过压缩回收。
- 显示 /
acp_status 的占用估算甚至不包含 reasoning，进一步掩盖了这个问题。
建议
在请求时增加一个 pass，从已关闭历史轮次的受保护豁免消息上剥离 reasoning 部分（保留当前开放轮次以兼容需要 reasoning 重放的 provider），并加 kill-switch 与大小阈值。opencode-acp 侧的修复见 PR #370。
参考: opencode-acp#368 (ranxianglei/opencode-acp#368) —— 同一问题，按 owner 要求在此仓库同步提交。
问题
在长会话中，
compress/skill携带的 assistant 消息上的reasoning部分构成一个永久不可压缩的上下文地板。保护是消息粒度的：
filterProtectedToolMessages把整条消息——包括 reasoning——排除出所有压缩，因此这些消息每轮都被原样重发。每次压缩轮次增加约 9 KB 无法回收的 reasoning。在真实长会话中测量，这占"从未被覆盖的残留"的 ~83.5%，是一个单调递增的反馈回路，会持续恶化长会话的可用性。机制（代码路径）
byMessageId，因此prune每轮都重发它们（reasoning 一并重发）。compress/skill是默认的compress.protectedTools；compress在FORCE_COMPRESS_PROTECTED中（强制追加，用户无法关闭）。input + cacheRead + cacheWrite + output + reasoning）。影响
acp_status的占用估算甚至不包含 reasoning，进一步掩盖了这个问题。建议
在请求时增加一个 pass，从已关闭历史轮次的受保护豁免消息上剥离 reasoning 部分（保留当前开放轮次以兼容需要 reasoning 重放的 provider），并加 kill-switch 与大小阈值。opencode-acp 侧的修复见 PR #370。