Samedi matin, vous lancez hermes update et le numéro de version passe de la v0.21.3 à la v0.21.4. Vous ouvrez les notes de version pour savoir ce qui a réellement changé, et la page tient en quelques paragraphes, avec une dernière ligne qui annonce que le récapitulatif complet arrivera avec la v0.22.0. Ce n’est pas de la paresse : les tags correctifs du cycle v0.21 existent pour donner aux images Docker, à Hermes Cloud et aux déploiements hébergés un point d’ancrage stable, et la documentation soignée arrive avec la version mineure suivante. Le hic, c’est que les comportements déjà livrés sur votre machine n’attendront pas la v0.22.0.

Cet article en extrait dix éléments, fusionnés sur main et bien présents dans ce tag, chacun accompagné d’une commande à lancer ou d’un bloc de configuration à coller. Aucun n’est un simple remaniement interne : trois changent votre topologie gateway, deux changent votre format de sortie ou votre facture, et les autres vous rendent du temps immédiatement.

D’abord, la comptabilité : pourquoi ce tag existe

Le corps de la release est d’une franchise inhabituelle sur ce point. Il s’agit d’un tag correctif qui regroupe tout ce qui a été fusionné depuis la v0.21.3 dans une release stable destinée aux consommateurs en aval (images Docker, Hermes Cloud, déploiements hébergés), les notes complètes étant renvoyées à la v0.22.0. Mesuré au commit 4b8a8134009a8727a289bcabeb0019fedd353128 :

Métrique	Valeur (depuis la v0.21.3)
Commits non fusionnés	5 071
Fichiers modifiés	5 169 (+312 961 / −62 855)
PR fusionnées	1 812
Issues fermées	2 116

Les utilisateurs de Docker peuvent tirer le tag directement avec nousresearch/hermes-agent:v2026.9.21 ; les installations git passent toujours par hermes update. Tout ce qui suit est classé selon l’ampleur du changement pour votre quotidien.

Dix choses déjà livrées

1. Un seul processus gateway par hôte, et non un par profile

C’est la plus grande convergence architecturale de la fenêtre : exactement un processus hermes gateway run par hôte et par utilisateur OS, qui sert tous les profiles. Les verbes de cycle de vie ont changé de sens avec elle. hermes -p X gateway run ne démarre plus un second processus tant que le gateway de l’hôte est actif : il s’y rattache, affiche le PID du gateway hôte et l’ensemble des profiles servis, puis sort avec le code 0. hermes gateway start --all et restart --all désignent désormais l’unique multiplexeur de l’hôte, et ils ne balayent plus jamais un gateway lancé par un autre profile.

L’ancien interrupteur gateway.multiplex_profiles: false est retiré : il est toujours analysé, mais il ne peut plus épingler un second processus gateway — il se résout exactement comme une clé non définie, journalise un avertissement et renvoie vers la commande de migration. Si vous montez en version depuis une topologie par profile, regardez le plan avant de toucher à quoi que ce soit :

hermes gateway migrate --multiplex --dry-run   # affiche le plan, les blocages et les redémarrages qu'il implique
hermes gateway migrate --multiplex             # converge pour de bon (ajoutez --yes dans un shell non interactif)

Le chemin de migration pas à pas, les trois incidents réels qui l’ont motivée (dont un P1 capable de supprimer le MEMORY.md du mauvais profile) et une checklist d’après mise à niveau sont dans un article dédié : Un seul gateway par hôte : la migration multiplex-only. Le précédent guide du multiplex activé par défaut raconte comment la capacité est apparue.

2. Connecteurs : brancher une application depuis la conversation

Brancher une application signifiait jusqu’ici modifier la configuration, ouvrir un navigateur et coller des clés. Désormais, l’utilisateur demande dans le chat de connecter Notion et le backend exécute toute la connexion : il collecte les valeurs, affiche le lien de connexion, et l’agent peut appeler le nouvel outil dans le même tour. Les trois clients interactifs dessinent la même étape de configuration — une boîte de dialogue dans l’application desktop, un encart dans hermes --tui, un panneau dans la CLI classique. Le dépôt embarque un catalogue de 65 serveurs MCP audités, dont 55 déclarent auth.type: oauth.

3. --format stream-json pour des exécutions lisibles par une machine

Les exécutions one-shot peuvent désormais produire du JSONL :

hermes chat -q "Summarize this repository" --format stream-json

