Vous avez installé Hermes comme service systemd il y a des mois, et il a redémarré proprement à chaque reboot depuis — jusqu’au matin où le service est mort, où systemctl start répond qu’il est déjà actif quelque part, et où le seul indice dans le log est un PID qui appartient à tout autre chose. Ou alors vous êtes sur un laptop, avec un modèle local, et un long tour s’arrête net : la ligne de statut reste figée, vous fermez le capot un moment, et au retour le tour a abandonné. Ces deux problèmes ont un correctif dans la v0.22.2, et un troisième, plus inhabituel, aussi : la release précédente a été compilée depuis le mauvais commit.

Ce qui est réellement arrivé à la v0.22.1

La v0.22.1 a été publiée le 14 octobre 2026 et pointait vers le mauvais arbre. Deux conséquences étaient visibles de l’extérieur : le tag embarquait du travail sur le gateway qui n’avait pas encore été publié, et le paquet Microsoft Store pouvait rester bloqué sur « Connecting. » au lieu de terminer son premier lancement.

La v0.22.2 a été publiée le lendemain matin, compilée depuis le commit que le tag précédent était censé utiliser, avec la v0.22.1 publiée comme parent. Le corps officiel de la release est sans détour sur la relation : « 0.22.2 is the release 0.22.1 was meant to be. » Entre v0.22.1 et v0.22.2, la plage de comparaison compte 11 commits — une reconstruction, pas une livraison de fonctionnalités.

Une mise en garde honnête accompagne cette reconstruction : les sessions exécutées sous le gateway 0.22.1 ne peuvent pas être supprimées en 0.22.2. Elles restent lisibles et reprenables ; leur suppression, elle, échoue. Si cela vous concerne, archivez ou exportez la session au lieu de compter sur la suppression.

D’abord, déterminez quelle build vous utilisez

Les releases correctives sont le moment où « est-ce que je suis vraiment sur la version corrigée » cesse d’être une question rhétorique : vérifiez avant toute autre chose :

hermes version

L’application desktop l’affiche dans Settings ▸ About (c’est aussi là que se trouve le commutateur de canal de mise à jour, si vous avez suivi le guide du canal stable). Côté Docker, regardez le tag que vous avez tiré : nousresearch/hermes-agent:stable bascule vers le nouveau correctif au prochain pull.

Si vous êtes en 0.22.1, mettez à jour. Si vous êtes en 0.22.0, le même hermes update vous amène directement en 0.22.2 et vous récupérez les deux correctifs ci-dessous.

hermes update

Correctif 1 : un gateway supervisé redémarre à nouveau après un reboot

Avant de prendre la main, le gateway doit savoir si un autre gateway tourne déjà sur cette machine. Il se fiait au PID qu’il avait enregistré, et il y avait un trou dans ce raisonnement : après un reboot, Linux peut attribuer un PID très bas à un processus sans rapport. Si le PID recyclé correspondait par hasard à celui enregistré, le gateway en concluait qu’un gateway vivant occupait la machine et refusait de démarrer. Sous systemd, launchd ou Docker — où quelque chose attend pour redémarrer le service — cela donne un service qui ne monte jamais.

Le correctif consiste à cesser de faire confiance à un PID nu et à enregistrer quelque chose qu’un reboot ne peut pas falsifier :

• Hermes enregistre dans quel boot il a démarré, et compare cet enregistrement au boot courant.
• Quand l’enregistrement n’est pas comparable — ancien format, ou heure de boot illisible — il interroge le host lock. Le host lock est un fichier que seul un gateway vivant détient : le détenir prouve la vie d’une manière qu’un PID ne permet pas.
• La vérification d’activité ne crée plus le fichier de verrou comme effet de bord, et l’identité argv a été entièrement retirée du contrôle, car un PID recyclé peut correspondre en même temps à une heure de démarrage et à une ligne de commande.

Si votre gateway refuse de démarrer après les reboots, la mise à jour corrige le problème sans toucher à votre unit file. Vérifiez avec la commande qu’utilise votre superviseur :

systemctl status hermes-gateway

Correctif 2 : les longs tours de modèle local survivent sur un laptop

Faire tourner un modèle en local change les modes de défaillance, parce que le modèle devient l’élément le plus lent de la pièce et que la machine qui l’exécute peut se mettre en veille. Une seule pull request (#138560) en ferme quatre d’un coup :

Symptôme	Ce qui a changé
Un long prompt ressemble à un tour bloqué	Les requêtes locales passent toujours en streaming, et la ligne de statut affiche la progression de lecture du prompt pendant que le serveur ingère
Un tour qui a dormi compte comme du temps de réflexion	Les minuteurs d’inactivité sautent le temps passé en veille
Tous les messages échouent après un timeout, même une fois le serveur revenu	Un serveur local revenu en vie obtient une nouvelle tentative au lieu d’un disjoncteur qui reste ouvert
La compression tombe en timeout pendant que le modèle lit encore	La compression n’abandonne plus tant que le serveur ingère une longue conversation

Sur les machines Windows à mémoire unifiée, il y a une cinquième pièce : le lancement du modèle et le cache de prompt sont dimensionnés d’après la mémoire libre plutôt que la mémoire totale, pour qu’une machine déjà occupée ne se sur-engage pas.

Cela compte surtout là où les modèles locaux sont les plus attractifs — un laptop avec quelques Go de marge, un long tour d’agent, et un utilisateur qui ferme le capot. Si vous mettez cela en place pour la première fois, le guide des modèles locaux avec llama.cpp détaille le runtime que Hermes installe.

Quoi d’autre dans la branche 0.22 depuis la v0.22.0

Comme la 0.22.2 republie toute la branche 0.22, quelques changements plus modestes voyagent avec elle et méritent d’être connus :

• Sélecteur de modèle : une liste de modèles sélectionnés figure en haut du sélecteur, NVIDIA NIM gagne sa liste de modèles par défaut, et Nemotron 3.5 Super VL arrive avec ses paramètres par défaut.
• Routes Mistral : les identifiants composite d’outils sont ré-appariés avant que le provider ne les voie — Mistral limite les identifiants d’outils à neuf caractères.
• Profiles : un nouveau profile hérite du modèle de lancement custom nu avec son endpoint, y compris les providers référencés par variables d’environnement.
• Terminal et recherche : vos propres outils passent avant ceux de Hermes dans le PATH, et la recherche locale de fichiers utilise le ripgrep épinglé par Hermes plutôt que le premier rg de la machine.
• Catalogue : les packs de langue du bureau coréen et portugais brésilien arrivent, plus de nouvelles entrées de catalogue (author-feed, wait-ledger, openinvest, TeamoRouter, Hermes AAC, Agent Mixer).
• Dépendances : httpx2/httpcore2 en 2.12.0 et les paquets npm épinglés mis à jour pour purger les alertes d’audit.

Les notes complètes et sélectionnées de la branche 0.22 se trouvent sur la page de release v0.22.0 Threshold et dans les notes de release v0.22.2.

À retenir

Une release corrective qui remplace une autre release corrective mérite une minute de votre attention : vérifiez hermes version, lancez hermes update, et si vous étiez en 0.22.1, traitez les sessions non supprimables comme le seul point en suspens et archivez plutôt que de supprimer. Si vous préparez une installation neuve, le guide d’installation contient les one-liners actuels.

---

Sources : le corps de release de la v0.22.2 et la plage de comparaison v0.22.1...v0.22.2 sur le dépôt Hermes Agent ; le travail sur l’identité de boot du gateway est la PR #138594 (corrigeant l’issue #133744) et le travail sur le modèle local est la PR #138560.