Timeout bei der Hermes-Kontextkomprimierung: Lösung

„Context compression timed out before it could commit“ bedeutet, dass Hermes' Zusammenfassungsmodell — das unter auxiliary.compression, nicht Ihr Hauptmodell — keinen Fortschritt machte, bevor Hermes' Komprimierungsbudget ablief, und die Runde beendet wurde, ohne dass der Hauptaufruf gesendet wurde. Das ist versionsabhängig: Wir reproduzierten beide Meldungen mit Hermes Agent v0.21.3 und konnten uns davon erholen, indem der Zusammenfasser zum Antworten gebracht und in derselben Sitzung erneut versucht wurde; mit v0.21.5 führte dasselbe Festhängen statt des Fehlers zu einer langen Wartezeit. Getestet am 1. Oktober 2026 gegen einen Aufzeichnungs-Ersatz für beide Modelle, nicht gegen einen echten Anbieter.

Wenn Sie Hermes gegen Ihren eigenen Endpunkt einrichten, statt es zu debuggen, beginnen Sie mit Hermes Agent mit einer benutzerdefinierten API.

Die beiden Meldungen und was jede Ihnen sagt

Was Sie sehen	Wann sie erschien	Hauptaufruf gesendet?
„Die Kontextkomprimierung hat das Zeitlimit überschritten, bevor sie die Änderungen übernehmen konnte, während die Anfrage noch ungefähr 83.485 Tokens umfasste. Der Anbieteraufruf wurde nicht gesendet. Führen Sie /compress aus, warten Sie auf den Abschluss und versuchen Sie es dann erneut.“	v0.21.3, Zusammenfasser stumm, Anfrage (~83.485 Tokens) größer als das 64.000-Token-Fenster des Modells	Nein
„Die Kontextkomprimierung hat das Zeitlimit überschritten, ohne diese Unterhaltung zu verkürzen. Es wurden keine Nachrichten verworfen. Starten Sie mit /new eine neue Sitzung oder prüfen Sie auxiliary.compression, bevor Sie /compress erneut versuchen.“	v0.21.3, Zusammenfasser stumm, Anfrage (~57.489 Tokens) über dem Komprimierungstrigger von 54.400 Tokens, aber innerhalb des Fensters	Nein

Die Tokenzahl in der ersten Meldung ist Hermes' eigene Schätzung der Anfrage, die es gesendet hätte. Beide Runden endeten im Protokoll als reason=context_compression_timeout mit api_calls=0, nach einer Warnung der Form „Context compression made no progress for 5.0s“ — fünf Sekunden, weil der Test compression.context_timeout_seconds: 5 gesetzt hatte, um die Läufe kurz zu halten; der Standardwert ist 120.

Die verwendete Version entscheidet, was geschieht

Status des Zusammenfassers	v0.21.3 (14. September)	v0.21.5 (24. September)
Stumm, Anfrage innerhalb des Fensters	Runde beendet — zweite Meldung oben	Darauf gewartet (30- und 90-Sekunden-Wartezeiten), 9 Nachrichten zu 5 komprimiert, Anfrage gesendet
Stumm, Anfrage über dem Fenster	Runde beendet — erste Meldung oben	Nicht mit einem stummen Zusammenfasser ausgeführt; die Dokumentation begrenzt diesen Fall durch ein Inaktivitätsbudget und eine deterministische Fallback-Zusammenfassung
Antwortfehler (404)	Zwei Versuche, Komprimierung übersprungen, Anfrage gesendet (innerhalb des Fensters getestet)	Gleich; eine Anfrage über dem Fenster wurde ebenfalls gesendet, was ein echter Anbieter ablehnen würde
Antwortet	Komprimiert und gesendet	Komprimiert und gesendet

Die Grenze steht im Quellcode. In v0.21.4 (Tag v2026.9.21) wurde die Funktion, die eine Runde nach abgelaufener Komprimierung beendet, auf Anfragen oberhalb des Modellfensters eingeschränkt, unter Verweis auf die Issues #113646 und #114594; v0.21.3 beendet jede. Die Konfigurationsdokumentation von v0.21.5 ergänzt dann, dass die Komprimierungswartezeit „mindestens dem eigenen Timeout der Anfrage zur Hilfskomprimierung entspricht (auxiliary.compression.timeout, mindestens 300 s)“ — deshalb bewirkte unsere Einstellung von fünf Sekunden dort nichts. In einem aktuellen Build kostet ein langsamer Zusammenfasser also Minuten Wartezeit statt eines Fehlers, und ein toter wird übersprungen.

