[Bug] 从大上下文窗口模型切到小窗口模型会卡死：压缩阈值随目标窗口重算，而摘要请求仍发往该小窗口模型，于是压缩请求自己也超限

[dingminhua]

[Bug] 从大上下文窗口模型切到小窗口模型会卡死：压缩阈值随目标窗口重算，而摘要请求仍发往该小窗口模型，于是压缩请求自己也超限

先说与 #9784 的关系（避免被当成重复）

#9784 报的是同一个 configured ?? latest ?? agentTarget 解析链，但根因不同：#9784 是 latest 指向一个已被删除的 provider（可用性问题）；本条是 provider 完全有效、窗口容量不够（容量问题）。即使把 #9784 建议的"可用性校验"全部实现，本条依然存在 —— 因为这里的 provider 是可用的，请求也确实发出去了，只是装不下。

两者的共同点是"摘要请求的命运被 latest 决定"，所以修法可以共用一处（下见建议一），但触发条件、复现步骤与用户可见现象都不同。

环境

项	值
DSH	0.2.0-rc.2（桌面端）
相关包	@deepseek-ai/dsh-compaction-basic、@deepseek-ai/dsh-compaction
触发缺陷的插件	dsh-connect-workbuddy（第三方 provider 插件，如实声明每个模型的 contextWindow）
区域	两个 provider 同时启用（国内 / 国际），各有独立账号
会话规模	41 轮、约 8000 条事件的长会话

现象

在一个大窗口模型（1M）上跑了一段长会话（历史约 500K token），**直接切换到一个小窗口模型（200K）**之后：

• 每一个请求都以 400 失败（上游业务码 11115，即上下文超限）；
• /compact 也失败 —— 于是没有任何自救路径；
• 用户实测卡死 4.6 小时（第 246 分钟首次超限 → 第 524 分钟才靠"切回大窗口模型"压缩成功）。

可恢复的操作是存在的，但只能靠用户自己想到：先切回同样是大窗口的模型压一次，压完再切到小窗口模型。

根因（两半，都在 0.2.0-rc.2 发布包里核实过）

A. 压缩阈值随目标模型的窗口重算

@deepseek-ai/dsh-compaction-basic → index.ts（agent/pre-step 路径，:304 / :314）：

const info = await this.ctx.llm.resolveModelInfo(target.provider, target.model, signal)
const spec = resolveCompactSpec(policy, info.context.contextWindow, reservedCompletionTokens(agent, info.defaultMaxTokens))
if (measurement.totalTokens < spec.thresholdTokens) return null

而 config.ts（:191）：

const thresholdTokens = Math.floor(Math.min(
  contextWindow * policy.thresholdRatio,
  pressureBudgetTokens            // = contextWindow - reservedCompletion - headroomTokens
))

⇒ 窗口从 1M 换成 200K 时，阈值当场塌下来（min(200K × ratio, …)），而历史一动没动，于是立刻判定超限。这一步本身是正确的 —— 历史确实装不进新窗口，本来就该压缩。

B. 但摘要请求发往的就是那个装不下的小窗口模型

同包 → summarizer.ts（:127-137）：

const latest = agent.session.requestHeader()?.config
const configured = config.summarizationProvider.length === 0 ? undefined : { provider, model }
const agentTarget = agent.options.provider !== undefined && ... ? { provider, model } : undefined
const target = configured ?? latest ?? agentTarget      // ← 未配置时 = 本会话当前模型

摘要请求携带全部待压缩的历史（input.messages 原样作为 messages 发出）。所以切到 200K 模型之后，这个请求和普通请求撞的是同一堵墙：阈值把它判定为"该压缩了"，而它自己就是压缩请求 —— 越超限越压不动，越压不动越超限。

C. 自动路径还会把失败静默吞掉，所以用户看不到真正的原因

index.ts:172：

} catch (error) {
  ...
  ctx.logger.warn(`step compaction failed: ${message}; continuing the turn`)
}

自动压缩失败后继续这一轮，于是用户看到的是模型返回的 400 / 11115（一个"上下文超限"），而不是"压缩失败了" —— 两个错误指向完全不同的处置，而界面上只有后者。

复现步骤

1. 选一个大上下文窗口的模型（如 1M），开一个会话并累积到约 500K token（长会话 + 工具调用）。
2. 直接切换到一个配置为 200K 窗口的模型（不要经过压缩）。
3. 随便发一条消息 → 400；输入 /compact → 同样失败。

预期：切换前（或压缩调度入口）判断"当前历史装不装得下目标窗口"；装不下就先用装得下的大窗口模型压一次，压完再切。或者至少把真正的原因（摘要请求超限）显示出来。

实际：每一个请求都失败，压缩也失败，没有任何界面信息指向"摘要请求本身超限"。

建议（按优先级）

