compaction-basic: default thresholdRatio 0.8 can never trigger when the per-request output reserve is large (sessions die before first compaction)

[nicecx]

现象

长会话（消息量约 79 万 token）在完成任何自动压缩之前，就直接收到上游 max-context 报错而死；会话记录中从未出现任何 compaction/start / compaction/summary。

环境

• dsh 0.1.5-rc.2（dsh --profile web；我们在此版本上运行长驻 agent 会话）
• 模型 deepseek-flash：context window 1,048,576；每次请求默认携带 maxTokens=256,000（输出预留）
• 实测报错样例（原文）：
  • This model's maximum context length is 1048576 tokens. However, you requested 1048596 tokens (792596 in the messages, 256000 in the completion)
  • ...requested 1055000 tokens (799000 in the messages, 256000 in the completion)

数值分析

• 有效输入上限 = 1,048,576 − 256,000 = 792,576（≈ window 的 75.6%；按显示口径 1,000,000 ≈ 79.26%）
• compaction-basic 默认 thresholdRatio: 0.8 ⇒ 触发点：
  • 按 1,048,576 计 = 838,860 > 792,576（不可达）
  • 按 1,000,000 计 = 800,000 > 792,576（仍不可达，差 7,424 tokens）
• ⇒ 在大输出预留（256K）下，默认阈值永远无法在死线前触发；先撞死线，压缩永远轮不到。

证据

• 两个长会话的完整会话记录（约 8.8MB / 8.1MB）：compaction 相关出现 0 次；终结均为上述硬溢出报错。
• 我们已在自家部署将 thresholdRatio 调整为 0.65 作为缓解（本 issue 供上游参考默认值行为）。

建议（供参考）

1. 触发条件与输出预留挂钩，例如 min(thresholdRatio × window, window − maxOutputReserve − margin)；或
2. 下调默认值（如 0.65–0.7）；或
3. 在文档中明确：大输出预留模型需自行调低 thresholdRatio（Dev Note 亦提到默认比例 no corpus-backed guidance）。

附注（观察，供确认）

packages/bundle/web-app 的补丁将 compaction-basic / command-compact / tool-result-pruner 置为 disabled: true（注释称 moved to host plane）。在我们部署的最终组合树（dsh --profile web --dump-config）中三者仍为 disabled: true 且未见替代挂载——不确定是预期行为还是我们缺了某个环节，一并反馈。

[PerryLink]

你的数值分析在 master（c291e7961）成立，逐行核对如下：

• 压力触发不扣输出预留：resolveCompactSpec 的 thresholdTokens = floor(contextWindow × thresholdRatio)（packages/compaction/compaction-basic/src/config.ts:144），不涉及 maxTokens/预留；压力判定只比较消息估值与阈值（compaction-basic/src/index.ts:304-305）。
• 默认 DEFAULT_THRESHOLD_RATIO = 0.8（config.ts:20）；deepseek 适配器默认 DEFAULT_CONTEXT_WINDOW = 1_000_000、DEFAULT_MAX_TOKENS = 256_000（packages/llm/llm-deepseek/src/adapter.ts:147,149），目录里的 deepseek-flash 用默认值（llm-deepseek/src/index.ts:92-101）。
• 算账：0.8 × 1,000,000 = 800,000。即便按最宽松的 256K 输出预留（1,000,000 − 256,000 = 744,000），800,000 也在死线之上——会话先死、压缩永不触发。与你的结论一致。
• 你提的"预留挂钩"在源码里不存在（config.ts:133-167 的 resolveCompactSpec 无该字段）；方案 3（文档化调优）也有官方背书缺口：README.zh.md 明确写"默认比例尚未决定"（README.zh.md:254）。

即时缓解：用 modelPolicies 按模型覆盖 thresholdRatio（config.ts:105-125），对 1M/256K 组合设 0.65 或更低（0.65×1M=650,000 < 744,000，可触发）；或按你的方案 1 给 upstream 提"压力判定纳入输出预留"。

