Automatic compaction falls into a permanent thrash loop when a route declares a large maxTokens; the threshold collapses silently and compaction stops being net-reductive.**

[noderex]

Environment: DSH Desktop, client UA deepseek-harness/0.2.0-rc.2, @deepseek-ai/dsh-compaction-basic 0.1.7-rc.2. Local OpenAI-compatible model route: contextWindow: 262000.

Symptom. One agent session compacted itself 42 times in 6.63 h (median gap 7.4 min, P10 3.0 min), spending 153 min (38.5% of the window) just generating summaries. Each cycle freed 6.6 K tokens net and re-triggered within 1–3 steps. Every compaction looked like a hang, so the user aborted 11 of 32 turns.

Mechanism (dsh-compaction-basic/lib/index.js):

// L63-64
headroomTokens = config.headroomTokens ?? 65536;
maxTokens      = config.maxTokens      ?? headroomTokens;   // summary output cap
// L757
reserved       = session.requestHeader()?.config.maxTokens ?? adapterDefaultMaxTokens ?? 0;
// L128-133
threshold = floor(min(contextWindow * 0.8, contextWindow - reserved - headroomTokens));
retain    = floor((contextWindow - reserved) * 0.16);

With contextWindow = 262000:

route maxTokens	threshold	retain	observed
unset (0)	196,464	41,920	compaction fired at pressure ≈169 K–196 K; one healthy cycle removed 89,702 / wrote 3,614
128000	68,464	21,440	compaction fires at 65,990–73,761, every 1–3 steps

The route's declared output cap is subtracted from the same budget the compaction threshold is drawn from, so maxTokens = 49% of the window drags the threshold down to 26% of the window. Post-compaction floor is then retain 21,440 + system/tool envelope 23,551 + summary output — with measured summary output averaging 12,639, only ≈10.8 K tokens of working band remain, i.e. one step of tool results re-crosses the threshold.

Four defects, in order of importance:

1. Silent pathological band. The only guards are reserved ≥ contextWindow (L129) and reserved + headroom ≥ contextWindow (L131), both of which throw with actionable text. reserved + headroom = 193,536 < 262,000 passes, and the configuration lands in the band where compaction cannot help. Nothing is logged; the agent just thrashes forever.
2. No progress guarantee on the pressure path. retainTokens is validated only against thresholdTokens (L134). There is no check that threshold − retain can actually absorb (system + tool envelope + summary output), and no "compaction made no progress → stop" bail-out. Compare the overflow path, which does have maxOverflowRetries. Measured: at 17:20:46 the summary wrote 15,473 tokens while removing 13,642 — compaction increased context by 1,831 tokens, and the loop continued.
3. headroomTokens is an absolute 65,536 and doubles as the summarizer's output cap. On any window ≤ 200 K it unilaterally claims ≥ 25–33% of capacity, and it is the very quantity that pushes threshold down. A capacity-relative default (e.g. min(65536, 0.1 * contextWindow)) would not create the trap.
4. Summary ratchet. Each summary re-summarizes the previous summary with no size feedback. In one session the output grew monotonically 3,614 → 20,037 tokens (5.5×) over 6 h, so cost per cycle rises without bound while usefulness falls.

Reproducer (deterministic, no local GPU required). Register an adapter model with contextWindow: 262000 and defaultMaxTokens: 128000; compose compaction-basic with defaults; drive a session from ~55 K to ~70 K estimated tokens with ordinary tool results. Expected (and observed): compaction/start at essentially every step boundary, retainTokens = 21440, thresholdTokens = 68464, and summary.outputTokens ≥ shadowedTokenCount within ~10 cycles. With maxTokens unset or ≤ 16,384 the same session compacts ~once per 130 turns and never re-fires.

Suggested fix.
(a) At spec-resolution time, verify thresholdTokens − retainTokens > envelopeTokens + expectedSummaryTokens (use policy.maxTokens as the worst case) and, if it fails, throw/warn with the same actionable wording as L131 ("reduce the effective request maxTokens or compaction headroomTokens, or configure a larger contextWindow").
(b) Track net reduction per session and stop auto-compacting when consecutive attempts do not reduce pressure (mirroring maxOverflowRetries).
(c) Cap summary output by the available band rather than by headroomTokens.

[PerryLink]

"阈值被输出上限拖下去"这个机制在代码里有对应结构——建议按"预算被两处争用"来写

1. 我核到的相关结构（HEAD = dsh-v0.2.1-alpha.1）

packages/compaction/compaction-basic/src/config.ts
:76   const maxTokens = config.maxTokens ?? headroomTokens
:104    maxTokens,                      ← 进入返回的规格
:135    maxTokens: override?.maxTokens ?? config.maxTokens,
:178    + "the adapter model's contextWindow above the effective request maxTokens"   ← 一条关系检查的报错文案

⇒ 两点支持你的判断：

1. maxTokens 是一等配置项，并且与 contextWindow 之间存在显式的关系检查（:178 的文案就是"contextWindow 必须高于有效的请求 maxTokens"）⇒ 说明两者确实被放在同一套预算里比较；
2. 加上我此前核到的 :153 resolveCompactSpec(target, contextWindow, …)（阈值由 contextWindow 派生）⇒ "输出上限与压缩阈值争用同一份窗口预算"这一机制是成立的。

