/compact cannot succeed once history exceeds the summarizer request limit (death spiral, 101/101 attempts failed)

[akshaytp1571]

Summary

/compact cannot succeed on a session whose history has grown past the summarizer route's own request limit. Every attempt fails, nothing is pruned, the context only grows, and each subsequent turn re-triggers the same doomed request — a monotonic death spiral with no user-visible way out.

Reproduced on a real session (session.v4.jsonl.zstd, 9,519 events, 7 concatenated zstd frames, 13 MB decompressed, preset cordis):

• 101 compaction/start / 101 compaction/end, 0 compaction/summary, 0 compaction/prune — no attempt ever committed.
• All 101 compaction/end events carried an error:
  • 94 × HTTP 413 Request Entity Too Large (raw nginx HTML page)
  • 3 × HTTP 400 context_length_exceeded — "Context far exceeds the limit for this pack: estimated ~655,944 / ~656,498 / ~699,975 tokens (limit 524,000). It can no longer be summarized in a single request — start a new session, or manually trim the conversation below 524,000 tokens."
  • 2 × HTTP 401, 1 × HTTP 402, 1 × pi-ai detected context overflow
• Surface pressure at the last attempt: 563,299 tokens against a 524,000-token window — already over the limit before compaction started.
• The log itself is healthy: 0 JSON parse failures, 0 duplicate seqs, 0 gaps, and every compaction/start matched exactly one compaction/end, so the durable compaction lock is not leaked and the session remains readable.

The final /compact returned "Compaction could not produce a useful summary. The attempt is recorded in the session log."

Root cause

dsh-compaction-basic summarizes by replaying the selected span into one request. Three properties combine into the trap:

1. compactNow uses retainTokens = 0 (dsh-compaction-basic/lib/index.js:992 in the shipped build; src/index.ts in source). The manual path therefore shadows essentially the entire surface and replays all of it.
2. The manual path never invokes the tool-result pruner. Only compactIfNeeded does (src/index.ts:926-945), so the model-free "trim first, maybe skip the summary entirely" fallback documented in the README is unavailable to /compact.
3. The summarizer route's request limit is independent of, and can be smaller than, the conversation's routed window. Here the conversation was routed to a model advertising a 524,000-token window while the gateway in front of it enforced a much smaller effective body limit — so the replay was rejected as a 413 before the provider ever evaluated the model's window.

Because the attempt never shrank anything, nothing was ever pruned, so the surface only grew and every later turn re-triggered the same doomed replay.

A second classification bug

