Proposal: Zero-loss pruning (spill-copy-on-prune)

[adamteale]

Proposal: Zero-loss pruning (spill-copy-on-prune)

Context

DeepSeek Harness's compaction-tool-result-pruner (threshold 8192, head 4096, tail 1024) and spill-policy (maxInlineBytes 50000) are independent mechanisms:

• Prune tier (8K–50K): permanently drops the middle with a fixed marker [... tool result middle pruned ...] — no recovery path.
• Spill tier (>50K): writes full output to disk, inline preview with locator.

The prune tier's permanent loss is by design but unnecessary — the spill infrastructure already exists.

Proposal

Merge the tiers: when the prune tier fires, also write the full output to a spill file (same ctx.spillStore), and include the file path + exact elided span [start, end) in the marker. The middle is dropped from context (same context savings) but recoverable from disk (zero information loss).

Marker upgrade

Current: [... tool result middle pruned ...]

Proposed (with spill copy):

[pruned — full output at <spill-path>; grep to recover]

<head 4096>

[... middle pruned: 4390 code points omitted [4096, 8486); full output at <spill-path>; grep or slice to recover ...]

<tail 1024>

The short prefix at position 0 survives compaction serialization (which truncates tool results to 2000 chars). The full marker in the middle gives exact offsets for precise recovery. The model uses these to grep or sed -n 'START,ENDp' the spill file.

Recovery-loop prevention

read results targeting a file inside the spill directory should pass through untouched — otherwise reading a spill file to recover the pruned middle would re-prune it (infinite loop).

Evidence

Benchmarked with 19 live sessions (glm-5.3 + deepseek-v4-flash) using a pi extension implementing this design:

Scenario	Standard	With zero-loss pruning	Δ
Uncached prefill	10-16K tok	1.5-3K tok	−72% to −88%
Transcript chars	51-55K	3-10K	−81% to −93%
Correctness	✓	✓ (same answers)	parity
Hallucinations	0	0	—
Recovery via spill file	N/A	confirmed (grep + sed)	—

Key finding: a deepseek-v4-flash model, given a 30K fake test log with an AssertionError at position 12K (in the pruned middle), recovered the correct root cause by grep-ing the spill file for FAIL|AssertionError then sed-ing the exact lines. Zero hallucination — the marker's omission count made the loss legible.

Implementation notes

This is a plugin-level change in dsh's architecture — the pruner plugin would call ctx.spillStore before dropping the middle. No core changes needed (everything is a plugin). The dsh-plugin topic exists for this kind of contribution.

Config: pruneSpillCopy: boolean (default true; false reverts to current permanently-lossy behaviour for disk-constrained environments).

Files

• Working extension code (pi): ~/.pi/agent/extensions/tool-result-pruner/ — 32 tests, tsc clean
• Benchmark harness: /tmp/pi-bench/ — prompts, driver, analyzer, 19 session transcripts

[Electricitysheep]

zero-loss pruning（spill-copy-on-prune）——压缩时保留完整工具结果的副本，比直接剪枝稳（剪了还能找回）。

和 compaction 的"summary 后仍可回溯"理念一致，第 14 章上下文/成本管理可作参考：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/14-cost.md

[adamteale]

Thanks for the reference — the traceability principle is exactly the insight here. We benchmarked this with 19 live sessions (glm-5.3 + deepseek-v4-flash): the prune tier saves 72–88% uncached prefill tokens while the spill copy makes the pruned middle recoverable via grep/sed on the file. The key design detail is a compaction-safe prefix marker at position 0 (pi's compaction serialises tool results to 2000 chars, so a marker at position ~4096 would be silently lost). The exact elided span [start, end) in the marker lets the model compute precise slice offsets for recovery — we observed models doing sed -n '155,180p' on the spill file to extract the exact region they needed.

[pinghe]

@tianyicui @zhanglunet