Vous passez une demi-heure à réécrire SOUL.md. Vous ajoutez deux nouvelles règles à un skill. Vous redémarrez le gateway, revenez sur la session ouverte depuis la veille et lui demandez de refaire la tâche qu’elle vient d’exécuter. Elle répond avec l’ancienne voix, suit les anciennes étapes et continue d’éviter précisément ce que vous venez de lui interdire. Vous ouvrez trois fois le fichier de configuration pour vérifier que la modification est bien prise en compte. Puis vous faites la seule chose qui reste : /new — et vous regardez quarante tours de contexte disparaître.

La configuration était correcte. Hermes l’ignorait volontairement, pour vous faire économiser de l’argent. Une commande permet désormais de rafraîchir les instructions sans toucher à la conversation.

Pourquoi une session active ne voit pas votre modification

Les providers de modèles ont une astuce pour réduire les coûts : quand le début de chaque requête est identique octet pour octet, le provider peut réutiliser son calcul en cache au lieu de le refaire. Ce préfixe, c’est le system prompt — le bloc qui porte la persona de votre SOUL.md, l’index des skills, les règles projet d’AGENTS.md, la mémoire et USER.md.

Pour garder ce préfixe stable, Hermes construit le system prompt d’une session une seule fois, puis le stocke et rejoue exactement ces octets à chaque tour suivant. Après un redémarrage du gateway, il restaure la copie enregistrée depuis la ligne de session ; un agent maintenu à chaud en mémoire ne relit jamais les fichiers.

Seule une session toute neuve lit donc les fichiers. Les conversations existantes continuent de rejouer le prompt avec lequel elles sont nées — exactement ce que vous observiez.

La commande : hermes sessions refresh-prompts

# toutes les sessions de ce profile
hermes sessions refresh-prompts

# une seule session (id ou préfixe unique)
hermes sessions refresh-prompts --session a1b2c3

# un autre profile
hermes sessions refresh-prompts -p work

# sortie exploitable par une machine, pratique dans un script de mise à jour
hermes sessions refresh-prompts --json

Ce qu’elle fait est volontairement minimal : elle enregistre une demande de rafraîchissement dans le state.db du profile et indique combien de sessions détiennent un prompt stocké. Le travail réel a lieu au début du tour suivant de chaque session.

La sortie ressemble à ceci :

Requested a system prompt refresh for every session in this profile (12 session(s) with a stored prompt).
Each rebuilds its prompt from the current SOUL.md, skills and context files on its next turn (one prompt-cache miss per session); conversation history is kept.

Avec --session, un cas limite est géré pour vous : une conversation compactée se poursuit sur son tip, la demande est donc rattachée à cette continuation plutôt qu’à la racine depuis longtemps terminée dont elle a été compressée.

Ce qui est réellement reconstruit

• Reconstruit : l’intégralité du system prompt repasse par le builder habituel, si bien que le nouveau SOUL.md, les skills ajoutés ou retirés, AGENTS.md et les fichiers de contexte prennent tous effet à ce tour. Les blocs mémoire et USER.md sont également relus depuis le disque.
• Intact : l’historique de la conversation, l’id de session et la liste d’outils épinglée de la session. Le hook on_session_start ne se déclenche pas, donc aucun de ses effets de bord ne se rejoue.
• Coût : un cache miss de préfixe par session rafraîchie, sur le tour qui reconstruit. Les tours suivants sont de nouveau en cache.
• Persistance : le nouveau prompt et son empreinte de version sont réécrits dans state.db, et chaque tour ultérieur les rejoue mot pour mot. Il s’agit d’une reconstruction unique, pas d’une dépense à chaque tour.

Aucun redémarrage du gateway n’est nécessaire, et un redémarrage ne l’annule pas : la demande vit dans la base, donc un agent qui revient après un redémarrage la lit quand même. Un script de mise à jour peut appeler la commande avant ou après avoir remplacé le gateway.

Comment il sait qu’un rafraîchissement est dû

Hermes tient un epoch incrémental dans le state_meta du profile — voyez-le comme un numéro de révision de vos instructions. Chaque session consigne, dans son model_config, la révision à laquelle son prompt stocké satisfait déjà. Au début d’un tour, l’agent fait une seule lecture ponctuelle : si l’epoch stocké est plus ancien, il reconstruit une fois ; sinon, il ne fait rien.

Sans demande enregistrée, le seul travail ajouté est cette lecture unique. Rien ne surveille les fichiers en arrière-plan, et rien ne remplace les instructions au milieu d’un tour.

Quand l’utiliser — et quand s’en passer

Ce que vous venez de modifier	Lancer refresh-prompts ?
SOUL.md, skills, AGENTS.md, USER.md	Oui — c’est le cas pour lequel elle a été conçue
Uniquement le modèle ou les réglages d’échantillonnage	Inutile
Les définitions ou permissions d’outils	Les nouvelles sessions en tiennent compte ; l’épinglage d’outils d’une session existante reste tel quel
Vous voulez repartir de zéro sur un nouveau sujet	Utilisez /new ; cette commande ne vide pas l’historique
La ligne de session elle-même est abîmée	Utilisez hermes sessions repair-prompts, une autre commande

Deux réserves. D’abord, un rafraîchissement ne rejoue pas l’historique et ne répare pas une conversation cassée — il ne remplace que le préfixe d’instructions. Ensuite, si vous enchaînez beaucoup de longues sessions et payez au token, préférez --session : chaque session rafraîchie paie son propre cache miss, et sur des dizaines de conversations, cela finit par compter.

Si votre question est plutôt « pourquoi les instructions deviennent-elles obsolètes après une compaction », c’est un mécanisme distinct — Hermes reconstruit le system prompt pendant la compaction. Les détails sont dans comment la compaction reconstruit le prompt. Si vous venez de déplacer des skills dans le dépôt, lisez d’abord les skills locaux au projet et la barrière de confiance — le rafraîchissement n’est que la façon dont une session active les rattrape. Et la mécanique du partage d’un cache de préfixe entre sessions est traitée dans le partage de prompt cache entre profiles. La référence complète des options figure sur la page de la commande hermes sessions.

Statut de la release

La commande a été mergée dans main le 29 octobre 2026 (PR #143581). La release courante, v0.22.5 (23 octobre 2026), ne l’inclut pas encore — si hermes sessions --help n’affiche pas refresh-prompts, vous êtes sur un build plus ancien. Installez depuis main pour l’utiliser tout de suite, ou attendez la prochaine release.

Modifiez les fichiers, lancez une commande, et le tour suivant s’exécute sur les nouvelles instructions — sans sacrifier une conversation pour y arriver.