Drei Stunden steckst du in einer langen Aufgabe — einer Migration, einem Bug über zwanzig Dateien, einer Datenbereinigung, die einfach nicht enden will. Dann fällt es dir auf: Jede neue Nachricht braucht länger für die Antwort, und das Dashboard des Providers zeigt, dass diese eine Session mehr Tokens verbraucht hat als der ganze Rest des Monats zusammen. Das ist kein Zufall. Bei jedem Turn muss das Modell das gesamte Gespräch neu lesen — einschließlich der Tool-Ausgaben und Zwischenschritte, die vor zwei Stunden schon irrelevant waren. Je größer dieser Haufen wird, desto teurer wird jeder Satz. Hermes nennt die Lösung dafür „Context Reduction“, und seit v0.20 Anfang August erschien, sind die offiziellen Werkzeuge dafür leise sehr gut geworden. Dieser Leitfaden führt durch jede verifizierbare Ebene: was du durch ein Update gratis bekommst, welche Konfigurations-Stellschrauben wirklich zählen und welche Slash-Befehle eine lange Session in Form halten.

Warum jeder Turn alles erneut sendet

Ein kurzes mentales Modell: Ein LLM hat kein eigenes Gedächtnis. Jedes Mal, wenn du eine Nachricht sendest, erhält es den kompletten Kontext — System-Prompt, geladene Skills, Tool-Definitionen, deine Memory-Dateien, den Gesprächsverlauf und jedes Tool-Ergebnis — und liest ihn neu. „Tokens“ sind nur das Maß für diesen Text, und du zahlst für jeden Token, den du sendest, bei jedem Turn.

Die Gesamtkosten einer Session sind also ungefähr Kontextgröße × Anzahl der Turns. Schrumpfe einen der beiden Faktoren und die Rechnung sinkt sofort. Genau darum geht es bei Context Reduction: die Informationen behalten, die die Antwort verbessern, und das Duplizierte, Veraltete oder Irrelevante verwerfen — ohne den Agenten dümmer zu machen.

Ebene 1: Automatische Kompression — arbeitet bereits für dich

Hermes bringt ein duales Kompressionssystem mit, das ohne Einrichtung von selbst läuft:

• Agent ContextCompressor — das primäre System, im Tool-Loop des Agents, mit präzisen, API-gemeldeten Token-Zahlen. Es feuert, wenn die Session 50 % des Kontextfensters des Modells überschreitet (konfigurierbar).
• Gateway Session Hygiene — ein Sicherheitsnetz bei 85 % des Kontexts, das vor jedem Turn läuft. Es fängt Sessions ab, die zwischen Turns zu groß geworden sind (z. B. eine nächtliche Ansammlung in Telegram oder Discord), damit die API nie an einer überdimensionierten Anfrage scheitert.

Wenn die Kompression auslöst, arbeitet sie in vier Phasen:

1. Alte Tool-Ergebnisse entfernen — die ältesten Tool-Ausgaben werden zuerst verworfen. Dieser Schritt kostet nichts: kein LLM-Aufruf.
2. Grenzen ausrichten — der Kompressor geht rückwärts, sodass ein „Tool-Call → Tool-Result“-Paar nie auseinandergerissen wird.
3. Strukturierte Zusammenfassung erstellen — die Gesprächsmitte wird an ein Hilfsmodell geschickt, das eine strukturierte Zusammenfassung über Ziele, Entscheidungen, Fortschritt und nächste Schritte schreibt. Das Zusammenfassungsbudget skaliert mit dem Inhalt (etwa 20 %), mindestens 2.000 Tokens, gedeckelt bei 5 % des Kontextfensters.
4. Zusammenbauen — die komprimierte Session besteht aus: Kopf (System-Prompt + früher Kontext) + Zusammenfassung + jüngstem Original-Tail.

Die offizielle Doku zeigt ein durchgerechnetes Beispiel: Eine Session mit 45 Nachrichten (~95K Tokens) komprimiert auf 25 Nachrichten (~45K Tokens) — eine Reduktion von rund 53 %, wobei Zusammenfassung und jüngster Tail die Kontinuität halten.

Ebene 2: Aktualisieren, und der v0.20-Umbau greift

Die Version v0.20.0 (3. August) hat die Kompression tiefgreifend überarbeitet — „Compression that respects your conversation“. Die wichtigsten Änderungen, alle upstream gemergt und in den Release-Notes nachprüfbar:

• Micro-Compaction pro Turn — statt einer großen, stockenden Pause beim Erreichen der Schwelle wird die Kostenlast in kleinen Schritten über Turns verteilt.
• N-User-Messages-Tail-Garantie — compression.min_tail_user_messages (Standard 1) stellt sicher, dass jüngste echte Nutzernachrichten die Kompaktion immer überleben. Du verlierst nie den Faden dessen, was du gefragt hast.
• Proaktives Tool-Result-Pruning — Modelle mit großem Fenster entfernen veraltete Tool-Ergebnisse schon vor der Schwelle.
• Ghost-Skill-Abwehr — eine mitten in der Session entfernte Skill kann den Kontext nicht mehr still heimsuchen ([SKILL_PRUNED]-Marker machen das Pruning deterministisch).
• Schwellen pro Modell und absolute Token-Schwellen — Kompression lässt sich pro Modell bei verschiedenen Prozentwerten oder bei einer festen Token-Zahl auslösen (compression.threshold_tokens) — wichtig, wenn deine Modelle sehr unterschiedliche Fenster haben.