附注同 #6672 一并说明：host 树禁用 compaction-basic 是预期（packages/bundle/web-app/cordis.patch.yml:427-434），替代挂载在 preset 隔离域（packages/preset/agent-presets/presets/standard/agent.cordis.yml:138-156），你的部署树需确认挂载了它——#6672 的"0 次压缩"很可能与此同根。

[nicecx]

感谢逐行核对，两点补充：

1. 你在附注里问的"部署树是否挂载 preset 组"：已确认挂载（host 平面与 preset 隔离域两个实例都在，实测）。
2. 除"阈值不可达"外，我们还发现一个更早的静默出口：适配器契约缺口使 measure() 先抛错，事务前退出、仅 warn 且不可见——完整复现与修复建议已写在另一帖的回复里（见 Overflow recovery produced no compaction attempt after CONTEXT_WINDOW_EXCEEDED (no compaction/start recorded; session stays dead) #6672）。所以两帖现象同根没错，但不止"部署问题"一层：挂载是正常的，真正的是 (a) 域内默认 0.8 不可达 ＋ (b) 该契约缺口。
3. 0.65 的缓解我们已实测生效（与你算的口径一致：0.65×1M=650,000 < 744,000）；modelPolicies 的官方写法记下，感谢。

[PerryLink]

补一条引用更正（结论不变）：master 上这两个默认值已经搬过家，packages/llm/llm-deepseek/src/adapter.ts 现只剩 58 行，不再定义这两个常量。新位置：

• packages/llm/llm-deepseek/src/common/defaults.ts:6 → DEFAULT_CONTEXT_WINDOW = 1_000_000
• packages/llm/llm-deepseek/src/common/defaults.ts:8 → DEFAULT_MAX_TOKENS = 256_000（注释 "Default per-request output-token cap"）
• deepseek-flash 的目录条目：packages/llm/llm-deepseek/src/common/models.ts:8-13（:10 用 DEFAULT_CONTEXT_WINDOW，未设 maxTokens → 取默认 256_000）

数值一字未改，所以 0.8 × 1,000,000 = 800,000 > 1,000,000 − 256,000 = 744,000 的结论、以及"压力判定不吃输出预留"（packages/compaction/compaction-basic/src/config.ts:144）仍然成立。

本文其他几处行号也已位移（结论不变）：压力判定 packages/compaction/compaction-basic/src/index.ts:304-305 → :300-301；packages/compaction/compaction-basic/README.zh.md:254 → :256；packages/bundle/web-app/cordis.patch.yml:427-434 → :432-439（compaction-basic 行在 :432）。

[PerryLink]

再补一条引用更正（结论不变）：上一条把 packages/bundle/web-app/cordis.patch.yml 的禁用块刷成 :432-439（"compaction-basic 行在 :432"），这个目标也已经过期。当前 dsh-v0.1.6-alpha.2（ddefc45fb）上这三行分别是：

• :456 - id: compaction-basic
• :459 - id: command-compact
• :462 - id: tool-result-pruner

（各自的下一行是 disabled: true。）而 :432 现在是 :431 - id: skill-filesystem 那一行的 disabled: true——照旧引用会指到别的插件。

另两处小修：

• 压力判定在 packages/compaction/compaction-basic/src/index.ts 里是 :301 与 :309 两处 if (measurement.totalTokens < spec.thresholdTokens) return null，不是 :300-301。
• packages/compaction/compaction-basic/README.zh.md 的「默认比例，尚未决定」在 c291e7961 上是 :254、在 0d1f5000 与 HEAD 上都是 :256；也就是说 254 并没有"位移"到 256，那是两个基线的对照，不是同一基线上的移动。

默认值与算式不变，仍然成立：compaction-basic/src/config.ts:20 是 DEFAULT_THRESHOLD_RATIO = 0.8，packages/llm/llm-deepseek/src/common/defaults.ts:6 / :8 是 1_000_000 / 256_000，config.ts:144 的 thresholdTokens 不含输出预留，所以 0.8 × 1,000,000 = 800,000 > 744,000 的结论照旧。

[gorban]

A concrete instance of "the ratio is applied to a capacity the provider does not admit", with a second multiplier on top: in the session I measured, the window used for the ratios was 4× too small.

