小窗口路由下 compaction 会持续失败：摘要调用跟随会话路由导致「压缩自锁」

[steven-stack-s]

长会话切到小窗口路由后，会以 pi-ai detected context overflow（CONTEXT_WINDOW_EXCEEDED）
每轮稳定失败。定位后发现问题不在模型，而在 compaction 的摘要请求本身也被同一个窗口限制住：

上下文超过窗口 → 需要压缩
   ↓ 摘要请求要复述整段历史，走的是同一条小窗口路由
摘要请求自己也超窗 → compaction/end 带 error
   ↓ 按文档「摘要失败则带着超预算历史继续」
上下文没有缩小 → 下一轮同样失败（确定性自锁）

为 compaction 配置一个独立的大窗口摘要模型后问题消失；同时把会话路由窗口切到该模型声明的 Max 值后，
上下文立刻回到窗口内。已有实际验证结果（见末节）。

环境

• DSH 0.1.6-alpha.2（@deepseek-ai/dsh-compaction-basic 同版本）
• profile：web 组合（bundle 含 dsh-base，即已挂载 compaction-basic + command-compact）
• 会话规模：约 116 轮、1.1 万条事件

[argszero]

This is the same defect as #5594 ("the summarization LLM call itself fails with context overflow"), re-reported on a small-window route — I analyzed that thread on 2026-09-04 (comment 18282109) and gave three fix directions and a regression invariant there. I re-verified the mechanism at HEAD today (c36a83ff6b, dsh-v0.1.7-alpha.1), because six compaction commits landed on 2026-09-18/19 and I wanted to be sure I was not describing an already-shipped fix as missing. Two of your dimensions hold, and the recent work covers a different shape.

Still unbounded at HEAD. The summarization request replays the whole shadowed region with no input-side bound. buildSummarizationInput (packages/compaction/compaction-basic/src/region.ts:544-563) maps every shadowed seq through deriveEventMessage and filters — no truncation, no slicing, no budget; summarizeWithLlm then spreads all of it (summarizer.ts:146, ...input.messages) in front of the instruction. So on a route whose window is smaller than the surface, the request that must shrink the surface is itself rejected by it. Nothing in the package bounds the input side.

What the 09-18/19 commits changed, and why it is not your case. 0fadb08fbd re-gated pressure on the message budget instead of the whole window (floor(min(W × 0.8, W − O − B)), README.md:62/:66). That fixed the inverse shape tracked in #1841: on a 1,000,000-token window with the default 256,000-token request reserve, the pressure gate sat at 800,000 while the provider rejected anything above ~792,576, so proactive compaction never fired and overflow recovery then tried to condense ~800k tokens into the summary cap. ec7030afd3 defaulted the summary output cap to the resolved headroom (config.ts:75-76, maxTokens ?? headroomTokens). Both are output/reserve arithmetic. Neither bounds the summarization input, so the small-window shape you report is unchanged at HEAD.

Your route-resolution reading is right, and it is the documented precedence. summarizeWithLlm resolves configured ?? latest durable route ?? AgentOptions (summarizer.ts:126-133), i.e. with no summarizationProvider/summarizationModel the summary call follows the session's last routed request — README.md:119 states exactly this. The escape hatch exists but nothing sets it: compaction-basic is mounted by the base bundle with no config (packages/bundle/base/cordis.patch.yml:340-341), and no bundle or preset sets the summarization pair, so the default really is "same route as the conversation".

