Hermes cesse de deviner la taille de votre contexte : l'ancrage sur l'usage aligne les seuils de compression sur les chiffres réels

Votre session atteint le tour 40 et tout va bien — puis, sans crier gare, un avis « contexte trop long, compression en cours » surgit, alors que vous êtes loin de la limite de la fenêtre. Ou bien, un jour, l’API renvoie une erreur 413 indiquant que la requête est trop volumineuse, alors que la conversation est clairement bien plus courte. Ces deux scénarios étaient monnaie courante dans Hermes, et ils partagent une même cause racine : Hermes devinait la taille de votre contexte — il réestimait tout le transcript, tour après tour, avec des heuristiques comme chars/4 et des images à 1 500 tokens fixes, laissant l’erreur se cumuler à mesure que l’historique grandissait. Le changement fusionné le 28 août (PR #97206) arrache cette racine : le comptage du contexte s’ancre désormais sur l’usage rapporté par le provider, et la fenêtre d’estimation passe de « toute la conversation » à « les messages ajoutés depuis la dernière réponse ».

Avant : l’estimation de tout le transcript, une erreur boule de neige

Chaque réponse de provider transporte en réalité un rapport d’usage précis : usage.prompt_tokens (exactement combien de tokens cette requête a envoyés, prompt système, schemas d’outils et historique complet compris) et usage.completion_tokens (combien ont été générés). Le fournisseur du modèle les compte lui-même — c’est la vraie vérité terrain.

Mais l’ancien Hermes s’en servait à peine. Chaque fois qu’il devait vérifier la taille du contexte, il réestimait la session entière avec des heuristiques : caractères ASCII divisés par 4, 1 500 tokens fixes par image, règles de densité CJK… L’estimation était correcte en début de session, mais à mesure que l’historique grandissait, l’erreur se cumulait. Certaines sessions étaient surestimées — compressées avant même d’atteindre le seuil ; d’autres sous-estimées — la requête dépassait la limite du provider et recevait un 413. Les issues #89938 et #88960 sont des exemples typiques de cette classe « estimation contre réalité ».

Nouveau mécanisme : ancrage sur l’usage, fenêtre d’erreur réduite à un tour

Le cœur du PR #97206 tient en une formule :

current context tokens =
  last response's usage.prompt_tokens
  + last response's usage.completion_tokens
  + estimate(ONLY messages appended since that response)

En d’autres termes : la taille réelle de toute la conversation vient directement des chiffres du provider ; seules les quelques messages ajoutés depuis la dernière réponse doivent être estimés. La fenêtre d’erreur passe de « tout le transcript » à « un seul tour » — et elle se corrige d’elle-même à chaque réponse, car la valeur réelle est le point de départ, jamais quelque chose que l’estimation doit rattraper.

L’ancre est capturée à un seul endroit : le bloc d’usage juste après context_compressor.update_from_response() dans la boucle principale de conversation (capture_usage_anchor), mis à jour à chaque réponse. Les seuils de compression et la logique de récupération 413 basculent tous sur ce nombre ancré.

Correctifs associés : la récupération 413 compte des octets

La même vague embarque des correctifs compagnons (#97197 et autres) : la récupération 413 mesurait auparavant la taille de la requête en tokens estimés — elle mesure désormais des octets réels, car le jugement 413 du provider repose sur la taille du payload HTTP, et aucune estimation de tokens ne se convertit correctement en octets. Le compressor libère en outre réellement les octets occupés par les images historiques lors de la compaction (#97160), si bien que la récupération 413 ne « passe pas de justesse » mais « libère vraiment de l’espace ».

Ce que cela change pour vous

  • Moins de compressions surprises : les vérifications de seuil s’alignent sur les chiffres réels, les sessions cessent d’être « virtuellement gonflées » et compressées trop tôt ;
  • Moins de 413 : les vérifications de taille de requête passent des estimations aux comptages d’octets, les longues sessions cessent de mourir au hasard avec « payload too large » ;
  • Un /context honnête : les chiffres que vous voyez correspondent à ceux de votre facture provider — ce que vous voyez est réel.

Le mainteneur Teknium l’a dit sans détour : « J’en ai vraiment marre qu’on estime des tokens. Arrêtez d’estimer. » Cette vague, c’est cette phrase transformée en code.

Ces changements ont été fusionnés le 28 août et vivent actuellement sur main en amont, pas encore dans un tag de release. Ils prennent effet automatiquement dès que vous faites hermes update vers un build qui les contient.

Pour aller plus loin