The harness maps any leading HTTP 413 to CONTEXT_WINDOW_EXCEEDED (pi-ai's overflow patterns match the bare status). An nginx error page is therefore reported as a context overflow even though nothing about the model's window was ever evaluated. That mislabel sends the failure down the overflow-recovery path, which replays the same oversized request and dies identically — burning a retry per turn. This is the same class of bug as the existing fix/pi-ai-413-gateway-body-limit branch, but reached from the compaction side.

Measured provider matrix (against this session's own credentials)

route	result
commandcode minimax/minimax-m3.1-flash	HTTP 200 — accepted a 2.54 MB / 654,767-token replay and produced a valid checkpoint
aethera	HTTP 413 (nginx body cap)
oao claude-opus-5.5	HTTP 400 context_length_exceeded (524,000)
whatstoken	HTTP 402 (account out of credit)

I rebuilt the exact compaction request from the failing session (3,133 surface messages, the real 47-tool schema, the real 8,065-char system prompt, the verbatim COMPACTION_INSTRUCTION) and confirmed commandcode answers it successfully, so the session's content is summarizable — only the route was wrong.

Fix

https://github.com/akshaytp1571/deepseek-harness/tree/fix/compact-over-budget-route

Commit 2179c355e2 — fix(compaction-basic): condense in slices when the replay exceeds the summarizer limit.

Classify the failure. New classifySummarizationFailure() (packages/compaction/compaction-basic/src/failure-class.ts) narrows a thrown summarizer failure to over-budget or other. Over-budget is a payload-size problem: a provider-confirmed context overflow, a gateway body-limit rejection of the replay, or a framed summary not smaller than its source. Auth, quota, transport, and empty output stay terminal. isGatewayBodyLimitError() distinguishes a proxy's HTML page or bare status line from a provider's structured overflow body.

Shrink and retry inside the same bracket. compactSurfaceRegion now retries on over-budget failures, re-selecting the oldest balanced prefix that fits and keeping the surface unchanged otherwise. The span keeps its start edge and only its tail boundary walks toward the start, so every intermediate cut stays tool-pairing balanced and the retained recent nodes stay verbatim. The durable contract is preserved exactly: one compaction/start, at most overBudgetRetries + 1 summary attempts, exactly one closing compaction/end — no lock leak, no orphan, no reader-visible shape change. Cancellation, surface change, and commit-stage failures are never retried.

New setting. overBudgetRetries (default 3), validated and merged through the existing per-model policy path, documented in the READMEs and the generated config catalog.

Tests. 14 new cases (183 total in the package pass, plus tsc -b and oxlint clean): 413 HTML page, bare status line, and structured provider overflow all classify as over-budget; auth, quota, and "summary is not smaller than the shadowed content" stay terminal; the bracket holds exactly one start/end pair across all retries; each retry replays a strictly smaller prefix; a non-over-budget failure is never retried.

What this does not fix

• No pre-flight guard. The backend still does not check whether the selected span fits the summarizer's window before making the request, so the first attempt of an over-budget session still fails once and only then shrinks. A pre-flight estimate would avoid that wasted request entirely.
• The manual path still never prunes. /compact cannot benefit from the tool-result pruner's model-free trim.
• The threshold/ceiling mismatch. The compaction trigger derives from the routed model's advertised contextWindow, while the summarization ceiling is the gateway's effective limit. When those disagree the trigger fires far too late for the first attempt to succeed. Sharing one source of truth for both would remove the trap at its root.
• This is a mitigation, not a recovery. A session already stuck in the death spiral still needs a restart to pick up the new code, and overBudgetRetries halves the span each attempt, so extremely oversized histories need several compactions rather than one.

Repro notes for maintainers

session.v4.jsonl.zstd is a concatenation of independently checksummed zstd frames, not a single frame. Node's zstdDecompressSync() and createZstdDecompress() both silently return only the first frame (314 bytes here). DSH's own dsh-session-persistence-jsonl ships a proper multi-frame decoder, so the harness reads these files correctly — but any external analysis tooling needs to split on frame magic 28 B5 2F FD and decode each frame.

I am posting this as a discussion rather than opening a PR against deepseek-ai/deepseek-harness because I do not have push access to the official repository. The branch above carries the full change and the reproducer's measured numbers.

[PerryLink]

It is a real dead end, and the spiral is structural.

What I verified at master ce7073d5 in packages/compaction/compaction-basic/src/index.ts:

• The pressure path prunes tool results first, then picks a range and summarizes it (:344-350 prune, :354 range, :362 compactRegion). The prune only happens when a toolResultPruner service is mounted (:326, :346); without it nothing shrinks the region at all.
• The summarize call is one one-shot request over the replayed region (:260-269 describes it as a direct ctx.llm.stream() whose prefix is the conversation itself), so the region size is the request size. A 413 from a proxy and a 400 context_length_exceeded from the pack are both "this one request is too big".
• The retry loop at :353 only covers "a compaction committed but the meter is still above threshold" — compactRegion at :362 is not wrapped in a try, so a failed summarize leaves the loop with the error and the region stays exactly the same.

So when the region is over the summarizer route's request limit, every trigger produces the same doomed request. There is no code path that drops messages to make the next summarize fit, and no pre-check of the region against that route's limit. Your numbers (101 start/end, 0 summary, 0 prune) are what this path looks like when the pruner is absent and the request never succeeds.

Getting out: a new session, or trimming history yourself before the next turn — which is also what the 400 body says. Repeating /compact cannot work, because the request it sends is the same size.

Fix shape, if you want to file it: estimate the region against the routed model's request limit before sending; on 413/400 from the summarizer, either prune harder than the tool-result pass or fail once with a definitive "this session cannot be compacted" instead of re-triggering on every turn.

If you paste one compaction/start…compaction/end pair with its timestamps, I can tell you which branch fired.

Read-only source inspection at master ce7073d5; I did not reproduce the 101 attempts.