« Context compression timed out before it could commit » signifie que le modèle de résumé de Hermes — celui défini sous auxiliary.compression, et non votre modèle principal — n’a pas progressé avant l’épuisement du budget de compression de Hermes, et que le tour a été arrêté sans envoi de l’appel principal. Le comportement dépend de la version : nous avons reproduit ses deux messages sur Hermes Agent v0.21.3 et récupéré la situation en faisant répondre le résumeur puis en réessayant dans la même session, tandis que sur v0.21.5 le même blocage a produit une longue attente plutôt que l’erreur. Testé le 1er octobre 2026 avec un substitut d’enregistrement pour les deux modèles, et non avec un fournisseur réel.
Si vous configurez Hermes avec votre propre endpoint plutôt que de le déboguer, commencez par Hermes Agent avec une API personnalisée.
Les deux messages et ce que chacun vous indique
| Ce que vous voyez | Quand il est apparu | Appel principal envoyé ? |
|---|---|---|
| "La compression du contexte a expiré avant de pouvoir valider les changements, alors que la requête contenait encore environ 83 485 tokens. L'appel au fournisseur n'a pas été envoyé. Exécutez /compress et attendez la fin de son exécution, puis réessayez." | v0.21.3, résumeur silencieux, requête (~83,485 tokens) supérieure à la fenêtre de 64,000 tokens du modèle | Non |
| "La compression du contexte a expiré sans réduire cette conversation. Aucun message n'a été supprimé. Démarrez une nouvelle session avec /new, ou vérifiez auxiliary.compression avant de réessayer /compress." | v0.21.3, résumeur silencieux, requête (~57,489 tokens) dépassant le seuil de compression de 54,400 tokens mais restant dans la fenêtre | Non |
Le nombre de tokens indiqué dans le premier message est l'estimation par Hermes de la requête qu'il aurait envoyée. Les deux tours se sont terminés dans le journal par reason=context_compression_timeout avec api_calls=0, après un avertissement de la forme "Context compression made no progress for 5.0s" — cinq secondes parce que le jeu de tests définissait compression.context_timeout_seconds: 5 pour raccourcir les exécutions ; la valeur par défaut est 120.
La version utilisée détermine ce qui se passe
| État du résumeur | v0.21.3 (14 septembre) | v0.21.5 (24 septembre) |
|---|---|---|
| Silencieux, requête dans la fenêtre | Tour arrêté — deuxième message ci-dessus | A attendu (pauses de 30 s et 90 s), a compressé 9 messages en 5, puis a envoyé la requête |
| Silencieux, requête dépassant la fenêtre | Tour arrêté — premier message ci-dessus | Non exécuté avec un résumeur silencieux ; la documentation encadre ce cas par un seul budget d'inactivité et un résumé de secours déterministe |
| Erreurs de réponse (404) | Deux tentatives, compression ignorée, requête envoyée (testée dans la fenêtre) | Même résultat ; une requête dépassant la fenêtre a également été envoyée, ce qu'un véritable fournisseur rejetterait |
| Réactif | Compressé et envoyé | Compressé et envoyé |
La limite se trouve dans le code source. Dans v0.21.4 (tag v2026.9.21), la fonction qui arrête un tour après l'expiration d'une compression a été restreinte aux requêtes dépassant la fenêtre du modèle, en citant les problèmes #113646 et #114594 ; v0.21.3 arrête toutes les requêtes. La documentation de configuration de v0.21.5 ajoute ensuite que l'attente de compression « is floored at the auxiliary compression request's own timeout (auxiliary.compression.timeout, minimum 300s) » — c'est pourquoi notre réglage de cinq secondes n'a rien changé dans cette version. Ainsi, avec une version actuelle, un résumeur lent vous fait attendre plusieurs minutes au lieu de générer une erreur, tandis qu'un résumeur inactif est ignoré.
Diagnostic le plus court
- Vérifiez la version avec
hermes --version. Avec v0.21.3 ou une version antérieure, les deux messages ci-dessus constituent le comportement attendu pour un résumeur bloqué. - Trouvez le résumeur dans
~/.hermes/logs/agent.log: une ligne « Auxiliary compression: using <provider> (<model>) at <url> » indique le modèle et l'endpoint ayant expiré. En l'absence de blocauxiliary.compression, il hérite de votre modèle principal. - Lisez la ligne de déclenchement : « Pre-API compression: ~N request tokens >= T threshold (context=W) ». Si N est supérieur à W, le tour ne peut sortir dans aucune version sans être réduit.
- Vérifiez la fenêtre du résumeur. La documentation de Hermes exige qu'elle soit au moins aussi grande que celle du modèle principal, car le résumeur reçoit tout le milieu de la conversation.
Récupération vérifiée
Dans tous les cas v0.21.3 ci-dessus, redémarrer le substitut avec un résumeur qui répondait, puis envoyer un tour supplémentaire dans la même session (--resume), a produit une réponse normale, la conversation restant intacte. En pratique, cela signifie l'une des actions suivantes : pointer auxiliary.compression vers un modèle rapide auquel vous pouvez accéder, corriger l'endpoint vers lequel il pointe, ou augmenter compression.context_timeout_seconds si votre résumeur est lent mais sain — par exemple un modèle local. Réessayez ensuite dans la même session.
# ~/.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: 600Deux éléments n'ont pas été testés : les surfaces Desktop et messaging-gateway de Hermes, qui disposent de leur propre compression d'hygiène avec des budgets différents, ainsi que le rejet réel par un fournisseur d'une requête dépassant la fenêtre. Les exécutions consistaient en des tours hermes chat -Q uniques.
Ce que cela coûte
Un tour arrêté n'envoie aucune requête au modèle principal, qui ne vous facture donc rien. La requête de résumé a été envoyée — environ 19,000 caractères d'invite dans ces exécutions — et un fournisseur la facture si elle s'achève finalement. La nouvelle tentative paie ensuite un résumé et un appel principal. Un résumeur petit et rapide réduit l'attente ainsi que ces frais généraux ; sur Kunavo, Claude Haiku 4.5 est tarifé $0.70 par million de tokens d'entrée et $3.50 par million de tokens de sortie, facturés par token à partir d'un solde prépayé. Personne chez Kunavo n'a exécuté Hermes avec son endpoint ; les exécutions présentées ici utilisaient un substitut local.
Questions fréquentes
Que signifie « Context compression timed out before it could commit » dans Hermes ?
Hermes a tenté de réduire la conversation avant d’envoyer votre tour, le modèle de résumé utilisé n’a pas progressé dans le délai qui lui était imparti, et la requête était trop volumineuse pour être envoyée sans réduction — Hermes a donc arrêté le tour sans appeler votre modèle principal. Reproduit sur Hermes Agent v0.21.3 avec un résumeur bloqué et une requête de 83,485 tokens pour une fenêtre de 64,000 tokens ; la ligne du journal pour ce tour indiquait api_calls=0. Votre modèle principal et son délai d’expiration API ne sont pas en cause. Le problème vient du résumeur : le modèle défini sous auxiliary.compression dans config.yaml.
Comment corriger un délai d’expiration de compression du contexte Hermes ?
Faites répondre le résumeur, puis réessayez dans la même session. Lors de la reproduction, rediriger auxiliary.compression vers un modèle réactif puis envoyer le tour suivant dans la même session a fonctionné à chaque fois sur v0.21.3, avec l’historique intact — le message lui-même indique qu’aucun message n’a été supprimé. La mise à niveau change également la situation : à partir de v0.21.4, une compression expirée n’arrête plus une requête qui tient encore dans la fenêtre du modèle, et dans v0.21.5 l’attente du résumé est plafonnée au délai de la requête du résumeur elle-même, à au moins 300 secondes. Démarrer une nouvelle session avec /new fonctionne aussi, au prix du contexte de la conversation.
Le délai d’expiration de compression Hermes est-il corrigé ?
Partiellement, et le comportement a changé. Jusqu’à v0.21.3 (14 septembre 2026), toute compression préalable expirée arrêtait le tour. v0.21.4 (21 septembre) n’arrête que les requêtes dépassant la fenêtre de contexte du modèle. Dans v0.21.5 (24 septembre), un résumeur bloqué pendant 30 puis 90 secondes n’a pas arrêté le tour : Hermes a attendu, compressé et envoyé la requête. Dans une version actuelle, le symptôme d’un résumeur lent est donc une longue pause, et non cette erreur. Un résumeur qui est mort plutôt que lent constitue un cas différent : Hermes réessaie, l’ignore, puis le tour continue sans compression.
Augmenter HERMES_API_TIMEOUT aide-t-il ?
Non. Cette variable régit l’appel au modèle principal, avec une valeur par défaut de 1 800 secondes. La compression possède ses propres budgets dans config.yaml : compression.context_timeout_seconds (budget d’inactivité, 120 secondes par défaut), compression.context_total_ceiling_seconds (600 par défaut) et auxiliary.compression.timeout pour la requête de résumé elle-même. La documentation de Hermes ajoute une exigence tout aussi importante que la vitesse : la fenêtre de contexte du modèle de résumé doit être au moins aussi grande que celle du modèle principal, car il reçoit l’intégralité de la partie centrale de la conversation.
Le tour ayant expiré a-t-il coûté quelque chose ?
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.
Reproduit le 1er octobre 2026 avec Hermes Agent v0.21.3 (tag v2026.9.14) et v0.21.5 (tag v2026.9.24), installés à partir des sources de leurs versions publiées, avec un substitut local enregistrant les requêtes et tenant lieu à la fois de modèle principal et de modèle de résumé (réponses retenues pour un résumeur bloqué, code 404 renvoyé pour un résumeur défaillant), avec une fenêtre de 64 000 tokens et quatre tours repris de texte de remplissage avant le tour de test. La limite entre les versions a été lue dans agent/turn_context.py aux tags v2026.9.14, v2026.9.21 et v2026.9.24, et les budgets dans la documentation de configuration de chaque tag. Le substitut n'est ni un modèle ni un fournisseur : il accepte toute taille de requête, de sorte que les erreurs de contexte côté fournisseur n'ont pas été reproduites.