1. 摘要目标要落在"装得下"的模型上（这条同时也能覆盖 [Bug] provider 被删改后，旧会话 /compact 永久失败，且真错被吞进会话日志 #9784）。当 requestHeader() 解析出的目标窗口小于当前所需时，不要把摘要请求发给它 —— 可以退到 agentTarget、或配置里指定的 summarization*、或目录中任一窗口足够的模型。
2. 把 C 的静默吞掉改成可见。自动压缩失败至少应该让这一轮的失败原因里带上"压缩失败"，而不是伪装成一次普通的上游超限 —— 否则用户唯一的入手点是翻会话日志。
3. （可选）切换模型时做一次容量检查。如果新模型的窗口小于当前历史，先触发压缩（在旧模型上）再切换，这样用户根本不会走到死锁。

目前的规避办法

在 profile patch 里把摘要目标钉死在一个大窗口模型上，让它与会话当前模型解耦：

- id: compaction-basic
  config:
    summarizationProvider: <provider>
    summarizationModel: <大窗口模型>

另可把各模型的 contextBudgets 调低，让压缩更早触发（降低概率）。但这两个都只是规避：只要历史已经超过目标窗口，切过去仍然死锁，因为问题在"摘要请求自身装不下"，不在触发时机。

[argszero]

Verified against the source at master (86a402200d, dsh 0.2.1-alpha.4) — the same two halves you measured on 0.2.0-rc.2.

Your half B is the part a configuration workaround cannot fix, and the reason yours is honest about being one: summarizer.ts:137 resolves configured ?? latest ?? agentTarget and never asks whether the resolved target fits, while the request it sends at :163 carries the whole history. Pinning summarizationProvider only holds while the pinned route is large enough.

I built the plugin half of your suggestion 1 and published it:

@argszero/dsh-compaction-target-guard 0.1.0 — npm · source (MIT)

It listens on the llm/stream waterfall, where a compaction call already arrives tagged purpose: 'compaction' (summarizer.ts:160). When such a call ends in a terminal failure carrying the harness's own CONTEXT_WINDOW_EXCEEDED code — the same discriminator compaction-basic/src/index.ts:194 branches on — it asks the runtime's catalogue (listProviders() / listModels() / resolveModelInfo()) which registered routes declare a larger contextWindow, and re-dispatches the identical request to the largest one first, up to maxAttempts. That is your "fall back to any model in the catalogue whose window is big enough", without editing the harness.

• A larger route answers → the caller gets that stream, and the summary does not depend on the route that refused it.
• No larger route answers → the caller gets its own failure back unchanged (same chunks, same code) with one sentence appended naming the capacity cause.

That appended sentence reaches the log half of your suggestion 2: summarizer.ts maps a terminal failure to new LlmError(finish.failure.message, …) and throws it, so index.ts:172 prints step compaction failed: <your message> [compaction-target-guard: the summarization request itself was refused for capacity by "p/m", which declares a window of N tokens; …]. The UI half is not reachable from a plugin: what a turn displays is the harness's decision.