Das neueste Stück kam am 26. August: der Lean-Tail-Modus (PR #87326). Die alte Formel hielt einen Original-Tail proportional zur Fenstergröße — bei einem 1M-Kontextmodell bedeutete das 170K Tokens roher Verlauf nach jeder Kompression, was /compress fast nutzlos machte und diese Tokens bei jedem Turn erneut verschickte. Der Lean-Modus klemmt den Tail auf 2,5 % des Fensters (10K–25K Tokens) und verlagert die Kontinuität in eine verbesserte Zusammenfassung mit Wiederherstellungszeigern. Eine Einstellungsänderung, zehntausende Tokens pro Turn gespart. Wenn hermes config get compression.tail_mode noch legacy zeigt, führe hermes update aus — der neue Standard ist lean.

Ebene 3: Stellschrauben, die du drehen kannst

Die Kompressions-Standards sind vernünftig, aber etwas Feintuning zahlt sich schnell aus. Schau zuerst, was du hast:

hermes config get compression.enabled             # true
hermes config get compression.threshold           # 0.50 (löst bei 50 % des Kontexts aus)
hermes config get compression.target_ratio        # 0.20
hermes config get compression.tail_mode           # lean bei aktuellen Builds
hermes config get compression.protect_last_n      # 20 (mindestens geschützte Tail-Nachrichten)
hermes config get compression.min_tail_user_messages  # 1

Drei Anpassungen zählen am meisten:

1. Bei großen Fenstern früher auslösen. Wenn du ein 200K+-Modell nutzt, heißt Warten bis 50 %, dass jeder Turn schon ~100K Tokens sendet. Setze compression.threshold auf 0,4 — oder besser, eine feste absolute Schwelle:

compression:
  enabled: true
  threshold_tokens: 80000    # komprimieren, sobald die Session 80K Tokens überschreitet

2. Schwellen pro Modell setzen. Verschiedene Fenster, verschiedene Preise:

compression:
  model_thresholds:
    "claude-sonnet": 0.35
    "glm-5.2": 0.40

3. Die Zusammenfassung billiger machen. Der Summarizer ist ebenfalls ein LLM-Aufruf — standardmäßig nutzt er ein sinnvolles auto-erkanntes Modell, aber du kannst ihn auf ein billiges, schnelles Modell zeigen:

auxiliary:
  compression:
    model: <ein billiges, schnelles Modell>

Kompressions-Zusammenfassungen sind nicht der Ort für dein teuerstes Modell.

Ebene 4: Tägliche Hygiene

Die vier Slash-Befehle, die dir zeigen, was los ist, und dir Handeln erlauben:

Befehl	Was er tut
/context	Schlüsselt genau auf, was dein Kontextfenster füllt — Skills, Tools, Memory, Verlauf, Dateien
/usage	Zeigt Token-Verbrauch und Kosten der Session (hermes insights deckt die letzten 30 Tage ab)
/compress	Löst manuell eine Kompression mitten in der Session aus
/focus	Reduzierte Ausgabeansicht, die verrauschte Tool-Zeilen ausblendet, aber wiederherstellbar hält

Über Befehle hinaus senken ein paar Gewohnheiten den festen Overhead, der bei jedem Turn mitreist:

• Skills deaktivieren, die du nicht nutzt. Jede aktivierte Skill injiziert ihren Kopf in den Kontext jedes Turns. hermes skills list, dann hermes skills disable <name> für die ungenutzten.
• tool_search auf auto stellen. Tools laden nur bei Bedarf, statt jedes Turn alle Schemas zu senden.
• Memory und AGENTS.md schlank halten. Jedes Zeichen injizierter Memory und Projektanweisungen wird bei jeder Nachricht erneut gesendet. Speichere dauerhafte Fakten, keinen Aufgabenfortschritt.
• Mitten in der Session nicht das Modell wechseln. Die meisten Provider cachen das Prompt-Präfix — ein stabiler System-Prompt lässt Folgeturns den Cache treffen und kostet einen Bruchteil. Ein Modellwechsel invalidiert ihn.
• Delegieren oder bündeln. Lange Recherchen per delegate_task oder Dateioperationen in einem execute_code-Skript halten sperrige Zwischenausgaben aus dem Hauptgespräch heraus.

Alles zusammengefügt

Nichts davon opfert Fähigkeiten. Das offizielle Beispiel zeigt allein ~95K → ~45K in einer typischen langen Session, und bei Modellen mit großem Fenster entfernt der Lean-Tail-Wechsel weit über hunderttausend Tokens pro Turn, die reiner Overhead waren. Automatische Kompression verwaltet den Verlauf; der v0.20-Umbau macht sie sanfter und billiger; ein paar Konfigurationszeilen passen sie an deine Modelle an; tägliche Hygiene verhindert, dass der Haufen überhaupt wächst.

Zwei Warnungen. Erstens: Setze die Schwelle nicht so aggressiv, dass der Agent ständig komprimiert — jede Zusammenfassung ist ein kleiner LLM-Aufruf, und wiederholtes Komprimieren einer kurzen Session verbrennt Geld für Zusammenfassungen statt Antworten. Zweitens: Context Reduction zielt auf duplizierten, veralteten oder irrelevanten Inhalt — wenn die Session wirklich riesig ist und alles braucht, sind unbegrenzte max_turns mit Session-Export die bessere Wahl als das Ausquetschen der Kompression.

Zur Geschichte hinter dem neuen Lean-Tail-Standard und echten Zahlen bei großen Fenstern: Hermes Compaction Gets a Lean Default. Wenn deine Rechnung sprang, weil ein Kontextfenster größer gesetzt war, als dein Provider ausweist: Why Your Subscription Drained in Hours. Und für die Feld-für-Feld-Aufschlüsselung des Kontextbudgets ist der Long-Task-Konfigurationsleitfaden der Lesezeichen-Tiefgang.