Kürzeste Diagnose

Prüfen Sie die Version mit hermes --version. Mit v0.21.3 oder früher sind beide oben genannten Meldungen bei einem festhängenden Zusammenfasser erwartetes Verhalten.
Finden Sie den Zusammenfasser in ~/.hermes/logs/agent.log: Eine Zeile „Auxiliary compression: using <provider> (<model>) at <url>“ nennt das Modell und den Endpunkt, bei dem das Timeout auftrat. Ohne einen auxiliary.compression-Block übernimmt er Ihr Hauptmodell.
Lesen Sie die Triggerzeile: „Pre-API compression: ~N request tokens >= T threshold (context=W)“. Wenn N über W liegt, kann die Runde in keiner Version ungekürzt gesendet werden.
Prüfen Sie das Fenster des Zusammenfassers. Die Hermes-Dokumentation verlangt, dass es mindestens so groß ist wie das des Hauptmodells, da ihm die gesamte Mitte der Unterhaltung gesendet wird.

Verifizierte Wiederherstellung

In jedem oben genannten v0.21.3-Fall erzeugte das Neustarten des Ersatzes mit einem antwortenden Zusammenfasser und das Senden einer weiteren Runde in derselben Sitzung (--resume) eine normale Antwort bei erhaltenem Gespräch. In der Praxis bedeutet das: Richten Sie auxiliary.compression auf ein schnelles Modell, das Sie erreichen können, beheben Sie den Endpunkt, auf den es zeigt, oder erhöhen Sie compression.context_timeout_seconds, wenn Ihr Zusammenfasser langsam, aber gesund ist — etwa ein lokales Modell. Versuchen Sie es dann in derselben Sitzung erneut.

Komprimierung auf einen antwortenden Zusammenfasser richten — die funktionierende Wiederherstellung

# ~/.hermes/config.yaml — the summariser is its own model, with its own budget
auxiliary:
  compression:
    base_url: https://api.kunavo.com/v1   # overrides provider; any OpenAI-compatible endpoint
    api_key: sk-kn-...
    model: claude-haiku-4-5             # fast, and a context window >= your main model's
    timeout: 300

compression:
  context_timeout_seconds: 120   # inactivity budget for the summary (default)
  context_total_ceiling_seconds: 600

Zwei Dinge wurden nicht getestet: Hermes' Desktop- und Messaging-Gateway-Oberflächen, die eine eigene Hygiene-Komprimierung mit anderen Budgets haben, sowie ein echter Anbieter, der eine Anfrage über dem Fenster ablehnt. Die Läufe waren einmalige hermes chat -Q-Runden.

Was es kostet

Eine gestoppte Runde sendet keine Anfrage an das Hauptmodell, daher stellt das Hauptmodell dafür nichts in Rechnung. Die Zusammenfassungsanfrage wurde gesendet — in diesen Läufen etwa 19.000 Zeichen Prompt — und ein Anbieter berechnet sie, wenn sie schließlich abgeschlossen wird. Beim erneuten Versuch fallen dann Kosten für eine Zusammenfassung und einen Hauptaufruf an. Ein kleiner, schneller Zusammenfasser hält sowohl die Wartezeit als auch diese zusätzlichen Kosten gering; bei Kunavo wird Claude Haiku 4.5 zu $0.70 pro Million Eingabetokens und $3.50 pro Million Ausgabetokens angeboten, wobei pro Token von einem vorausbezahlten Guthaben abgerechnet wird. Niemand bei Kunavo hat Hermes gegen seinen Endpunkt ausgeführt; die hier beschriebenen Läufe verwendeten einen lokalen Ersatz.

Häufig gestellte Fragen

Was bedeutet „Context compression timed out before it could commit“ in Hermes?

Hermes versuchte, die Unterhaltung vor dem Senden Ihrer Runde zu verkleinern. Das dafür verwendete Zusammenfassungsmodell machte innerhalb seines Zeitbudgets keinen Fortschritt, und die Anfrage war zu groß, um ungekürzt gesendet zu werden — daher beendete Hermes die Runde, ohne Ihr Hauptmodell überhaupt aufzurufen. Reproduziert mit Hermes Agent v0.21.3 mit einem festhängenden Zusammenfasser und einer Anfrage mit 83.485 Tokens gegenüber einem Fenster von 64.000; die Protokollzeile für die Runde lautete api_calls=0. Ihr Hauptmodell und dessen API-Timeout sind nicht das Problem. Der Zusammenfasser ist es: das Modell unter auxiliary.compression in config.yaml.

