Le Régime Contexte de Hermes : Réduisez la Facture de Tokens par Tour, à l'Officielle

Vous êtes à trois heures d’une longue tâche — une migration, un bug qui traverse vingt fichiers, un nettoyage de données qui ne cesse de grossir. Puis vous le remarquez : chaque nouveau message met plus de temps à répondre, et le tableau de bord du fournisseur montre que cette session a consommé plus de tokens que tout le reste du mois réuni. Ce n’est pas un hasard. À chaque tour, le modèle doit relire toute la conversation — y compris les sorties d’outils et les étapes intermédiaires devenues inutiles il y a deux heures. Plus cette pile grossit, plus chaque phrase coûte cher. Hermes appelle la solution « réduction de contexte », et depuis v0.20 début août, les outils officiels sont discrètement devenus très bons. Ce guide parcourt chaque couche vérifiable : ce que vous obtenez gratuitement en mettant à jour, quels boutons de configuration comptent vraiment, et les commandes slash qui gardent une longue session en forme.
Pourquoi chaque tour renvoie tout
Un modèle mental rapide : un LLM n’a pas de mémoire propre. À chaque message, il reçoit le contexte complet — prompt système, skills chargés, définitions d’outils, vos fichiers de mémoire, l’historique de conversation et chaque résultat d’outil — et le relit. Les « tokens » ne sont que la mesure de ce texte, et vous payez chaque token envoyé, à chaque tour.
Le coût total d’une session est donc à peu près taille du contexte × nombre de tours. Réduisez l’un des deux et la facture chute immédiatement. C’est tout l’enjeu de la réduction de contexte : garder l’information qui améliore la réponse, retirer ce qui est dupliqué, obsolète ou hors sujet — sans rendre l’agent plus bête.
Couche 1 : Compression automatique — déjà active
Hermes embarque un système de compression double qui fonctionne seul, sans configuration :
- ContextCompressor de l’agent — le système principal, dans la boucle d’outils de l’agent, avec des comptages de tokens réels rapportés par l’API. Il se déclenche quand la session franchit 50 % de la fenêtre de contexte du modèle (configurable).
- Hygiène de session du gateway — un filet de sécurité à 85 % du contexte, qui tourne avant chaque tour. Il attrape les sessions devenues trop grosses entre deux tours (par exemple une accumulation nocturne sur Telegram ou Discord) pour que l’API ne plante jamais sur une requête surdimensionnée.
Quand la compression se déclenche, elle travaille en quatre phases :
- Élaguer les anciennes sorties d’outils — les plus vieilles sont retirées d’abord. Cette étape ne coûte rien : aucun appel LLM.
- Aligner les frontières — le compresseur remonte pour ne jamais couper une paire « appel d’outil → résultat ».
- Générer un résumé structuré — le milieu de la conversation est envoyé à un modèle auxiliaire, qui écrit un résumé structuré (objectifs, décisions, progression, prochaines étapes). Le budget du résumé évolue avec le contenu (≈20 %), plancher de 2 000 tokens, plafond de 5 % de la fenêtre de contexte.
- Assembler — la session compressée devient : tête (prompt système + contexte initial) + résumé + file récente verbatim.
La documentation officielle montre un exemple concret : une session de 45 messages (~95K tokens) se compresse en 25 messages (~45K tokens) — une réduction d’environ 53 %, le résumé et la file récente préservant la continuité.
Couche 2 : Mettez à jour, la refonte v0.20 s’active
La v0.20.0 (3 août) a profondément refondu la compression — « Compression that respects your conversation ». Les changements majeurs, tous fusionnés en amont et vérifiables dans les notes de version :
- Micro-compaction par tour — au lieu d’une grosse pause qui bloque, le coût est amorti en petits incréments sur les tours.
- Garantie de file de N messages utilisateur —
compression.min_tail_user_messages(défaut 1) garantit que les vrais messages récents survivent toujours à la compaction. Vous ne perdez jamais le fil de ce que vous avez demandé. - Élagage proactif des sorties d’outils — les modèles à grande fenêtre élaguent les résultats obsolètes avant même le seuil.
- Défense ghost-skill — une skill supprimée en pleine session ne peut plus hanter silencieusement le contexte (les marqueurs
[SKILL_PRUNED]rendent l’élagage déterministe). - Seuils par modèle et seuils absolus en tokens — déclenchez la compression à des pourcentages différents selon le modèle, ou à un nombre fixe de tokens (
compression.threshold_tokens) — crucial quand vos modèles ont des fenêtres très différentes.
La pièce la plus récente est arrivée le 26 août : le mode lean tail (PR #87326). L’ancienne formule gardait une file verbatim proportionnelle à la fenêtre — sur un modèle à 1M de contexte, cela signifiait 170K tokens d’historique brut après chaque compression, rendant /compress presque inutile et renvoyant ces tokens à chaque tour. Le mode lean bride la file à 2,5 % de la fenêtre (10K–25K tokens) et déplace la continuité vers un résumé amélioré avec pointeurs de récupération. Un seul réglage, des dizaines de milliers de tokens économisés par tour. Si hermes config get compression.tail_mode affiche encore legacy, lancez hermes update — la nouvelle valeur par défaut est lean.
Couche 3 : Les boutons que vous pouvez tourner
Les valeurs par défaut sont saines, mais un peu de réglage paie vite. Regardez d’abord ce que vous avez :
hermes config get compression.enabled # true
hermes config get compression.threshold # 0.50 (déclenche à 50 % du contexte)
hermes config get compression.target_ratio # 0.20
hermes config get compression.tail_mode # lean sur les versions récentes
hermes config get compression.protect_last_n # 20 (messages de file minimum protégés)
hermes config get compression.min_tail_user_messages # 1
Trois réglages qui comptent vraiment :
1. Déclenchez plus tôt sur les grandes fenêtres. Avec un modèle 200K+, attendre 50 % signifie que chaque tour envoie déjà ~100K tokens. Mettez compression.threshold à 0,4, ou mieux, un seuil absolu fixe :
compression:
enabled: true
threshold_tokens: 80000 # compresser dès que la session dépasse 80K tokens
2. Des seuils par modèle. Fenêtres différentes, prix différents :
compression:
model_thresholds:
"claude-sonnet": 0.35
"glm-5.2": 0.40
3. Rendez le résumé moins cher. Le résumeur est aussi un appel LLM — par défaut un modèle auto-détecté, mais vous pouvez le pointer vers un modèle bon marché et rapide :
auxiliary:
compression:
model: <un modèle bon marché et rapide>
Les résumés de compression ne sont pas l’endroit pour votre modèle le plus cher.
Couche 4 : Hygiène quotidienne
Les quatre commandes slash qui vous disent ce qui se passe et vous laissent agir :
| Commande | Rôle |
|---|---|
/context |
Décompose exactement ce qui remplit votre fenêtre — skills, outils, mémoire, historique, fichiers |
/usage |
Affiche l’utilisation et le coût en tokens de la session (hermes insights couvre les 30 derniers jours) |
/compress |
Déclenche une compression manuelle en pleine session |
/focus |
Vue de sortie réduite qui masque les lignes d’outils bruyantes tout en les gardant récupérables |
Au-delà des commandes, quelques habitudes réduisent le coût fixe qui voyage à chaque tour :
- Désactivez les skills inutilisées. Chaque skill activée injecte son en-tête dans le contexte de chaque tour.
hermes skills list, puishermes skills disable <nom>pour celles que vous ne touchez jamais. - Passez
tool_searchenauto. Les outils se chargent seulement si nécessaire, au lieu d’envoyer tous les schémas à chaque tour. - Gardez la mémoire et AGENTS.md légers. Chaque caractère de mémoire injectée et d’instructions projet est renvoyé à chaque message. Stockez des faits durables, pas la progression d’une tâche.
- Ne changez pas de modèle en pleine session. La plupart des fournisseurs mettent en cache le préfixe du prompt — un prompt système stable fait toucher le cache aux tours suivants, pour une fraction du coût. Changer de modèle l’invalide.
- Déléguez ou regroupez. Les longues recherches via
delegate_taskou les opérations de fichiers dans un scriptexecute_codegardent les sorties volumineuses hors de la conversation principale.
Tout assembler
Rien de tout cela ne sacrifie les capacités. L’exemple officiel montre déjà ~95K → ~45K sur une longue session typique, et sur les modèles à grande fenêtre, le lean tail retire bien plus de cent mille tokens par tour qui étaient du pur gaspillage. La compression automatique gère l’historique ; la refonte v0.20 la rend plus douce et moins chère ; quelques lignes de config l’adaptent à vos modèles ; l’hygiène quotidienne empêche la pile de grossir.
Deux avertissements. D’abord, ne réglez pas le seuil si agressivement que l’agent compresse en permanence — chaque résumé est un petit appel LLM, et comprimer sans cesse une session courte gaspille de l’argent en résumés au lieu de réponses. Ensuite, la réduction de contexte vise le contenu dupliqué, obsolète ou hors sujet — si la session est vraiment énorme et en a besoin, préférez les max_turns illimités avec l’export de session à une compression forcée.
Pour l’histoire derrière le nouveau défaut lean tail et des chiffres réels sur les grandes fenêtres, voir Hermes Compaction Gets a Lean Default. Si votre facture a bondi parce qu’une fenêtre de contexte était réglée plus grande que ce que votre fournisseur annonce, lisez Why Your Subscription Drained in Hours. Et pour le détail champ par champ du budget de contexte, le guide de configuration des longues tâches est la lecture approfondie à mettre en favori.