Mount (shipped as the package's own cordis.patch.yml):

- insert:
    - id: compaction-target-guard
      name: '@argszero/dsh-compaction-target-guard'
      config:
        mode: reroute        # or `observe`: decide and log, dispatch nothing
        maxAttempts: 2
        allowProviders: []   # narrow to one vendor if a summary must not leave it

Three limits, stated plainly:

1. It does not predict capacity — only a summary already refused is re-routed, so the first attempt on an undersized route is still paid. A plugin that intercepted before the refusal would be choosing a model for the operator.
2. Re-routing is also a disclosure: the replacement carries the same conversation prefix, so the provider that owns the alternative route sees that history. That is what allowProviders / denyProviders are for.
3. It only acts on the harness's own classification. A provider whose wording the adapter does not recognize is never classified CONTEXT_WINDOW_EXCEEDED, so nothing is attempted.

When the catalogue has no larger route at all, this plugin can only name the cause. For that case @argszero/dsh-overflow-recovery (also mine) drops history without a model on agent/request-error, so the turn can still proceed. The two are complements, not duplicates: try the model-based summary while some route can hold it, fall back to no model when none can.

Your suggestion 3 (a capacity check at the moment of the switch) is outside this plugin's reach: it acts on a summary that has already been refused, not on the switch. And the preventive form of suggestion 1 — pick a large route before the switch — is a decision about which model answers, which is the operator's call, not a plugin's.

Verification, in case it is useful for judging whether to install it: 42 tests against a real cordis context, the real LlmRuntime, the real llm/stream waterfall and a real registered adapter; every assertion made on what the caller received and on what the adapter was actually asked to stream, never on the plugin's own report; 21 mutation arms, each removing one distinction (the capacity discriminator, the purpose tag, the identity guard on the re-dispatch, the strictly-larger rule, the maxAttempts cap, the configuration resolutions) and required to make the suite fail — 20 caught, 1 declared equivalent; and the suite green on 0.1.7-rc.2, 0.2.0-rc.2, 0.2.1-alpha.3 and 0.2.1-alpha.4.

[dingminhua]

@argszero 谢谢 —— 在回复之前我把你的说法独立复核了一遍。先报结论，再报依据。

我在这台机器上重新跑出来的（不是采信描述）

项	我的结果
summarizer.ts:137 / :160 / :163、index.ts:194 四处引用	与 0.2.0-rc.2 源码逐字一致（我在本地 0.2.0-rc.2 检出上核对）
日志回路	index.ts:172 的 step compaction failed: ${message} ＋ summarizer.ts:201 的 new LlmError(finish.failure.message, finish.failure.code, …) —— 追加句确实会进日志，且 code 未被改动
套件	42 例 / 11 组，42 pass / 0 fail
接缝是否为真	是：真 cordis.Context、真 LlmRuntime、经 ctx.llm.registerAdapter() 注册的真 adapter，走 ctx.llm.stream() 的 llm/stream waterfall —— 不是 mock
变异	20/21 caught，1 declared equivalent，0 silent，与你的数字一致
与你声明的宿主矩阵	用 dsh-llm@0.2.0-rc.2 + cordis@4.0.4（我实际在用的那一对）重跑：42/42 通过
包本身	无 runtime 依赖、@deepseek-ai/* 全为 type-only import —— 由 invariant.spec.mjs 钉住，我核过

那条 declared-equivalent 我看了理由，同意它是不可达的：failed route 被「必须声明窗口」与「strictly-larger」两条规则挡在候选之外，在确定性 resolver 上即使重排也改不了结果。把它报出来而不是藏起来，是这套 harness 里我最信的一处。

两条你可能想知道的

一、你声明的宿主矩阵，我自己复现不出来（不是套件的问题，是 devDependency 配对）

$ npm install @deepseek-ai/dsh-llm@0.2.0-rc.2
npm error code ERESOLVE
npm error Could not resolve dependency:
npm error peer @deepseek-ai/cordis@"~4.0.4" from @deepseek-ai/dsh-llm@0.2.0-rc.2
npm error Found: @deepseek-ai/cordis@4.0.5-alpha.2

package.json 把 @deepseek-ai/cordis 钉在 4.0.5-alpha.2，而 0.2.0-rc.2 那一代 dsh-llm 的 peer 是 ~4.0.4。必须先 --legacy-peer-deps 并把 cordis 一起降到 4.0.4 才装得动 —— 装上之后 42/42 通过。

所以你的结论是对的，只是仓库里没有任何东西记着「0.2.0-rc.2 要配 cordis 4.0.4」。devDependency 只能钉一对，矩阵里其余格子在别人机器上的第一个现象就是这句 ERESOLVE。要么把每格配的 cordis 版本记进 README / 矩阵脚本，要么把宿主版本从 devDependency 移出去、由矩阵脚本按格安装。

二、容量判断交给「声明值」，而这条线上已经有证据表明声明值会夸大

declaredWindow() 读的是 resolveModelInfo().context.contextWindow，即路由自报的窗口。这条线上就有一例：#3948 的实测里，模型 advertise 262,144，服务端只放 32,768。

含义是：一个候选可以「按声明更大」却在真实上仍然装不下 —— 你把它判为 refused、继续试下一个（或走到 exhausted），行为是对的；但rescues 的成功率上限被「声明值 − 真实值」这个差吃掉。默认 maxAttempts: 2 时，若按声明排序的前两名都落在那个差里，这一轮就救不回来。

我不认为这需要改设计（除了声明值你也没有别的可读）。只是如果你在 README 里那句「a larger route answers」旁补一句「以路由自报的窗口为准，自报与真实可能不一致」，它就和你在别处保持的口径一致了 —— 你在 limit 1/2/3 上把话说得很准，这一条是唯一一处把「声明」当成了「事实」。

这一条下午在我自己的机器上就变成现实了（下面的实测），而且形态比我预想的更极端：不是「声明偏小导致选错候选」，而是候选池被整个压平、一个都选不出来。

关于建议一 / 二 / 三

• 建议二（日志半边）：上面已核实会到日志，这一半你做到了；UI 半边确实不是插件能碰的，同意。
• 建议三（切换时做容量检查）：同意不在你这条接缝上。
• 建议一：你实现了「被拒绝之后再找装得下的」，首次打到小窗口那一次仍然要付 —— 你在 limit 1 里写明了，好。只是它意味着这个插件是止血而不是预防：真正该改的还是 summarizer.ts:137 上的一个 fits() 判断。

装上试的结果：在我这台机器上，它没有接管 —— 而原因值得你知道

我按计划在本机（macOS，DSH 0.2.0-rc.2，两个 provider 同时启用：国内 workbuddy + 国际 workbuddy-global，各有独立账号）跑了它的规划器。你的规则本身没问题，问题在我的目录配置。

我把本机已注册的模型与它们的声明窗口喂给 planAlternatives：

provider	模型	真实窗口	我声明的（被 contextBudgets 压过）
workbuddy	deepseek-v4.1-flash	1,000,000	500,000
workbuddy	space-bunny	1,000,000	500,000
workbuddy-global	deepseek-v4.1-flash	1,000,000	500,000
trae / trae-global	…	—	200,000
qoder	…	—	400,000

结果：

失败路由 workbuddy/deepseek-v4.1-flash（声明 500000）
  候选数(eligible): 0 | 计划尝试: 0
  计划：（空 —— 没有任何路由声明更大窗口）

失败路由 trae/deepseek-v4-flash-0731（声明 200000）
  候选数(eligible): 5 | 计划尝试: 2
  计划: workbuddy/deepseek-v4.1-flash(500000), workbuddy/space-bunny(500000)

我这条路径（workbuddy 的模型）上 eligible = 0，所以结果是 no-candidate：它会追一句诊断就放行，不会改投。

为什么会这样 —— 两个缓解手段互相抵消

我自己在 profile 里给这些模型设了 contextBudgets: 500000（dsh-connect-workbuddy 的 applyContextBudgets 让声明窗口 = min(真实, 预算)，且预算只能调低）。我设它的目的正是压小窗口、让压缩更早触发。

但你的「strictly-larger」判据读的也是这个声明值 —— 于是：

• 我把「最大声明窗口」压成了 500,000；
• 失败路由也是那批 500,000 的模型；
• 500000 > 500000 不成立 → 没有任何候选。

这不是你的 bug：你的规则是对的（不能拿一个装不下的路由去接）。是我的两个缓解手段撞在一起：压预算降低了超限概率，同时把插件唯一能用的「更大路由」也压没了。

这对你的设计意味着什么（只提一个观察，不建议改行为）

declaredWindow() 读声明值没问题 —— 你除了声明值没有别的可读。但这里出现了一个可预见的用户配置形态：任何照「把预算调低以更早压缩」去做的人，都会同时把自己的候选池压平。你的 snapshot() 已经暴露 noCandidate 计数，足以让用户自己发现，所以我不建议改行为。

如果只动文档，我想不到比这更值的一处：在限制 1（不预测容量）旁边补一句「它以路由自报的窗口为准；若操作者用预算把多个路由压到同一窗口，严格更大规则会找不到候选」。下一个踩到的人就会知道去看 snapshot()，而不是以为插件坏了。

我这边的动作：把被压平的 contextBudgets 改回真实值（那几个 1M 模型），然后再跑一次 —— 那时失败路由声明 200K、候选声明 1M，严格更大成立，它就该接管了。有结果我再回来。

另外补一句我核对时发现的、与你无关但值得记的事实：这条路径上那个所谓的「1.94 倍」跨区域计数差，最近被六组实验排除了 —— 两个网关对同一段字节的计数一致（比值 0.981.06，覆盖 12k500k 字符）。原始报告里的 1.94 倍另有来源，不是分词器差异。如果你的插件被用来救某个「跨区域突然超限」的现场，那个现象的原因可能不在窗口声明上。

[DiFedorets]

Additional reproduction on Windows + proposed confirmation flow

I encountered this twice in the Web UI on DSH 0.2.0-rc.2.

• Previous route: configured context window 1,048,576 tokens.
• Last successful request before switching: approximately 642k input tokens, including cached input.
• New model: gpt-6.1-sol, context window 500,000 tokens.
• No explicit summarizationProvider / summarizationModel override.

After switching, the turn failed with CONTEXT_WINDOW_EXCEEDED. Automatic compaction and subsequent manual /compact attempts also failed:

pi-ai detected context overflow for model "gpt-6.1-sol"

Additional recovery problem: selecting the previous, larger model in the picker did not immediately fix manual compaction. The session log records the selection back to the larger route, but the following /compact still failed naming gpt-6.1-sol. This matches the summarizer prioritizing the latest request header over the currently selected model.

Requested behavior

1. Before committing a model change, check whether the current context fits the target model, accounting for instructions, tools, images, output reservation and safety headroom.
2. If it does not fit, keep the current model selected and show:
   “The conversation does not fit the selected model. Compact using the current model, then switch?” — OK / Cancel.
3. Only after confirmation, compact using the explicitly captured current provider/model.
4. Recheck the target budget after compaction. Commit the new selection only if it fits.
5. Cancellation or failure must not switch models, silently truncate history, or automatically send it to another provider.

This should be shared Host-level behavior for all sessions and presets, rather than a workaround configured separately for each model. Interfaces without confirmation support should reject an unsafe switch.