上下文与自动压缩

模型每次请求能装的内容有上限，Klaus 的算法是：

• 有效窗口 = 模型上下文窗口 − 输出预留（窗口默认按 20 万 token 算，预留默认 2 万，且预留不超过模型允许的单次输出上限）。
• 压缩触发线 = 有效窗口 − 1.3 万 token 的绝对预留。留绝对量而不是百分比，是因为触发时要腾出的东西（这一轮的回复加摘要请求本身）是固定开销，窗口再大也不会变多；按比例留会让大窗口白白浪费掉几十万 token。
• 到线：历史被换成摘要，对话继续。

按占用触发的默认只有「到线」这一档，而这一次是要等的——长会话跑到某个点忽然卡一下再继续，那一下就是它。另外还有三级提前动作，界面上都没有开关（只能改引擎配置）；前两级默认关着，第三级默认开着：

• 提前轻量清理：到了「触发线 − 有效窗口的 15%」就丢掉早期工具输出的正文。清理后必须降到「触发线 − 有效窗口的 5%」才算够，否则还是升级为完整压缩。
• 后台预先摘要：到了「触发线 − 有效窗口的 7%」就在后台先把摘要算出来，真到线时不必阻塞等待。
• 空闲期微清理（默认开）：一条会话冷下来超过 60 分钟再发下一条时，先把旧的工具结果清掉（保留最近 5 条原文）。间隔阈值按各家供应商最长的提示缓存寿命取，所以这一下永远不会造成一次本来不会发生的缓存未命中。

输入区旁那个上下文用量圆饼对应三档：正常、达到触发线 85% 显示接近上限、到线显示超限。

两个熔断

压缩反复失败或反复白做都是真实的坑，所以除了上面的阈值还有两道保护：

• 没进展就熔断：一次压缩只有在把占用降到原来的 99% 以下才算「真降了」——清掉一个本来就很小的结果这种毛毛雨不算。连续三次压缩都没有实质进展，熔断器跳闸，不再白耗模型调用。
• 快速回填抖动熔断：另一种失败形态是压缩确实成功了（真的腾出了 token，所以上一道熔断不会跳），但上下文在两三轮内又爬回触发线——因为同一个超大输入（一个巨大的文件、一个巨大的工具结果）在被反复读。一次压缩必须「按住」上下文低于线三轮才算健康，没按住就是一次快速回填；连着三次跳闸，回合带一个可补救的错误停下来，而不是把整轮预算烧在背靠背的压缩上。