Repository navigation
Context compression capability will not be triggered automatically. #4360
Description
What happened
The underlying system actually has "manual compression" and "context diagnostics" capabilities; the main problem is that these capabilities are not exposed in the sending area and are not automatically triggered during high water levels.
How to reproduce
1、上下文窗口占满出现提示
Environment
- source build
Logs, screenshots, or additional context
No response
Activity
[-]底层其实具备“手动压缩”和“上下文诊断”能力，问题主要是没有在发送区暴露，也没有在高水位时自动触发[/-][+]Context compression capability will not be triggered automatically.[/+]andotorg commentedon Sep 1, 2026
andotorg commentedon Sep 1, 2026
ggbdpq commentedon Sep 4, 2026
对照当前 main（22715e84f）核实了一下，这个 issue 描述的两个问题在最新代码里都已经有解了：
1. 高水位自动压缩——已随 #4348（2026-08-31，和本 issue 同一天提交）落地：mid-turn 容量触发会以
context_limit为原因自动发起 history compaction；随后 #4486（09-02）把估算锚定到真实 provider usage，#4653（09-03）改为由 provider 决定容量判定。另一份带生产数据的报告 #4634 也证实触发器现在会正常开火。2. 手动压缩入口——两个 surface 都有
/compact：桌面端 composer（#2612，08-10 起）和 CLI/TUI 的 slash 命令（pi-tui-runner.ts，Usage: /compact）。你的环境写的是 source build 但没有提交号——大概率早于 #4348。麻烦：
如果更新后仍有问题，请附上 build commit 和 surface（desktop / TUI），我们再继续排查。
Astro-Han commentedon Sep 17, 2026
Proactive high-water compaction landed in #4348 (
36f058c90): a mid-turn capacity trigger now starts history compaction withreason: 'context_limit'(packages/runtime/src/ai-sdk-compaction.ts:891and:948), and #4486 and #4653 later moved the capacity judgement onto real provider usage. Manual/compactis available in both the Desktop composer and the CLI/TUI slash commands. The source build in the report predates those changes. Closing as fixed; if compaction is attempted on your provider but fails open, that case is tracked in #4634 and your model and connection details are welcome there.