fix: a turn is not a unit of size, and a summary of a summary is not a compaction

[webmatze]

Behebt #118.

Was falsch war

Das Recency-Window zählt Turns, keine Tokens. Ein langer Agentenlauf — ein Prompt, dann hundert Tool-Calls — ist ein Turn, also deckte das Fenster, das die letzten drei Turns schützen soll, die gesamte Historie ab:

• window_start gibt 0 zurück, sobald es nicht mehr echte Turns gibt als das Fenster breit ist → alle vier billigen Stages brechen bei der ersten Nachricht ab
• safe_cut_index findet keine Grenze, deren Tail passt, und fällt auf die neuste zurück
• ab der zweiten Kompaktierung ist der Prefix genau eine Nachricht: die Summary der ersten

Ergebnis in einer echten Session: ~105421 → ~105341 tokens, 0% of the budget reclaimed · summarize, in jedem Turn — jedes Mal ein Provider-Call und eine Prompt-Cache-Invalidierung, um eine Summary gegen die nächste zu tauschen, während die 76 k Tokens Tool-Output hinter dem Cut nie Kandidat waren.

Der Notausgang, der das Fenster ignoriert, existierte schon — er hing an cut.zero?, also an der einen Form, die dieser Fall nie annimmt.

Was sich ändert

1. Der Notausgang läuft jetzt, wenn der Tail, der den Cut überlebt, selbst über dem Target liegt. cut.zero? ist der Fall ohne Grenze, das hier der Fall, in dem keine Grenze hilft — dieselbe Sackgasse über einen anderen Weg. Danach wird die Grenze gegen die verkürzte Historie neu gewählt, und was jetzt passt, wird zurückgegeben statt umsonst zusammengefasst.
2. Ein Prefix, der nur die letzte Summary ist, wird vor dem Call abgelehnt — erkannt an SUMMARY_PREFIX, den Schreiber und Leser jetzt teilen. Bewusst am Text statt an einem Flag: eine resumte Session holt ihre Historie über dieselbe JSON zurück wie jede andere Nachricht, und ein Flag, das den Roundtrip nicht überlebt, würde die Guard frisch greifen und resumt aussetzen lassen.
3. Eine Summary, die länger zurückkommt als die Turns, die sie ersetzt, wird verworfen. Den Call bezahlen, das Detail verlieren und den Request vergrößern ist das eine Ergebnis, für das nichts spricht.

Messung

Reproduktion: ein kurzer Turn, dann 30 Tool-Ergebnisse à 8 KB, Budget 70 000.

	vorher	nachher
stages	["summarize"]	["truncate"]
tokens	60212 → 60168	60212 → 34249
reclaimed	44 (0 %)	25963 (74 %)
target erreicht	nein	ja
Provider-Calls	1 pro Turn	0

Für den Review

Fidelity-Tradeoff, bewusst: ein großes read_file-Ergebnis im laufenden Turn kann jetzt gekürzt werden, bevor das Modell darauf reagiert hat. Vorher machte der cut.zero?-Zweig dieses Zugeständnis nur im entarteten Einzelturn-Fall, jetzt gilt es in jeder Session, in der ein Turn über das Target wächst. Gemildert dadurch, dass truncate_old_tool_results größtes-zuerst geht und abbricht, sobald das Target erreicht ist — in der Messung oben bleiben von 240 KB Tool-Output 136 KB stehen, kleine junge Ergebnisse überleben also. Die Alternative wäre ein Request, den der Provider ablehnt.

Der Strategy::None-Fall bleibt still, wenn Compaction nichts ausrichten kann. Das ist unverändert — der alte cut.zero?-Pfad gab dasselbe zurück.

Tests

Jede der drei Änderungen fällt einzeln durch eine eigene Spec, wenn man sie zurücknimmt — nachgeprüft, nicht behauptet. Die erste Fassung der Summary-Guard-Spec traf die Guard nicht (sie kam über den Notausgang ans Ziel) und ist ersetzt.

crystal spec: 1352 Beispiele, 0 Fehler. crystal tool format --check: sauber.

🤖 Generated with Claude Code