Wie behebe ich ein Timeout bei der Hermes-Kontextkomprimierung?

Sorgen Sie dafür, dass der Zusammenfasser antwortet, und versuchen Sie es in derselben Sitzung erneut. In der Reproduktion funktionierte es mit v0.21.3 jedes Mal, wenn auxiliary.compression auf ein antwortendes Modell gerichtet und die nächste Runde in derselben Sitzung gesendet wurde; der Verlauf blieb erhalten — die Meldung selbst besagt, dass keine Nachrichten verworfen wurden. Ein Upgrade verändert die Situation ebenfalls: Ab v0.21.4 beendet eine abgelaufene Komprimierung keine Anfrage mehr, die noch in das Modellfenster passt, und in v0.21.5 wird die Wartezeit für die Zusammenfassung auf das eigene Timeout der Zusammenfassungsanfrage begrenzt, mindestens 300 Sekunden. Eine neue Sitzung mit /new funktioniert ebenfalls, kostet aber den Gesprächskontext.

Ist das Hermes-Komprimierungstimeout behoben?

Teilweise, und es hat seine Form geändert. Bis einschließlich v0.21.3 (14. September 2026) beendete jede abgelaufene Komprimierung im Vorfeld die Runde. v0.21.4 (21. September) beendet nur noch eine Anfrage, die das Kontextfenster des Modells überschreitet. In v0.21.5 (24. September) beendete ein festhängender Zusammenfasser, der 30 und anschließend 90 Sekunden gehalten wurde, die Runde überhaupt nicht: Hermes wartete, komprimierte und sendete die Anfrage — in einer aktuellen Version ist das Symptom eines langsamen Zusammenfassers daher eine lange Pause und nicht dieser Fehler. Ein Zusammenfasser, der tot statt langsam ist, verhält sich anders: Er wird erneut versucht, dann übersprungen, und die Runde wird unkomprimiert fortgesetzt.

Hilft das Erhöhen von HERMES_API_TIMEOUT?

Nein. Diese Variable steuert den Aufruf des Hauptmodells, standardmäßig 1.800 Sekunden. Die Komprimierung hat eigene Budgets in config.yaml: compression.context_timeout_seconds (ein Inaktivitätsbudget, standardmäßig 120 Sekunden), compression.context_total_ceiling_seconds (standardmäßig 600) und auxiliary.compression.timeout für die Zusammenfassungsanfrage selbst. Die Hermes-Dokumentation enthält außerdem eine Anforderung, die ebenso wichtig wie die Geschwindigkeit ist: Das Kontextfenster des Zusammenfassungsmodells muss mindestens so groß sein wie das des Hauptmodells, da es die gesamte Mitte der Unterhaltung erhält.

Hat die abgelaufene Runde etwas gekostet?

Not on the main model: the turn ended before the main call was sent. The summary request was sent, though, and a summariser that eventually finishes is billed by its provider like any other call — in the runs here the summary prompt was about 19,000 characters. The retry then pays for one summary and one main call. That is why pointing compression at a small, fast model is cheaper as well as quicker: on Kunavo, Claude Haiku 4.5 lists at $0.70 per million input tokens.

Reproduziert am 1. Oktober 2026 mit Hermes Agent v0.21.3 (Tag v2026.9.14) und v0.21.5 (Tag v2026.9.24), installiert aus deren Release-Quellen, gegen einen lokalen Aufzeichnungs-Ersatz, der sowohl das Haupt- als auch das Zusammenfassungsmodell bereitstellte (Antworten für einen festhängenden Zusammenfasser zurückhielt, 404 für einen fehlerhaften zurückgab), mit einem 64.000-Token-Fenster und vier fortgesetzten Füllrunden vor der Testrunde. Die Versionsgrenze wurde aus agent/turn_context.py an den Tags v2026.9.14, v2026.9.21 und v2026.9.24 abgelesen, die Budgets aus der Konfigurationsdokumentation jedes Tags. Der Ersatz ist weder ein Modell noch ein Anbieter: Er akzeptiert jede Anfragegröße, daher wurden anbieterbasierte Kontextfehler nicht reproduziert.