⇒ 你说的"maxTokens = 49% 把阈值拖到很低"（你引的那半句）与这套结构自洽；请把那句完整引用补上（见第 4 节）。

2. ⇒ 你这条最重的其实是后果指标，建议放摘要首句

单会话 6.63 小时内压缩 42 次（中位间隔 7.4 分钟）、**153 分钟（38.5%）**用于生成摘要。

⇒ 这句话把"参数配置问题"变成"压缩变成净负收益、会话在空转"。⇒ 术语上你用的 thrash loop 很准确：阈值被拖低 ⇒ 频繁触发 ⇒ 摘要本身消耗又推高占用 ⇒ 再次触发。

3. ⇒ 诉求（三条）

1. 阈值不得被输出上限拖低到失去净收益（即：maxTokens 不应从"留给输出的余量"里反扣压缩阈值；两者应当各自有独立的下限）；
2. 阈值塌陷必须可见：当 maxTokens 使得阈值降到某个下限以下时，应当告警或拒绝该配置，而不是静默生效；
3. 加一条"反震荡"保护：同一会话在短窗口内反复压缩时，应当降低触发频率或提示（否则一条配置就能让会话空转数小时）。

4. 请补四样

1. 那句被截断的关键句（"the route's declared output cap is subtracted from the same budget …"）；
2. 路由的 contextWindow 与 maxTokens 实际值（你给了 contextWindow: 262000，请补 maxTokens）；
3. 压缩规格的实际取值（若能看到"阈值/保留量"的实际数字，就能直接印证"被拖低"）；
4. 版本：你写 compaction-basic 0.1.7-rc.2 ⇒ 请确认 0.2.1-alpha.1 是否仍如此（我核到 :76/:104/:135/:178 均仍在）。

5. 一条边界

我确认的是**maxTokens 与 contextWindow 在同一套配置里且有显式关系检查这一结构（:76/:104/:135/:178）。"阈值被拖低到 49% 的输出上限"这一具体算术**以你补的完整句子与规格取值为准——我没有在你的路由上复现。

[Damiencorrigan]

Upvoting — we hit this in production and narrowed it to a one-line validator gap,
which may be the cheapest place to fix it.

The condition. resolveCompactSpec (packages/compaction/compaction-basic/lib/index.js:124-143)
validates contextWindow > 0, reserved >= 0, messageBudget > 0,
pressureBudget > 0 and retainTokens < thresholdTokens — but never
maxTokens < thresholdTokens. It computes:

// index.js:63-64
const headroomTokens = config.headroomTokens ?? 65536;
const maxTokens      = config.maxTokens     ?? headroomTokens;
// index.js:132-134
const thresholdTokens = Math.floor(Math.min(
  contextWindow * thresholdRatio,
  (contextWindow - reserved) - headroomTokens,
));

and the shrink guard (index.js:601) then throws when
framedSummaryTokenCount >= prepared.shadowedRouteTokenCount.

So the burn condition is exactly maxTokens >= thresholdTokens, and no input
validation rejects a config that satisfies it. retainTokens gets the
symmetric check; maxTokens does not.

The boundary is worth pinning. contextWindow 32768, reserved 4096, headroomTokens 16384, thresholdRatio 0.5, maxTokens 8192 gives
thresholdTokens = min(16384, 12288) = 12288 → safe. But dropping
thresholdRatio to 0.25 gives min(8192, 12288) = 8192, and 8192 >= 8192
holds — the guard fails on exact equality. Whatever the fix, >= vs >
should be pinned by a test, because a threshold that lands exactly on the cap is
a legal-looking config that cannot ever shrink.

Why it is easy to hit. maxTokens reads like a compaction trigger, but it is
the summarizer's output cap. A settings migration that treats it as a trigger
sets it as an absolute value with no relation to the span it replaces. Measured
on our fleet: one seat carried maxTokens 100000, headroomTokens 65536 against a
thresholdTokens of 49152, another maxTokens 60000 against the same 49152.
Both are unsatisfiable by construction, and both --dump-config cleanly —
dsh --profile <p> --dump-config validates the YAML and applies the patches but
never constructs the plugin, so this entire class is invisible to it.

Suggested fix. Derive the cap from the span rather than the absolute value:

const maxTokens = Math.min(
  config.maxTokens ?? headroomTokens,
  Math.floor(shadowedRouteTokenCount * 0.5),
);

Or, minimally, fail at construction instead of at the 601 guard:

if (maxTokens >= thresholdTokens)
  throw new TargetPressureConfigError(
    `maxTokens (${maxTokens}) must be below thresholdTokens (${thresholdTokens}): ` +
    `a summary capped at or above the span it replaces can never shrink it`);

Either turns an unbounded, billed, per-step loop into a single actionable error —
and a construction-time throw would also make the defect visible to
--dump-config, which is where an operator would look for it.

Happy to test a patch if that is useful.