会话一旦超过模型窗口就永久报废：重启会全量重放表面、压缩陷入死锁、定时任务静默失效 ｜ A session dies permanently once it exceeds the model window: restart replays the full surface, compaction deadlocks, scheduled tasks go dark

[iso12138]

一句话 / TL;DR

一个长时间运行的会话，会因为一次与它无关的 dsh web 重启而永久报废 —— 此后每一轮都 400，且产品内没有任何手段能让它复活。

A long-running session is permanently destroyed by an unrelated dsh web restart. Every subsequent turn returns 400, and nothing in the product can bring it back.

---

最硬的证据：三个数字咬合 / The decisive numbers

量	值
contextPressure.surfaceTokens（会话原始体积）	555,153
× 2.07 换算成真实 token	1,149,966
provider 报错里的 messages	1,149,949 ← 差 0.0015%
最后一次成功的请求	174,998（turn 132.3，本地 22:27:57）
dsh web 重启	本地 22:54:14
重启后第一次请求	1,149,949 → HTTP 400
模型硬上限	1,048,576

报错原文：

This model's maximum context length is 1048576 tokens. However, you requested
1405949 tokens (1149949 in the messages, 256000 in the completion).
(request_id: 5eb200ce-20e8-4d27-8976-532518b3f655)

★ 关键：重启前它用 17.5 万 token 正常回答，重启后一分钟就是 115 万被拒。用户没有对会话做任何事 —— 是一次与它无关的重启把它杀了。

---

根因 1 · 已经超窗的会话，压缩救不回来（死锁）

dsh-compaction-basic 的文档写了溢出恢复（"after a context-overflow error, it condenses and retries"），但摘要请求本身必须把整个表面发给模型。线级代理日志实拍到：

dsh native compaction call identified (final user message = COMPACTION_INSTRUCTION, 589 msgs)

一个 115 万 token 的压缩请求会被和原请求一模一样地拒掉。

唯一能缩小表面的机制，前提是把表面发出去。没有任何"不调模型"的兜底先跑。

建议：检测到规范溢出时，先无条件把工具结果裁剪器（dsh-compaction-tool-result-pruner，按设计不调模型）跑到收敛；若裁剪后重放已低于路由窗口就直接重试，再考虑摘要。

---

根因 2 · 压缩触发线用的单位，可能落在真实墙外面

触发线 = floor(min(W × thresholdRatio, W − O − headroomTokens))，默认 0.8 / 65536。
取 W = 1e6、O = 256e3 → 678,464（计量器单位）。

而中文内容在真实分词下约为计量器的 2.07 倍 → 678,464 ≈ 140 万真实 token，已经在墙外。

对非拉丁文字内容，这道闸门被标定在错误的单位上，永远来不及触发。

建议：用 provider 回报的 prompt_tokens（响应里本来就有真实值）校准计量器，或直接以"上一次真实用量"作为触发依据。

---

根因 3 · 一次重启，静默杀死任何大会话

重启会从日志按完整原始体量重建表面。此前让它「装得下」的内存摘要、之前做过的裁剪，在第一个请求之前不会被重新建立。

这是本 bug 最恶劣的性质：会话看起来一直健康，直到一次寻常的重启把它永久杀掉。用户没有任何办法知道哪些会话已经上膛。

建议：加载会话时把重放出的表面与路由窗口比一下；超出就在加载时跑一遍裁剪，或至少给出指名道姓的警告。

---

根因 4 · 绑在死会话上的定时任务静默失效，而且删不掉

dsh-schedule 把每个任务绑到 sessionId（deliveryMode 是硬编码 const: "host"，没有"投递到全新会话"这个选项）。会话超窗后每次投递都以 400 失败，而用户侧什么都看不到 —— 没有横幅，任务状态也不会变成错误。

我们 7 个每日检查点任务（09:26 / 10:00 / 10:30 / 11:15 / 13:30 / 14:45 / 15:05，status: "active"）就这样全瞎了，界面上还显示着正常排期。

更糟的是清不掉：schedule_delete 是会话隔离的，从别的会话去删一个确实存在于 $DSH_HOME/storages/schedule.json 里的任务，返回：

