Vous faites tourner plusieurs workflows Hermes en parallèle sur votre machine, et un jour vous décidez de faire le ménage : ls .worktrees/ affiche deux douzaines d’arbres, et la liste des branches défile sur trois écrans — mais vous n’osez rien supprimer, car vous ne savez pas quel arbre contient encore du travail non poussé. Pendant ce temps, vous montez une discussion de groupe en Bot Mode avec trois bots qui suivent un projet, et quand vous essayez de partager un PDF de conception, vous constatez que le salon ne peut tout simplement pas accepter de fichiers. Ce sont ces corvées que personne n’a explicitement demandées mais que tout le monde a rencontrées — et c’est exactement de cela qu’il s’agit dans v0.20.5 (tag v2026.8.19, sortie le 19 août 2026).

La fenêtre a fusionné environ 323 PR et ~746 commits sur ~1 250 fichiers depuis v0.20.4. Pas de fonctionnalité phare unique : l’histoire, c’est que les discussions de groupe en Bot Mode acceptent enfin les fichiers, que les worktrees ont enfin une commande de grand ménage sûre, que les mises à jour produisent enfin des reçus que vous pouvez auditer, et que les tâches cron ont enfin de la mémoire. Passons-les en revue.

Les discussions de groupe acceptent les fichiers — et les anciens messages se replient automatiquement

