Compaction can repeatedly fail when its one-shot summary input exceeds the summary model context

[aka-danielZhang]

Symptom

Automatic compaction can trigger above the configured pressure threshold but fail to land a checkpoint. The log reports step compaction failed: ... context overflow ...; continuing the turn, and subsequent turns keep replaying the same over-budget surface.

Root cause

dsh-compaction-basic selects a compactable surface prefix, then replays that complete prefix in one auxiliary summary request. The selected prefix can itself exceed the summary target context window. Provider CONTEXT_WINDOW_EXCEEDED is caught by the automatic listener, so the durable surface remains unchanged and the next step repeats the failure. Installing an alternate Provider does not fix the shipped default presets because they continue mounting @deepseek-ai/dsh-compaction-basic in the isolated compaction realm.

Proposed fix

Keep the existing cache-reusing one-shot request unchanged when estimated input plus its output cap fits. Otherwise, or when that fitting request receives canonical CONTEXT_WINDOW_EXCEEDED, use bounded chronological map/reduce internally:

• group source messages without splitting tool calls from results
• greedily map chunks under the summary model input budget
• recursively reduce structured partial checkpoints
• bisect only a Provider-rejected span and retain successful siblings
• fail closed on truncation, malformed/visual output, cancellation, no progress, depth exhaustion, or an indivisible overflow
• preserve one-call provenance and aggregate usage only when complete and honest
• make no durable replacement until the complete hierarchy succeeds

Adapters without context capacity metadata retain the existing one-shot behavior; capacity becomes required only if that call overflows and bounded recovery is needed.

Verification and implementation

Fork implementation and tests: aka-danielZhang#9

The focused dsh-compaction-basic suite passes 153 tests with 100% statements, branches, functions, and lines. Full Harness typecheck and build pass. The fitting one-shot request shape, target precedence, maxTokens, raw output, and KV-cache behavior remain covered as compatibility contracts.

[oludotun]

I can corroborate this on DeepSeek Harness 0.1.3-alpha.1, commit d347e703908d0406b7a7ef80e3a0e594d86b2215, using Windows, the Web profile, the standard preset, and a local Qwen3.8-27B model through openai-completions.

These measurements come from the persisted session events:

Measurement	Observed value
Harness context setting at final failure	45,000 tokens
Server-reported context limit	49,152 tokens
Rejected normal request input	49,398 tokens
Rejected recovery-summary input	49,652 tokens
Last successful compaction output	8,060 tokens
That compaction's configured output cap	8,192 tokens

The final event sequence was:

seq 473  request/context: contextWindow = 45000
seq 474  assistant/attempt: CONTEXT_WINDOW_EXCEEDED
         n_prompt_tokens = 49398, n_ctx = 49152
seq 475  compaction/start
seq 476  compaction/end: context overflow
         n_prompt_tokens = 49652, n_ctx = 49152
seq 478  turn/end: original context-overflow error

Before this, several summary attempts failed with:

summarization truncated at the token cap (incomplete checkpoint)

Fresh-session corroboration: A new conversation started with the 45,000-token harness setting. Two compactions succeeded, reporting 5,773 and 4,061 output tokens, both with maxTokens: 8192. Five subsequent compactions failed with the truncation error, taking 416, 457, 496, 490 and 494 seconds respectively, approximately 39 minutes total. No subsequent context-overflow error had been recorded in that session at the inspected snapshot.

Configuration caveat: The original conversation initially advertised 262,144 tokens while the server allowed 32,768. That contributed to early failures. The later settings and fresh-session observations are included to distinguish that mismatch from the continuing compaction problem.

Diagnostic limitation: Failed summaries did not preserve output or usage in the session log. I cannot prove that every truncation consumed exactly 8,192 tokens, or distinguish reasoning-budget exhaustion from summary length or a server-side generation limit.

The clearest finding is that overflow recovery submitted a summary request larger than the already-rejected normal request, leaving the conversation unable to recover.