session-2496881f-8d36-4ce6-93d9-1954a31930c7, dsh 0.1.6-alpha.2, openrouter/deepseek/deepseek-v4.1-flash:

quantity	value
harness-resolved window (request/context)	262,144
provider-declared window (OpenRouter /api/v1/models)	1,048,576
thresholdTokens = 0.8 × resolved	209,715
retainTokens = 0.16 × resolved	41,943
largest prompt the route actually completed normally	283,268 tokens (tool_calls)
prompt at which it began failing	287,113 tokens (finish_reason: length, 1 token out)

The model entry in settings.yaml declares only id/name, so llm-pi-ai silently applies DEFAULT_CONTEXT_WINDOW = 262_144. Another route on the same profile resolved to 1,024,000, so the disagreement is visible within a single session's log.

In this case the wrong window made compaction fire early rather than never, so it is not a duplicate of the reserve problem — but it shows the same class of defect: the ratio is scaled against a number that is neither the provider's declared window nor the prompt capacity the provider accepts. Fixing the reserve without fixing the window still leaves the threshold anchored to the wrong capacity.

Reported separately: #7213

Evidence: https://gist.github.com/gorban/4725c87390cb391047a2f14b56b98d28

[mengge237]

同一处算式，我这台撞的是反方向：喂进算式的 capacity 比路由真实容量小一个数量级，而且那个小值是静默回退来的 —— 报大了永远不触发（这条线在讨论的），报小了会疯狂误触发并把自己夹死。补个对照读数。

这条线的形状是「比例套在 provider 不认的容量上」（窗口 1,048,576、阈值 0.8 出 838,860，而请求默认已带 256,000 输出预留，provider 先到墙）。我这台的形状：配置里这个 provider 只写了 id 和 name（手声明路由，pi-ai 自带目录里没有这一条），于是解析链 entry.contextWindow ?? base?.contextWindow ?? request.defaultContextWindow（@deepseek-ai/dsh-llm-pi-ai 0.1.5-rc.2 的 lib/index.js:670）落到内置常量 DEFAULT_CONTEXT_WINDOW = 262144（同文件 :893），而同一 baseURL 在 pi-ai 自带目录里的 8 个模型全部写着 1000000。

后果是三件事同时坏，症状看起来互不相关：

1. @earendil-works/pi-ai 0.85.1 的 dist/api/simple-options.js:4-9 里 clampMaxTokensToContext = min(maxTokens, max(1, contextWindow − 预估 − 4096))，window 取 262144 → 会话撑到 26 万附近时 max_tokens 被夹成 1，模型每回合只回一个 token，turn/end.reason.kind=max-tokens；
2. 同一个 262144 让压缩把正常回复判成 pi-ai detected context overflow，于是开始尝试压缩；
3. 总结请求本身也被同一个窗口夹，输出撞内置 maxTokens: 8192 截断，判 incomplete checkpoint 直接 fail-closed —— 所以表现为「压不动」。

一份会话里 11 次压缩只落地 1 次，就是这三件叠出来的（逐项计数见 #6672 我补的那条）。两半合起来才是完整形状：只要喂进这些算式的 capacity 不是 provider 确认的那一个，阈值和输出预算会朝两个相反的方向坏；两边缺的是同一样东西 —— 读不到「这个数现在是多少、从哪来」。

不改装也能自查的口径：会话存档里 request/context 事件的 contextWindow 就是算式真正在用的那个值，拿它跟 provider 给的容量比，不等即命中这一类；配置侧用 dsh --profile web --dump-config 看合成后的树（它连哪一层覆盖了哪一行都打出来）。

修的方向我倾向「别静默」：手声明路由缺 capacity 时，要么启动就报错、要么至少留一条 warn，而不是回退到一个内置常量 —— 报大了只是不压缩，报小了把输出预算和总结一起打死，代价不对称。

版本：运行时 0.1.5-rc.2（发帖时 npm latest）；行号按该版本产物读，master tip 0010283（2026-09-22T15:25Z）里 packages/session/session-stats/src/projection.ts 的 SessionStatsTotals 仍只有 turns / steps 那一族，没有压缩维度。