Chaque ligne de stdout est un objet JSON (system, text, tool_use, tool_result, result), les diagnostics et la ligne session_id: restent sur stderr, et l’enregistrement result terminal porte exit_code, les statistiques de tokens et la durée. Cela exige -q (ou --query-file), implique le mode quiet et refuse --tui. Le tableau complet des champs d’événements, la sémantique des codes de sortie (0 / 1 / 130, plus 75 pour un worker Kanban) et la façon de le consommer dans un pipeline : Apprendre à la CI à lire Hermes : le flux d’événements stream-json.

4. skills.auto_load épingle des skills dans chaque nouvelle session

Trois lignes dans config.yaml suffisent pour que ces skills soient entièrement chargés au début de chaque nouvelle session, et pas seulement listés dans le catalogue :

skills:
  auto_load:
    - release-notes
    - qa-multilingual

Le réglage s’applique à la CLI, à la TUI, au gateway, au cron et aux agents API, et il est limité au profile. L’injection n’est résolue qu’une fois par agent — changements de modèle, compression et restauration du préfixe statique réutilisent les mêmes octets rendus —, donc votre cache de prompt reste intact. Quand l’éviter et comment il déduplique face à --skills : Épingler des skills dans chaque session.

5. mcp.discovery_concurrency met fin à la tempête de processus au démarrage

La découverte MCP partait auparavant dans un asyncio.gather sans borne : huit serveurs stdio signifiaient huit arbres de processus lancés au même instant, et dans une flotte multi-profile chaque profile servi lançait sa propre passe. Les connexions sont désormais bornées par mcp.discovery_concurrency, par défaut 4, avec 0 pour illimité :

hermes config set mcp.discovery_concurrency 2   # machines plus lentes, mémoire plus tendue

Les mesures de la PR (8 serveurs stdio) : la concurrence de pointe passe de 8 à 4 avec la valeur par défaut, la passe passant de 4,0 s à 5,6 s ; la valeur 2 donne une pointe à 2 et 13,2 s ; 0 restaure une pointe à 8 et 3,5 s. Vous échangez un démarrage légèrement plus lent contre l’absence de tempête de processus.

6. hermes sessions set-journal-mode convertit le stockage hors ligne

Si vous configurez database.journal_mode: delete alors que state.db est déjà en mode WAL, Hermes ne le rétrogradera jamais en direct : le gateway, le dashboard ou le cron peuvent détenir des commits non checkpointés, et une rétrogradation sous leurs pieds les détruit. La seule issue consistait jusqu’ici à lancer une PRAGMA à la main. Il existe désormais une commande :

hermes sessions set-journal-mode delete                          # WAL -> journal rollback
hermes sessions set-journal-mode wal                             # retour au WAL
hermes sessions set-journal-mode delete --db ~/.hermes/kanban.db # un autre stockage Hermes

Elle commence par chercher les détenteurs du fichier, refuse tant qu’un processus (ou ses fichiers annexes -wal/-shm) l’a encore ouvert, nomme chacun sous la forme pid — command: path, puis relit les octets d’en-tête pour vérifier le nouveau mode. Elle refuse aussi purement et simplement sous Windows, où le recensement des détenteurs est indisponible, et refuse d’activer le WAL sur un système de fichiers inter-VM (virtiofs/9p). Pour le contexte : doctor et les écrivains WAL à chaud et le WAL de state.db dans Docker.

7. Les messages privés non autorisés peuvent être refusés poliment

Le gateway n’avait que deux réponses face à un message privé non autorisé : pair (faire passer l’expéditeur par l’appairage) ou ignore (l’ignorer). Il en existe une troisième, avec un texte personnalisé :

gateway:
  unauthorized_dm_behavior: decline
  unauthorized_dm_decline_message: "This bot is private. Ask the owner for an invite."

Vous pouvez aussi la surcharger plateforme par plateforme, dans le bloc extra de celle-ci. Pour un assistant personnel joignable sur un canal public, c’est plus professionnel que le silence : l’expéditeur apprend que le message est bien arrivé et pourquoi il n’a pas reçu de réponse.

8. session_search gagne une fenêtre temporelle et une nouvelle tentative assouplie

Le rappel inter-sessions accepte désormais des bornes after / before, qu’il s’agisse de dates ISO ou de durées relatives (7d, 24h, 2w) :

• after="7d" — uniquement les sessions démarrées dans la dernière semaine ;
• before="2026-09-01" — uniquement l’historique jusqu’au 1er septembre (une valeur de date seule signifie minuit UTC ce jour-là) ;
• la forme relative before="7d" signifie plus ancien qu’une semaine, et non la dernière semaine — facile à inverser.

