compaction-basic: add a prompt-message budget — long sessions die on gateways that cap message count

[layen-king]

Summary

A long-lived session became permanently unsendable: every model call returned HTTP 400 from the provider, and nothing in DSH noticed. The token meter reported pressure below the compaction threshold, so compaction-basic never ran, and each retry rebuilt the same oversized prompt.

The root cause is that some OpenAI-compatible gateways cap the prompt message count per request independently of the model's context window. compaction-basic only reacts to token pressure, so a tool-heavy session can reach that cap while still "fitting" the declared window.

Observed failure

Session: 180 goal rounds, 2057 projected prompt messages, ~790k tokens, model declaring contextWindow: 1000000. From one step onwards every request failed:

400: {"message":"{\"message\":\"the configured rewrite value still does not satisfy the rule trace_id: <redacted>\",\"type\":\"invalid_request_error\"}\n","type":"invalid_request_error"}

The message comes from the gateway's internal request-rewrite layer and never clears on retry, because the history is already over the cap.

Root cause (bisected against the live endpoint)

projected messages	result
1022 (first half of the failing history)	200
2047	200
2048	400, same "rewrite value" message
5001	400, a single request cannot evaluate more than 8192 path candidates

The cap is message count, not bytes or content:

• replaying the captured failing body with every message truncated to 40 chars → still 400
• replaying it with all reasoning_content stripped → still 400
• cutting the history to its first 1022 messages (contents byte-identical) → 200

DSH side: resolveCompactSpec derives pressure purely from tokens — min(contextWindow * thresholdRatio, contextWindow - reservedCompletionTokens - headroomTokens). With thresholdRatio: 0.8, headroomTokens: 65536, a 32k output reservation and a 1M window that is 800,000 tokens, while 2048 messages of a tool-heavy session sat at ~790k. Compaction therefore never triggered, and the session could never be recovered.

Suggested fix

Add a second, independent pressure trigger — a prompt-message budget — instead of relying on token scaling to approximate one:

1. CompactionPolicyConfig.maxMessages?: number (default 1600; 0 disables), validated as a non-negative integer and inherited by exact-target modelPolicies like the other policy fields.
2. Carry it through ResolvedPolicyFields → resolveTargetPolicy → resolveCompactSpec.
3. In compactIfNeeded (the pressure branch), treat measurement.nodes.length >= spec.maxMessages as pressure, and re-check the same predicate after the pruner pass and after each compaction attempt.

TokenMeasurement.nodes already gives the projected message count, so no new service or projection is needed. A per-route override is worth exposing too, since a gateway may cap lower than 2048.

Sketch of the predicate change:

const overBudget = (m: { totalTokens: number; nodes: readonly unknown[] }): boolean => (
  m.totalTokens >= spec.thresholdTokens
  || (spec.maxMessages > 0 && m.nodes.length >= spec.maxMessages)
)

Patch

Since the repo does not take external PRs, the change lives on a branch of my fork (4 files, +37/-4, packages/compaction/compaction-basic only):

layen-king/deepseek-harness@master...fix/compaction-max-messages

• src/types.ts — new maxMessages policy field
• src/config.ts — validation, default, inheritance, and resolveCompactSpec plumbing
• src/index.ts — the dual trigger and its re-checks
• tests/compaction-basic.spec.ts — defaults assertion updated (all 152 tests in the package pass)

Verified locally: the session that always returned 400 now compacts at 1600 messages and continues (400 → 200 on the same request).

Environment

• dsh 0.2.1-rc.2, web profile
• Linux/WSL2 host and the packaged Windows desktop build (reproduced on both)
• provider: an OpenAI-compatible gateway (api: openai-completions), single model route, reasoning_effort in use

Workaround applied meanwhile

Lowering the declared contextWindow for that provider's models (1M → 500k) so token pressure lands before the message cap. It works, but it is a guess at the gateway's real limit and costs usable context, which is why a first-class message budget seems preferable.

[layen-king]

Follow-up: what shipped locally, and where it still bites

Two deployment shapes here, and they diverge — worth recording since the workaround is not equivalent to the fix:

Source checkout / dsh web (Linux, WSL2) — patch applied and live: src/ change plus a rebuilt lib/, instance restarted. On the exact session that had been failing for 5 consecutive turns (2057 messages, ~790k tokens), the same request now triggers compaction at the message budget and returns 200 instead of 400, and the turn continues normally. Package tests: 152/152, and the repo's own pre-push typecheck passes.

Packaged desktop build (Windows, Electron + app.asar) — the plugin lives inside the archive, so there is no supported way to land the change without repackaging. The only lever is configuration: lowering the declared contextWindow for that provider's models (1M → 500k) so token pressure is reached before the message cap. That fires compaction at ~480k tokens ≈ 1250 messages for a tool-heavy session, which is enough headroom here, but:

• it is a guess at the gateway's real per-request limit, not a measurement of it;
• it costs usable context permanently, for every session, including ones that would never hit the cap;
• it does not protect sessions whose messages are short: 2048 tiny messages can sit at 100–200k tokens, far below any threshold derived from the window, and those sessions still become unsendable.

So the configuration workaround is really "bend the token budget until it accidentally approximates a message budget". A first-class maxMessages (with a per-route override in modelPolicies, since a gateway may cap lower than 2048) would make this exact and would also be the only way to fix the packaged builds without changing how anyone configures models.

Happy to iterate on the patch shape if a different seam is preferred — e.g. a generic "request budget" concept alongside the token one, rather than a message-specific field.