{"deleted": false, "code": "schedule_not_found"}

绑在死会话上的任务，UI 够不着、工具 API 也够不着，只能手工改 JSON 存储再重启。

建议：(a) 投递失败时把任务标为错误并通知；(b) 允许按 id 从任意会话删除任务。

---

附带 5 · DEFAULT_MAX_TOKENS = 256e3 每次请求占掉 100 万窗口的约 24%

dsh-llm-deepseek/lib/index.js L19 / L21。provider 把这个预留算进窗口（报错原文可见 256000 in the completion）。

本机实测：一天 381 次请求的真实输出合计仅 661,635，平均 1,737，峰值 9,748。预留量是实测峰值的约 26 倍，直接从可用输入里挖走四分之一。

说明：这是窗口成本，不是计费成本 —— max_tokens 是上限，没用掉的额度不收费。

建议：默认值显著调小。

---

附带 6 · DEFAULT_CONTEXT_WINDOW = 1e6 与提供方真实值 1,048,576 差 48,576

数值不大，但所有派生阈值都会跟着偏。

---

环境 / Environment

@deepseek-ai/dsh 0.2.0-rc.2
Windows 11 25H2 build 26200.8655 · Node v24.21.0 · profile web
provider deepseek-official / model deepseek-flash

---

我们本机的绕过方案（纯配置，无需改代码）

- id: llm-deepseek-account
  config:
    maxTokens: 64000          # 默认 256e3 下调

- id: compaction-basic
  config:
    thresholdRatio: 0.4       # 默认 0.8 → 触发线 678,464 → 400,000

---

复现步骤 / Reproduction

1. 跑一个中文密集 + 工具输出巨大的会话（大块 JSON / CSV / 行情数据），让 surfaceTokens 越过约 55 万计量器单位。
2. 确认此时会话仍然正常回答（会的 —— 实时请求比原始表面小得多）。
3. 重启 dsh web。
4. 随便发一条消息 → CONTEXT_WINDOW_EXCEEDED，并且永远这么报下去。

---

English summary (click to expand)

Symptom. A long-running session returns HTTP 400 CONTEXT_WINDOW_EXCEEDED and never recovers.

Trigger. An unrelated dsh web restart. The harness rebuilds the session surface at full raw size; if that exceeds the model window, every turn fails forever. Measured: same session answered at 174,998 tokens before the restart and failed at 1,149,949 one minute after it.

Root causes.

1. Compaction deadlock — the summarization request must itself carry the full surface, so it is rejected identically. The only mechanism that could shrink the surface requires sending it.
2. Trigger unit mismatch — floor(min(W×thresholdRatio, W−O−headroomTokens)) is evaluated in the meter's unit, which under-counts CJK by ~2.07×. A 678,464 trigger corresponds to ~1.4M real tokens — past the 1,048,576 wall.
3. Restart kills large sessions silently — sessions look healthy until an ordinary restart destroys them permanently.
4. Scheduled tasks bound to a dead session fail silently and cannot be deleted — schedule_delete is session-scoped and returns schedule_not_found for a task that demonstrably exists in $DSH_HOME/storages/schedule.json.
5. DEFAULT_MAX_TOKENS = 256e3 reserves ~24% of a 1M window per request (measured real output: mean 1,737, max 9,748).
6. DEFAULT_CONTEXT_WINDOW = 1e6 vs the real 1,048,576.

Workaround (config only). maxTokens: 64000 on the provider row + thresholdRatio: 0.4 on compaction-basic → trigger 678,464 → 400,000.

Repro. Grow a CJK-heavy, tool-output-heavy session past ~550K meter units → confirm it still answers → restart dsh web → send anything.

[argszero]

What already exists for the recognition half, and exactly where it stops

Your root cause 1 is the one I can contribute to concretely, because the failure you describe has a published partial remedy: the refusal is real, the reason is named by the provider, and the harness still does not read it.