Les discussions de groupe en Bot Mode étaient uniquement textuelles : pour montrer un PDF aux bots d’un salon, il fallait déposer le fichier quelque part et référencer le chemin dans votre prompt. Désormais les fichiers sont des citoyens de première classe — les salons acceptent les PDF, les fichiers arbitraires et le glisser-déposer, et chaque bot répondant au tour voit les pièces jointes (PR #97b41f8cf, #b359db72e). Le scénario de suivi de projet multi-bots fonctionne enfin sans détours.

Les longs salons ont aussi leur réponse : les conversations plus anciennes se replient automatiquement en résumés d’une ligne (« ▸ API design … 14 réponses · il y a 2 h ») tandis que la conversation la plus récente reste entièrement ouverte (#8505559fa) — les salons cessent de grossir sans limite, et l’historique reste parcourable d’un coup d’œil. Les avatars changent aussi de look : ils utilisent par défaut des visages blob déterministes dessinés à partir du nom de l’agent (même nom, même visage, à chaque fois), avec quatre nouvelles silhouettes issues de blobatar 2.0.0 (#a77ee88ce, #cb0fd836a). Pour une visite systématique des fonctionnalités de discussion de groupe, consultez notre guide des discussions de groupe en Bot Mode.

hermes worktree list/prune : un grand ménage sûr pour les worktrees

Retour à la scène d’ouverture. Les workflows multi-agents (hermes -w ou /worktree new) accumulent des dizaines d’arbres et des centaines de branches fusionnées sous .worktrees/. Le nettoyeur silencieux au démarrage ne touche que les arbres propres et entièrement fusionnés ; tout le reste traîne indéfiniment — prudent par conception, mais cela vous laisse auditer à la main.

v0.20.5 ajoute une commande de récupération explicite, en mode dry-run d’abord (#f309f92d3) :

hermes worktree list              # audit : une ligne par arbre — âge, taille, verdict, raison
hermes worktree prune --dry-run   # affiche le plan, ne change rien
hermes worktree prune             # récupère les arbres sûrs + branches fusionnées

list affiche un tableau : nom de l’arbre, âge, taille, verdict (récolter/conserver) et raison, avec un pied de tableau résumant « N arbres, X au total, Y récupérables dès maintenant ». Les invariants de sécurité sont identiques à ceux du nettoyeur de démarrage : les modifications suivies ne sont jamais supprimées, quel que soit leur âge, les commits uniques non poussés ne sont jamais supprimés (git cherry décide de ce qui est « unique » ; les dépôts peu profonds sont d’abord approfondis sans blobs), les arbres verrouillés en direct sont laissés intacts, une branche n’est supprimée qu’après la suppression réussie de son worktree, et les brouillons sans fichiers suivis sont archivés dans ~/.hermes/archive/worktree-prune/ avant que l’arbre ne soit récolté — les déchets disparaissent, le travail vivant reste.

Les mises à jour livrent désormais des reçus : hermes update --plan

« Ce qui s’est réellement passé pendant la mise à jour » était une boîte noire : on affiche ✓ Code updated! et on considère que c’est fait — le helper meurt après l’affichage, le redémarrage est silencieusement ignoré, le desktop affiche un échec pour une mise à jour réussie — les classes d’échec silencieux (#88848, #74973, #85753, #81193) relevaient toutes de la devinette a posteriori. v0.20.5 fait prouver son résultat au programme de mise à jour (#0aecadc17, #1d74833d8) :

• hermes update --plan : lecture seule. Liste ce que la mise à jour touchera — type d’installation (git/docker/nix), chaque service Hermes en cours d’exécution sur tous les profils avec son superviseur et la version de code en cours, et la manière dont chacun sera redémarré. Sans risque à exécuter sur une flotte en production.
• Reçus structurés : chaque hermes update écrit un enregistrement JSON lisible par machine — ce qui a été découvert, fait, ignoré (et pourquoi) — dans <HERMES_HOME>/logs/update_receipts/. Après la phase de redémarrage, il lit le gateway_state.json de chaque profil, compare le code_sha de chaque gateway actif avec le HEAD du checkout fraîchement mis à jour, et affiche une matrice des versions de la flotte — les flottes à versions mixtes deviennent un rapport clair et actionnable au lieu d’un état latent.

Exécutez hermes update --plan avant de mettre à jour pour voir ce qui va changer, puis consultez le reçu après — qui est sur quelle version se voit d’un coup d’œil. Cela prolonge la trajectoire ouverte par le hermes update honnête de v0.20.4 : la mise à jour passe de « faites-moi confiance » à « vérifiable ».

Les tâches cron ont de la mémoire — et un effort de raisonnement par tâche

Les tâches cron étaient traitées différemment : skip_memory=True, MEMORY.md/USER.md jamais chargés, et l’outil de mémoire durement retiré — même si vous le nommiez dans les enabled_toolsets d’une tâche. Les utilisateurs recouraient à des contournements bricolés. Les agents cron tournent désormais avec la mémoire persistante activée comme tout autre agent (#ef04d846e) : les tâches peuvent lire — et mettre à jour — votre mémoire persistante.

Chaque tâche peut aussi épingler son propre effort de raisonnement, indépendamment de agent.reasoning_effort global et des reasoning_overrides par modèle (#4e1dd1a74) :

# analyse planifiée lourde en high, tâche récurrente bon marché en minimal — la valeur globale reste inchangée
hermes cron create "0 7 * * *" --reasoning-effort high --prompt "Deep weekly repo-trend analysis"
hermes cron create "every 5m"  --reasoning-effort minimal --prompt "Health check and report"

Niveaux : none/minimal/low/medium/high/xhigh/max/ultra ; les niveaux non pris en charge par un modèle sont plafonnés par le provider au moment de la requête (épingler xhigh sur un modèle plafonné à high s’exécute à high). Passez une chaîne vide à la modification pour effacer l’épinglage. Pour d’autres motifs cron, consultez notre guide complet d’automatisation cron.

opencode-free : un modèle gratuit véritablement sans clé

opencode-free est désormais entièrement sans clé — aucune variable d’environnement, aucun compte, une liaison anonyme (#ca06b8768) — et la synchronisation anti-dérive du catalogue récupère les modèles gratuits OpenRouter en direct dans la liste tout en retirant les slugs gratuits morts (#624723130). Les providers sans clé comptent comme authentifiés partout : opencode-free apparaît directement dans /model et les sélecteurs du desktop sans aucune configuration (#2a2307e68) :

hermes model    # sélectionnez opencode-free — aucune clé requise

Si vous n’avez pas encore configuré de modèle gratuit, voilà une option fonctionnelle dès la sortie de la boîte. Combiné à nos cinq canaux de recherche gratuits, une installation Hermes fraîche peut fonctionner entièrement sans clé.

Autres améliorations « personne ne le fait, mais tout le monde en a besoin »

• Discipline d’exécution et garde-fous contre les blocages (issus des résultats de l’évaluation Composio) : annulation de la review en arrière-plan synchronisée avec la bonne priorité au premier plan (#37da0d4d5, #b883756b7), effort de raisonnement Ox Alpha fiablement plafonné sur les providers zen et free (#d4d04098a), décoration cache-control du prompt-caching idempotente (#0fc52b055) — les tâches de longue durée bloquent moins et consomment des tokens de manière plus prévisible.
• Performance du desktop : hydration Bot Mode en paint-first, spinners du compositeur, React Compiler dans les deux renderers.
• La modification de messages dans les anciennes sessions ne plante plus (#02e270a47) ; les brouillons Telegram DM conservent leur mise en forme riche après le streaming (#790c85014) ; le bootstrap API_SERVER_KEY du stage2 Docker ne dépend plus de l’existence de .env (#7a17a1b8a).

Pour la décomposition complète point par point (y compris les listes des améliorations et des corrections), consultez nos notes de release v0.20.5. La mise à jour est simple :

hermes update

Après la mise à jour, lancez hermes doctor pour vérifier l’installation et redémarrez la gateway (hermes gateway) afin que les changements de plateforme prennent effet. Pour voir ce que la prochaine mise à jour touchera avant de l’exécuter, commencez par hermes update --plan. Cette release n’a pas de titre clinquant — mais elle vide une pile de corvées que tout le monde a rencontrées, et un bon grand ménage fait toujours du bien une fois terminé.