Le rappel retente également une fois avec une correspondance OR assouplie quand la correspondance stricte ne trouve rien, si bien qu’un vague « je crois que j’avais mentionné le truc de déploiement » aboutit plus souvent. L’index lui-même a été reconstruit plus tôt comme un chemin rapide sans LLM (voir les frontières de session) ; ce changement complète la dimension temporelle.

9. Une pile de petits gains côté desktop

• Sélecteur de police chat/interface — choisissez séparément la police du transcript et celle de l’interface, y compris des polices de lisibilité comme OpenDyslexic.
• Réduction dans la zone de notification — sur option : réduire masque les fenêtres sans détruire les renderers ni arrêter le travail en cours ; Close, Alt+F4 et Cmd+Q gardent leur comportement, et la zone de notification propose Show Hermes / Quit Hermes.
• Pression rapide pour convoquer le HUD — appuyez et relâchez Cmd+Option sur macOS, Ctrl+Alt sous Windows/Linux X11, pour faire revenir le HUD au premier plan depuis une autre application (désactivé par défaut, mémorisé par appareil, les deux touches devant être relâchées en moins de 500 ms).
• Tiroir d’état par conversation — un liseré au-dessus de la zone de saisie replie d’un coup la pile d’état et la ligne git ; chaque conversation garde son choix.
• Désinstallation de plugin depuis le hub Plugins, plus la mise à jour du moteur local en un clic.

10. Mises à jour du catalogue : modèles vidéo et pages de plugins

La famille vidéo FAL a accueilli LTX 2.5 (le modèle audio-vidéo ouvert de Lightricks : audio natif, jusqu’à 20 s / 4K en image-vers-vidéo, préréglages de mouvement de caméra) et Kling O3 Standard (Kuaishou : narration native multi-plans, audio en option, 3–15 s). Le catalogue de plugins a gagné une douzaine de plugins communautaires (tailscale, ssh, shodan, terminal, rss, resetwatch, done-bell, kiwi, cognee et d’autres), et chaque plugin et auteur du catalogue dispose désormais de sa propre page, avec le README figé sur un commit audité.

Bon à savoir, sans action immédiate

La même fenêtre a aussi resserré une série de cas limites : hermes -p X update ne redémarre plus le gateway hôte qu’une fois pour toute la machine, la notification atteignant chaque profile servi (#118108) ; le desktop se rattache au backend hôte en cours d’exécution au lieu d’en lancer un par profile (#118246) ; les profiles nommés relisent le auth.json du profile racine, ce qui corrige les échecs No Codex credentials stored après mise à jour (#118373) ; une notification post-mise à jour adressée à une plateforme qui ne se connecte jamais cesse de réessayer au lieu de journaliser toutes les 2 secondes à l’infini (#118312) ; un 429 de gateway managé sur image_generate ou sur une vidéo FAL est signalé comme une limite de débit et retenté une fois, au lieu de vous inviter à changer de modèle ou à définir FAL_KEY (#118311) ; et l’appel de titre automatique n’entre plus en course avec la réponse sur un serveur de modèle auto-hébergé à emplacement unique (#117494).

Cinq minutes de vérification après la mise à niveau

hermes version                        # attendez-vous à v0.21.4 (tag v2026.9.21)
hermes doctor                         # d'abord les avertissements stockage / topologie gateway
hermes gateway status                 # qui sert quels profiles
hermes gateway migrate --multiplex --dry-run   # mise à niveau depuis une topologie par profile : lisez le plan

Si vous faites tourner plus d’un profile sur la machine, c’est le point 1 qui mérite votre temps : il constitue à la fois une frontière de sécurité (les profiles cessent de lire les credentials des autres) et une frontière de disponibilité (un seul redémarrage de gateway par mise à jour, au lieu d’un par profile).

En résumé

Un tag correctif sans notes soignées, c’est normal ; « pas de notes de version » ne veut pas dire « rien n’a changé ». Les parties de cette fenêtre qui méritent votre attention sont la convergence de la topologie gateway et les correctifs d’isolation des profiles — la première décide combien de processus tournent sur votre machine, les seconds décident si un profile peut lire les clés et la mémoire d’un autre. Le reste (sortie structurée, skills épinglés, concurrence MCP au démarrage, conversion du mode journal) relève de ces changements que l’on adopte dès qu’on sait qu’ils existent. Le récapitulatif soigné complet arrive avec la v0.22.0 et couvre tout depuis la v0.21.0 ; pour le tag lui-même, voyez notre page de release v0.21.4.