Hermes-Compaction bekommt einen schlanken Default: Große Fenster horten keine 170K-Token-Tails mehr

Stell dir vor: Du fährst eine Marathonsession auf einem 1M-Kontext-Modell, kommst auf eine halbe Million Tokens, es wird langsam, du tippst /compress, um den Kontext zu verschlanken – und die Session schrumpft kaum. Jeder weitere Turn schickt trotzdem einen „Schwanz“ von über hunderttausend Tokens an das Modell, und deine Rechnung bläht sich leise auf. Das ist keine Einbildung: Die Legacy-Kompressionsformel skaliert den wortgetreuen Tail mit Fenstergröße und Schwellwert, also hortet sie bei großen Fenstern still 100K–240K Tokens wortgetreuer Historie aus jeder Kompression. Ein am 26. August gemergter Commit (6e5413844e) hat den Default umgedreht: Der neue Lean-Modus behält nur einen kleinen, geklemmten Tail – und der gewonnene Platz ist enorm.
Warum die alte Formel bei modernen Modellen zu horten begann
Wenn die Kompression läuft, teilt Hermes die Session in eine „Zusammenfassung“ (Langzeitgedächtnis) und einen „Tail“ (aktuelle wortgetreue Inhalte für die Kontinuität). Das Legacy-Default-Budget war threshold × target_ratio – eine Formel, die für 128K-Fenster bei 50-%-Auslöser entworfen wurde und einen vernünftigen Tail von ~13K Tokens ergab.
Aber als die Fenster der Modelle wuchsen, skalierte die Formel proportional weiter: Eine 1M-Session bei Schwellwert 0.85 bekommt im Legacy-Modus einen wortgetreuen Tail von 170K Tokens (weiche Obergrenze 255K). Ein manuelles /compress bei 540K landet bei ~290K – die Hortung macht Kompression sinnlos, und jeder Turn schickt diese Tokens erneut an das Modell: Geld verbrennt doppelt.
Der neue Default: Lean-Modus (#87326 compaction-v2)
Der Lean-Modus behandelt den Tail als kleines Rezent-Fenster statt als Kontext-Hort. Konkret:
- Tail-Budget = 2,5 % der Fenstergröße, mindestens 10K und maximal 25K Tokens;
- Kontinuität hängt nicht mehr von einem großen Tail ab – sie trägt die aufgewertete Zusammenfassung: Content-Digests, einen Anker-Index, wortgetreue User-Messages und
session_search-Recovery-Pointer; - Der Recall wurde in einem Vorher/Nachher-Eval validiert (
evals/compaction/results/), nicht nach Augenmaß.
Seite an Seite (echte Imports, 1M-Fenster @ 0.85-Schwellwert):
| Szenario | Budget für den wortgetreuen Tail |
|---|---|
| Alter Default (legacy) | 170.000 (Obergrenze 255.000) |
| Neuer Default (lean) | 25.000 (Obergrenze 37.500) |
| Explizit zurück zu legacy | 170.000 (Opt-out intakt) |
| Modellwechsel mitten in der Session auf ein 400K-Modell (lean bleibt erhalten) | 10.000 |
Es behebt auch einen latenten Bug: update_model() hat beim Neuberechnen der Budgets früher direkt wieder die Legacy-Formel zugewiesen und einen Lean-Kompressor bei jedem Modellwechsel mitten in der Session still zurück ins Horten versetzt. Die Neuberechnung läuft jetzt über die modusbewusste tail_token_budget-Property (Regressionstest inklusive).
Einstellung prüfen und anpassen
Sieh dir deine aktuelle Konfiguration an:
hermes config get compression.tail_mode # jetzt standardmäßig lean
hermes config get compression.threshold # Default 0.50 (50-%-Auslöser)
hermes config get compression.target_ratio # Default 0.20
Um das alte Verhalten wiederherzustellen, setze es explizit in der config.yaml:
compression:
tail_mode: legacy # alte Formel: 0.20 × threshold, hortet bei großen Fenstern
Hinweis: compression.tail_mode ist jetzt auch ein Cache-Busting-Key fürs Gateway – eine Änderung räumt gecachte Gateway-Agenten ab, genau wie Änderungen an target_ratio, ohne dass ein kompletter Gateway-Neustart nötig ist.
Wann welcher Modus?
Für die meisten Leute gilt: beim schlanken Default bleiben. Er spart Geld, schafft bei /compress echten Platz, und die Zusammenfassung trägt Recovery-Pointer als Sicherheitsnetz. Nur wenn du wirklich feststellst, dass nach der Kompression „wichtige Informationen verloren gegangen“ sind (etwa eine kritische Tool-Ausgabe in einer langen Session, die der Digest nicht abgedeckt hat), lohnt der Wechsel zurück zu Legacy zum Vergleich – zum Preis von zig tausend zusätzlichen Input-Tokens pro Turn.
Fazit
Diese Änderung bringt die Frage „wie viel Originaltext soll behalten werden?“ von einem formelbedingten Zufall zu begrenztem Engineering: Kontinuität kommt aus einer intelligenteren Zusammenfassung, und der Tail ist nur ein Rezent-Fenster. Wenn sich /compress bei großen Fenstern nutzlos angefühlt hat, aktualisiere auf den neuesten Dev-Build und versuch es noch einmal – der Unterschied ist wie Tag und Nacht. Kompression ist nur ein Teil der Ausdauer für lange Sessions: Kombiniere sie mit unbegrenzten max_turns und Session-Export, dann laufen lange Aufgaben sorgenfrei. Für die vollständige Feld-für-Feld-Übersicht der Kontext-Budgets siehe den Long-Task-Konfigurations-Guide.