The pressure path being unavailable on a small window is documented, not accidental — that is what makes the loop deterministic. README.md:78: "Small-window deployments must configure headroom that fits their capacity; lower thresholdRatio to compact earlier." README.md:115: "Missing capacity, output plus headroom exhausting the window, or a retained budget at least as large as the threshold makes the manual pressure path throw a target-specific configuration error. The automatic listener warns once for that exact target and skips proactive compaction until its configuration is corrected; provider-confirmed overflow recovery remains available." At HEAD the gate is W − O − B > 0 with B = headroomTokens defaulting to 65,536 (config.ts:75-76, README.md:66), and O the routed request's effective output reservation. Below that budget the only live path is overflow recovery — which is issued on the same route with the whole region as input. README.md:247 documents the other half of your loop from the other direction: a failed summary "preserves the latest durable surface", so the auto path proceeds with full over-budget history and the next turn fails identically.

One-step discriminator, so you can tell the two failure shapes apart. The auto listener emits a single warn per target when the pressure configuration cannot fit: step compaction failed: compaction-basic: <provider>/<model> reserves <O> completion tokens and <B> headroom tokens of its <W>-token context window, leaving no pressure budget; reduce the effective request maxTokens or compaction headroomTokens, or configure a larger adapter model contextWindow; continuing the turn (config.ts:174-190, warn + once-per-target suppression at index.ts:167-173, message assembled from TargetPressureConfigError). If that warn is absent and you instead see only a compaction/end carrying an error with no surface change plus a compaction/summary-error, the failure is the summary call's own overflow — my reading of your report — and the pressure configuration is not the thing to tune.

Two notes on the report itself.