The plugin: @argszero/cordis-plugin-length-stop-overflow 0.4.0 (npm; source discussion #9434, siblings #7214/#7626/#7632). It sits on agent/request-error and rewrites a refusal into CONTEXT_WINDOW_EXCEEDED — the one code that the built-in recovery gate reads (compaction-basic/src/index.ts:194, failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE || signal.aborted). It recognises four shapes, all of which currently arrive as codes nothing recovers from:

• a length stop carrying one token (pi-ai's clamp to max_tokens: 1);
• a size-naming refusal classified INVALID_REQUEST (413 with no JSON body);
• a provider's own prompt_tokens count at/over the advertised window;
• a harness-metered request size at/over a configurable fraction of the advertised window (fullRequestRatio, default 0.5).

Every rewrite keeps the provider's words verbatim and adds both numbers, so it is checkable in the session log.

Where it stops, for your report specifically. It restores the gate, not the recovery. If compaction's own request is itself over the window — your root cause 1 — the plugin gets you to the call and the call still fails; the unconditional non-LLM pruner you propose is the missing piece and it is a core change, not something I can put in front of the gate from outside. Two further boundaries, stated because they matter for a CJK session like yours:

• the meter-based rule inherits the meter. It compares tokenMeter.measure(session).totalTokens against the declared window, so your root cause 2 (the ~2.07× calibration gap between the meter's unit and real tokenization) applies to the plugin's line exactly as it applies to the built-in threshold — the plugin cannot see the real wall either, it only speaks in the units the harness has;
• root causes 3 and 4 (a restart rebuilding the full surface before anything shrinks it; schedule deliveries dying silently against a dead session) are outside it entirely — a plugin never sees the load path that seeds the surface, and the schedule layer is session-scoped by construction.

So: worth installing if the symptom you hit is "every turn 400s and it never compacts", which is what the four triggers target. Not a fix for a session that is already past the window, and not a substitute for the pruner-first ordering you propose.

[iso12138]

Thanks - this is a very high-quality reply, and the "restores the gate, not the recovery"
distinction is exactly the right framing.

One measured data point you may want, because it affects your fullRequestRatio default.

Environment: dsh 0.2.0-rc.2, Windows 11, provider deepseek-official / deepseek-flash,
CJK-heavy session.

Your meter-based rule fires at fullRequestRatio = 0.5 of the ADVERTISED window. On a
CJK session that is still far too late, because it inherits the meter:

contextPressure.surfaceTokens 555,153
x 2.07 -> real tokens 1,149,966
provider-reported messages 1,149,949 (delta 0.0015%)
hard wall 1,048,576

So "50% of the advertised window" in meter units is already ~100% of the real wall.
The plugin cannot see the real wall, as you said - so the ratio has to be chosen in the
meter's units, not the advertised ones.

What I did locally instead (config only, no plugin):

• id: llm-deepseek-account
  config:
  maxTokens: 64000 # default 256e3; frees 192,000 of input space
  # (the provider counts this reservation against the
  # window: "256000 in the completion")
• id: compaction-basic
  config:
  thresholdRatio: 0.4 # default 0.8 -> trigger 678,464 -> 400,000 meter units
  # 400,000 x 2.07 ~ 828,000 real, 21% below the wall

That reproduces roughly what your point 4 does, but calibrated by the measured 2.07x
instead of by a flag ratio. I will report back with a surfaceTokens curve after a full
trading day, if that is useful for your sibling discussions.

So my only question: could the meter-based rule read the provider-reported prompt_tokens
from the previous response to locate that calibration factor, instead of comparing
meter-units against the advertised window? As it stands, sibling #9434's approach cannot
become correct for non-Latin sessions even in principle - it would only shift the wrong
line.

Two smaller things from the same report, in case they are cheap on your side:

1. Root cause 4 has a second half that is not just "deliveries die silently": the task
   also cannot be CLEANED UP. schedule_delete is session-scoped, so from another
   session it returns {"deleted": false, "code": "schedule_not_found"} for a task that
   demonstrably exists in $DSH_HOME/storages/schedule.json. A task bound to a dead
   session is unreachable from the UI and from the tool API - only a manual JSON edit
   plus a restart clears it.

2. DEFAULT_MAX_TOKENS = 256e3 (dsh-llm-deepseek/lib/index.js L21) reserves ~24% of a
   1M window on every request. Measured over 381 requests in one day: total output
   661,635 tokens, mean 1,737, max 9,748. The reservation is ~26x the observed peak.

[workibear]

配置好后现象还存在吗，我发现我之前的对话也出现了这个问题

[iso12138]

回 @workibear —— 我刚好在你问的这一刻做完了这个实验，直接给数据。

结论分两半：日常路径是安全的，但我上次贴的那份配置根本没生效。

---

① 日常路径：安全

我跑了一整天的实测（dsh 0.2.0-rc.2 / Windows / 中文会话，214 次请求）：

首个 462,006  ->  峰值 679,405  ->  末值 529,431
压缩正常触发 2 次，撞到阈值后立刻压下去：
   679,164 -> 520,325   (-23.4%)
   679,333 -> 282,362   (-58.4%)
硬墙 1,048,576，峰值余量 35%。会话活着。

② 但我上次那份配置，一个字都没进去

dsh --profile web --dump-config 打出来是这样的：

- id: compaction-basic
  name: '@deepseek-ai/dsh-compaction-basic'
  disabled: true                 <-- 顶层这一行是禁用的
  config:
    thresholdRatio: 0.4          <-- 我的 patch 落在这里，什么也不做

真正在跑的是 agent-preset 里 isolate 组的副本，没有 config，用默认 0.8。反推验证：

实测触发点                    679,164 / 679,333
默认参数算出的线              678,464     <- 差 0.1%，吻合
我设的参数算出的线            400,000     <- 差 279,000，完全不符

maxTokens 我犯了同样的错：patch 的是 llm-deepseek-account，而 profile 实际在用的是 llm-deepseek（api-key 版）。

所以「配置好后现象还存在吗」的答案是：配置没进去，谈不上有没有效。
抱歉 —— 我上一楼那份配置建议不要照抄，至少在这个 profile 上它是空转的。

---

③ 那真正管用的是哪条

不是压缩阈值。我把两个量搞混过，现在分开：

日常请求（压缩后的视图）      ~679K 真实 token      -> 安全
重启后的全量重放              surfaceTokens × 2.07  -> 这才是杀手

死掉那个会话 surfaceTokens = 555,153，重放出来 1,149,949，直接撞墙。
所以真正的危险线是 surfaceTokens ≈ 500,000，而压缩策略管不到它 ——
因为压缩是在请求已经构建之后才被咨询的。

这条正好是原帖 root cause 3，也就是 argszero 说的「核心改动、我在外围做不到」。

④ 补一个 @xiaoyuyu6420 没提到的细节

你提到 /compact 手动触发 —— 我查了：顶层 command-compact 也是 disabled: true，
但 agent-preset isolate 组内部有一个活副本，所以 /compact 应该是可用的。
这条救命通道在，值得先试它，再考虑搬会话。

⑤ 实操上真正能做的（我这边在用的）

- 长会话盯 surfaceTokens，别盯请求大小；过 400,000 就准备换会话
- 重启 DSH 之前先看一眼有没有大会话 —— 重启是唯一会全量重放的动作
- 已经撞墙的会话不要反复重试（每次都在烧 token 打同一堵墙）
- 卡住的会话数据不会丢，能正常加载、历史看得见，只是发不出新请求

[xiaoyuyu6420]

回 @workibear 的问题——答案要分两种情况，取决于你的会话卡在哪一段：

装上 cordis-plugin-length-stop-overflow 恢复的是"识别"，不是"执行"。它把 provider 的超窗拒绝改写成内置恢复机制唯一认得的代码，让自动压缩能触发。所以：

• 会话还没坏透（压缩请求本身还没超窗）：装上后自动压缩能跑起来，/compact 手动触发也行——能救回；
• 已经到原帖 root cause 1（压缩自己的请求也超窗）：识别恢复了，但压缩调用本身还是会失败——argszero 自己说了这步"gets you to the call and the call still fails"。这种情况产品内目前无解，非 LLM 修剪器是核心改动还没做。

对你已经出问题的旧对话，先说定心的：数据没丢。这类会话能正常加载、历史在界面里都看得见——只是发不出新请求。最稳的"恢复"是把要紧内容手动搬进新会话继续；不要反复重试同一轮（每次都在烧 token 打同一堵墙）。

两个实操建议：

1. 插件从 npm 装（包名在 argszero 楼里），装完重启 dsh web 生效——它接管的是 agent/request-error 事件；装好后拿 /compact 试一次就知道你的会话属于上面哪种情况；
2. 窗口期里长会话要主动管理：这个插件默认在请求达到标称窗口一半时就触发压缩（fullRequestRatio 0.5），思路就是"别等撞墙"——重要的长任务建议到一半就主动 /compact 或拆新会话，等官方的非 LLM 修剪器落地再改回激进用法。

[xg-gh-25]

The compaction-deadlock in root cause 1 is the sharp part here, and I think it's structural rather than a tuning bug: compaction is modeled as a recovery step, but the recovery step itself needs a model call sized to the surface it's trying to shrink. Once the surface is past the hard wall, every path that could rescue it — including the summary request — is already over the wall. There is no non-model floor that runs first, so the only mechanism that can shrink the surface presupposes you can send the surface.

We hit the same wall and ended up treating the model window as a write-time invariant, not a recovery target. Two things that made the deadlock structurally impossible rather than just rarer:

1. A non-model pruning floor runs unconditionally on spec-overflow, before any summary call. Tool-result pruning (the pure, no-model path) runs to convergence first; if the replayed surface is now under the route window we just retry — a model summary is only attempted after that, never as the first response to overflow. This is exactly your proposed fix and I'd argue it's the only ordering that can't deadlock.
2. The budget is enforced at append time, not at request time. A turn that would push the surface past W − O − headroom is refused or pre-pruned when it's written, so a surface that can't be served never gets persisted. The decisive thing in your trace — a 175k-token session becoming a 1.15M-token request a minute later with no user action — can't occur if the ceiling is checked on the way in rather than on the way out.

Root cause 2 (trigger line in a unit that can land outside the real wall) is the same class of bug: the only safe trigger unit is real provider tokens with the completion reservation subtracted, because that's the only number the provider actually rejects against.

---

We run a single-orchestrator agent OS where the context budget is an engine-owned invariant enforced at write time, with a no-model pruning floor that always runs before any summarization call. More context on SwarmAI. Discussion: T-MEM

[iso12138]

@xg-gh-25 thanks - and I agree it is structural rather than a tuning bug.

Two measured data points from this side that land on your second point, because "real
provider tokens with the completion reservation subtracted" is exactly the line I went
looking for and eventually found.

1. The reservation is literal, and it is an absolute ceiling

The route here advertises contextWindow 1,000,000, but refuses anything whose
prompt_tokens + max_tokens exceeds 2^20 = 1,048,576 - roughly 63% of the advertised
window. The provider prints both numbers in the refusal:

This model's maximum context length is 1048576 tokens. However, you requested
1405949 tokens (1149949 in the messages, 256000 in the completion).

1,149,949 + 256,000 = 1,405,949   -> refused

allowed input = 1,048,576 - max_tokens
    max_tokens 256,000 (default) ->  792,576
    max_tokens  64,000           ->  984,576

So on this route the reservation is subtracted literally, not heuristically. Lowering
it is free headroom - and it also moves the compaction trigger, because the policy
formula carries the same O:

trigger = floor(min(W * thresholdRatio, W - O - headroomTokens))
    O = 256,000 -> 678,464
    O =  64,000 -> 800,000

2. A correction I owe the thread: the meter is ~1:1 here

I posted earlier that the harness meter carries a ~2x calibration gap on CJK content.
A full trading day says otherwise:

compaction fired at meter threshold      678,464   (computed from the formula)
provider-reported request at that fire   679,405
ratio                                     1.0015

So fullRequestRatio is not fighting a 2x error on this setup. The 2.07 factor was a
different quantity entirely: surfaceTokens (raw history) against a FULL REPLAY
request, which is what a restart sends. Two different numbers; I conflated them.

3. On append-time enforcement - one boundary I would like your view on

"a surface that can't be served never gets persisted" is the half I cannot reproduce
from outside, and it addresses root cause 3 exactly. The measured boundary here:

dead session      surfaceTokens 555,153 -> replay 1,149,949 -> 400
survivor          surfaceTokens 485,335 -> replay 1,004,643 -> 4% under the wall
active session    surfaceTokens 283,684 -> replay   587,225 -> comfortable

The middle one is the interesting case: 4% under the ceiling, still usable, history
intact.

Which is what I keep coming back to. If the no-model floor has run and the turn still
will not fit under W - O - headroom, what do you do with that turn? Refusing the
append makes the invariant hold, but then the user's input is never persisted at all -
a different failure from the one we have today, where the dead session loses nothing
and merely cannot send. Pre-pruning instead degrades the record. Neither looks free to
me, and I would be curious which one you took and why.

---

One note for anyone patching the compaction policy from outside on DSH, since it cost
me a day: a profile-layer patch can silently do nothing here. The top-level
compaction-basic row is disabled: true - the live instance is a copy nested inside
an agent-preset isolate group - and per the shipped schema, patch ids resolve only
against the current index, "not ids introduced or changed by earlier patches". Verify
with dsh --profile web --dump-config. A modified config file is not evidence that a
value was read.

[iso12138]

Second data point, as promised - same machine, same session, one config change apart. And this
time the prediction lands.

What changed between the two days

                        day 1 (10-13)          day 2 (10-14)
maxTokens               256,000 (default)      64,000  (patched)
compaction trigger      default 0.8            default 0.8 (unchanged - see caveat 2)

Only maxTokens moved. The threshold formula carries O, so the predicted trigger line
moves with it:

trigger = floor(min(W * thresholdRatio, W - O - headroomTokens))
    O = 256,000  ->  min(800,000, 678,464) = 678,464
    O =  64,000  ->  min(800,000, 870,464) = 800,000

Measured - the provider-reported request size on the turn compaction fired

day 1    679,164  and  679,333     predicted 678,464     delta +700 / +869
day 2    800,591                   predicted 800,000     delta +591

Three firings across two configurations, all within 0.1% of the line the formula predicts.
The trigger is the formula, and maxTokens is subtracted literally - which is what the
refusal says too: prompt_tokens + max_tokens <= 2^20.

What the second day actually looks like

day 2, 168 requests
    first 656,885  ->  peak 800,591 (turn 84.1)  ->  last 624,552
    compaction fired once:  800,591 -> 351,656   (-56.1%)

day 1, 275 requests
    first 462,006  ->  peak 679,405              ->  last 653,895
    compaction fired twice: 679,164 -> 520,325  /  679,333 -> 282,362

The daily path is inside the wall either way. The largest request today was
800,591 + 64,000 = 864,591 against 1,048,576 - about 17% headroom left at the peak.
Lowering the reservation bought exactly what it should: the session runs 121,536 tokens
larger before anything has to shrink.

Two honest caveats

1. The plugin logged nothing. @argszero/cordis-plugin-length-stop-overflow is loaded
   and was not disabled by the peer gate (zero disabling profile plugin row entries),
   but none of its four triggers fired across two days of traffic. That is consistent
   with "no unrecognised refusals happened" and equally consistent with "it is not wired
   the way I think". I cannot tell those apart from outside, and I am not going to claim
   it works on the strength of a clean log.

2. thresholdRatio is still 0.8, and I no longer think that is fixable from here. The
   top-level compaction-basic row on this profile is disabled: true; the live instance
   is a copy nested inside an agent-preset isolate group, and per the shipped schema patch
   ids resolve only against the current index - "not ids introduced or changed by earlier
   patches". dsh --profile web --dump-config shows both the row state and that a - set:
   against the nested id silently does nothing.

And the part that has not changed

The daily path was never the failure mode. The failure is the reload path: a restart
replays surfaceTokens in full, and that is the number that has to fit. A lower
reservation moves that line out as well:

safe surfaceTokens  <=  (2^20 - maxTokens) / ~2.07
    maxTokens 256,000  ->  382,887
    maxTokens  64,000  ->  475,640

Real improvement, but still a line the compaction policy cannot see - because the policy
is consulted after the request has already been built. Root cause 3 stands, and your
append-time invariant is still the fix for it.