First, it is truncated: the body is 550 characters and ends mid-list in the environment section (- 会话规模：约 116 轮、1.1 万条事件), while the text above it promises 已有实际验证结果（见末节）. The verification section never arrived — could you post it as a follow-up comment? The "switching the session route's window to the model's declared Max value brought the context back inside the window immediately" measurement is the part I most want to see: it reads like a distinction between the adapter's declared contextWindow and the route's effective request cap, and those two numbers are separate terms in W − O − B (W is the adapter-declared capacity, O is reservedCompletionTokens(agent, info.defaultMaxTokens) = the request envelope's own maxTokens else the adapter default, index.ts:65-68 / :316-317), so which one is mis-sized changes the fix.

Second, a correction to my own #5594 ruling. I closed that analysis with "core, not a plugin seam". At HEAD the mitigation half is mountable: GenerateOptions.purpose is set to 'compaction' for exactly this call (summarizer.ts:159, type at packages/llm/llm/src/types.ts:525), and the llm/stream waterfall hands listeners the original options with a terminal next() that closes over them (packages/llm/llm/src/index.ts:73, :1122) — so an out-of-tree plugin can observe a condensation call and re-issue it against a fallback route. That is a mitigation, not the fix: it still cannot make an over-window prefix fit, it only gives the retry a route that can take it. The fix stays core-side, in the fix directions from #5594 — ① bound the replayed prefix so the instruction plus a window-sized prefix always fits (keeps the warm-prefix reuse the design deliberately buys, summarizer.ts:26-30), ② reserve a summarization budget in resolveCompactSpec, which already resolves contextWindow, ③ a non-LLM truncation floor of last resort. Worth noting your workaround — a permanently configured summarizationProvider/summarizationModel — routes every condensation away from the session route and so forfeits that warm-prefix reuse on each call; re-issuing only when the primary attempt fails keeps the common case on the route that already has the prefix cached.

The invariant I proposed in #5594 still pins this: after a failed compaction the surface is unchanged (the error close appends no surface node), yet the session must remain able to run the next summarization — i.e. the summary call itself must never be the request that overflows. A test that seeds a surface above contextWindow and asserts the summarizer bounds its own input, rather than replaying everything, covers the shape you hit.

[argszero]

Follow-up to my analysis above: the plugin mitigation I described is now published.

@argszero/cordis-plugin-compaction-route-fallback@0.1.0 — npm · source

Mount it and name the route that has room:

- insert:
    - id: compaction-route-fallback
      name: '@argszero/cordis-plugin-compaction-route-fallback'
      config:
        provider: big-window-provider
        model: big-window-model

What it does about the self-lock in this report: it joins the public llm/stream waterfall and, for a call carrying purpose: 'compaction' (summarizer.ts:159) that settles with CONTEXT_WINDOW_EXCEEDED before any content chunk was emitted, withholds that terminal frame and re-issues the identical request — same messages, tools, cap and signal — on the configured route. Every other call takes the identity path.

That is the difference from your own workaround, which is otherwise the same idea: configuring summarizationProvider/summarizationModel sends every condensation away from the session route, forfeiting the warm prefix cache the summarization call deliberately reuses, while this plugin keeps the common condensation on the session route and falls back only for the call that provably cannot fit it. It also needs no profile edit — the fallback is config on the plugin row.

The boundaries are worth stating as plainly as the effect:

• It cannot bound the summarization input. The request is still buildSummarizationInput's verbatim replay of the shadowed region (region.ts:544-563); only the route serving it changes. The core fix from [BUG] deadlocks when surface exceeds the model window — the summarization LLM call itself fails with "context overflow", so the session can never compress (nor converse) again #5594 — bound the replayed prefix, or reserve a summarization budget in resolveCompactSpec — is still the fix. This plugin only means an operator with a larger-window route is not forced to self-lock, and is not forced to pin that route permanently.
• The durable record keeps naming the requested route. compaction-basic stamps provider/model on the compaction/summary event from its own request object (summarizer.ts:175-176), so after a fallback that event names the route that refused the request while the summary text and its usage came from the fallback. Every substitution is logged with both routes at warn level; if your audit needs the durable record itself to match, configure the summarization route statically instead — that path stays correct and this plugin is inert on it.
• It does not recover a stream that already emitted content and then failed, since the caller would assemble both attempts (pi-ai's usage-based overflow detection lands in that class by construction). It also routes on the finish code rather than provider wording, as dsh-llm requires, so an adapter reporting overflow under a different code is not covered.
• It acts only on purpose: 'compaction' calls, and never when the failing route is the configured one — that is also what bounds it to one fallback per call.

Evidence, since a plugin claiming to fix a report should be checkable: 25 tests against a real @deepseek-ai/cordis context and the published @deepseek-ai/dsh-llm runtime with stub adapters; the failing fixture is present as a control arm (unmounted, the same call reports CONTEXT_WINDOW_EXCEEDED to the caller), the common path is asserted to deliver a chunk while its route is still parked (no buffering), 9/9 mutations killed, the suite re-run green against 0.1.2-rc.1 / 0.1.3-alpha.2 / 0.1.5-alpha.1 / 0.1.6-alpha.1 / 0.1.7-alpha.1, and the packed artifact installed by name from the registry (byte-identical to the local build, no nested harness copy) running the same behaviour suite. observeOnly: true reports the fallback it would take without taking it — the safe way to confirm the trigger fires in your session before trusting it.

Your report's core observation stands unchanged, and the truncation note from my earlier comment still applies: the verification section the body promises never arrived, and the "switching the session route's window to the model's declared Max value" measurement is the one I would most like to see, because W (adapter-declared capacity) and O (the route's effective request cap) are separate terms.

[steven-stack-s]

谢谢——尤其感谢你把它接到 #5594、并在 HEAD（c36a83ff6b / dsh-v0.1.7-alpha.1）上重新验证过机制，而不是直接沿用旧结论。你的判断我先说结论：你的定位是对的，而且你请求的那组测量确实存在。
先说报告本身：你读得没错，原帖正文被截断了——GitHub 上只有 550 字符，在「环境」小节第三行就中断了，所以「观察到的数据」「已验证的解法」「验证小节」全都没发出去。下面补发，其中第二节正好回答你问的 W 与 O 的区分。

一、补发：被截断的数据

会话规模约 116 轮 / 1.1 万条事件（完整 JSONL 解压后逐条统计，不是抽样）。
contextPressure（token-meter 投影的最终值）：

{ "surfaceTokens": 529075, "pressureTokens": 659289, "contextWindow": 200000 }

compaction/end 全量分布（共 68 次事务，61 次失败）：

次数	compaction/end 的 error
34	pi-ai detected context overflow for model "DeepSeek-V4-Flash-Official"
21	pi-ai detected context overflow for model "gpt-6-astra"
2	OpenAI API error (403): insufficient balance
2	Request was aborted
1	gateway_concurrency_limit: Concurrency limit exceeded for account
1	OpenAI API error (403): 403 status code (no body)
7	成功（无 error）
即溢出导致的摘要失败占错误总数的约 90%（55/61）。按 turn 分布：
turn	start
---	---
10, 19, 26, 30, 35, 43, 44	各 1
45 – 99	0
100	3
101	5
102	14
103	1
104	1
105	6
106	8
107	3
108	1
109	2
110	7
111	5
112	3
113	2
turn 45–99 一次压缩都没有，这一段的含义放在第二条评论里讨论（它是理解触发入口的关键）。

二、你问的 W 与 O：改动的是 W；这条路由的 O = 0

这是你说「which one is mis-sized changes the fix」时最想要的那组测量，结论很明确。
改动的是 W（adapter 声明的 contextWindow）——通过 provider 插件的 contextBudgets，把它从 Trae 公布的 dev 窗口切到同一模型自己声明的 Max 窗口。会话记录里的前后两行：

seq 10913  request/context {"provider":"trae","model":"DeepSeek-V4-Flash-Official","contextWindow":200000}
   ↓ 配置 contextBudgets 后重启
seq 11243  request/context {"provider":"trae","model":"DeepSeek-V4-Flash-Official","contextWindow":1000000}

O 没有变，而且在这条路由上 O = 0。 依据是 reservedCompletionTokens 的实现——"No declared cap means no reservation"：

agent.session.requestHeader()?.config.maxTokens ?? defaultMaxTokens ?? 0

这条会话的 request/header 里，两个路由的形态正好对照：

route: trae/DeepSeek-V4-Flash-Official    config.maxTokens: undefined   adapterDefaults: undefined
route: deepseek-official/deepseek-flash   config.maxTokens: 256000      adapterDefaults: {"maxTokens":true}

trae 路由既没有在请求信封上设 maxTokens，也没有 adapter 级默认（该插件的 configuredMaxTokens 是空 Map），所以三项全空 → O = 0。
代入你引用的门控：W − O − B = 200000 − 0 − 65536 = 134464 > 0。
thresholdTokens = floor(min(W × 0.8, W − O − B)) = floor(min(160000, 134464)) = 134464。
这个数字在第二条评论里是关键——它意味着压力路径并没有因为小窗口而失效。

三、验证小节（原帖承诺但没发出去的部分）

把该路由窗口从 dev 的 200000 切到 Max 的 1000000 后重启（配置层改动，无需改代码）：

验证项	结果
窗口是否切换	✅ request/context 由 200000 → 1000000
溢出死锁是否解除	✅ surface 52.9 万随即可容纳，不再触发压缩（低于阈值，符合预期）
会话是否恢复	✅ 后续回合 turn/end {"kind":"completed"} 正常完成
配置校验	✅ YAML 解析 + 字段 schema 通过；applyContextBudgets 按严格相等判断，须填模型声明的 maxContextWindow
剩余故障	另有 provider 侧 429 soft_rate 与一次 Stream ended without finish_reason，与本问题无关
需要说明的是，这一步只改变了 W：它让 session surface 重新落回窗口内，因此连压缩都不再被触发——
它是「把既成事实的越界状态恢复回来」，不是对摘要输入侧的任何修复。完整事件流 JSONL 我保留了，
如果你要 seed 一个「高于 contextWindow 的 surface」做 fixture，这份数据里的
surfaceTokens / thresholdTokens / compaction/end 序列可以直接当参照。