Pourquoi la mémoire Honcho d'Hermes atterrit ailleurs

Vous avez trois dépôts : un monorepo backend, un frontend et un dossier de scripts d’exploitation que vous n’avez pas ouvert depuis deux ans. La semaine dernière, vous avez réécrit le flux de remboursement dans le monorepo. Aujourd’hui, vous lancez Hermes dans le dossier de scripts, vous demandez où en est ce refactoring, et la réponse est précise, détaillée, et parle d’un projet qui n’a jamais été abordé dans ce répertoire. L’inverse est plus troublant encore : un dépôt fraîchement cloné, pas une ligne de code écrite, et la première conversation « se souvient » déjà de tout votre répertoire personnel. Vous faites tourner Hermes projet par projet précisément pour que chaque dépôt ait sa propre mémoire. Honcho la rangeait ailleurs.

Les prompts n’avaient rien à se reprocher. C’est la destination qui était fausse. La PR #112602 (fusionnée le 2026-09-16) corrige les deux chemins de code qui routaient les sessions au mauvais endroit. Voici ce qui était cassé, comment configurer sessionStrategy pour qu’il soit réellement appliqué, et comment vérifier dans quelle session votre mémoire a atterri.

Deux termes, une phrase chacun

Honcho est l’un des memory providers d’Hermes : il modélise vous sous forme de profil persistant d’une session à l’autre — user representation, peer card — au lieu de traiter chaque conversation comme une île.

sessionStrategy détermine comment les sessions Honcho (pensez « compartiments de mémoire ») se projettent sur votre travail. La valeur par défaut est per-directory, avec quatre niveaux :

sessionStrategy Ce que ça fait
per-session Chaque exécution de hermes démarre une session neuve ; la mémoire revient via les outils. La doc le recommande pour débuter
per-directory Une session par répertoire de travail ; le contexte s’accumule d’une exécution à l’autre (défaut)
per-repo Une session par dépôt git
global Une seule session pour tous les répertoires

Un détail à ne pas confondre avec le reste : en mode hybrid / context, Honcho injecte deux couches de contexte dans le system prompt à chaque tour — une couche de base (résumé de session, user representation, peer card, auto-représentation de l’IA) et un supplément dialectique produit par un LLM. contextCadence vaut 1 par défaut, dialecticCadence vaut 2 (la doc conseille 1–5), et le résultat concaténé est tronqué selon le budget contextTokens. La mémoire de session et le profil utilisateur sont deux choses distinctes : les mélanger rend ces bugs de routage beaucoup plus difficiles à diagnostiquer.

Si vous préférez garder la mémoire sur votre propre disque, la piste LanceDB est décrite dans comment Hermes implémente la mémoire sémantique : même problème, autre stockage.

Le symptôme : trois dépôts, une seule mémoire

Trois variantes de la même plainte, toutes avec la même configuration :

  • Vous posez une question sur le dépôt B depuis le dépôt A, et Honcho ressort les détails de B.
  • Un dépôt tout neuf arrive déjà chargé de préférences et de conclusions d’anciens projets.
  • Votre configuration dit per-repo, mais l’agent se comporte comme en global.

Les trois signifient la même chose : tous les projets tombent dans la même session, et cette session ne porte le nom d’aucun de vos dépôts.

Cause numéro un : un titre automatique renomme la session

Hermes écrit des titres de conversation à votre place. Leur provenance est derived ou llm (idem pour les titres de lineage des branches Desktop). Ils servent à reconnaître une conversation dans une liste : ce sont des métadonnées d’affichage.

L’ancien code voyait les choses autrement. Dès qu’une session avait un titre, ce titre participait à la dérivation du nom de session. Un titre automatique comme « Refactor the billing module » sortait donc la conversation de la session du dépôt pour la renommer Refactor-the-billing-module. Votre sessionStrategy était toujours configuré ; simplement, personne ne le consultait.

Cause numéro deux : la résolution utilisait le dossier de lancement, pas le workspace

Celle-ci est plus discrète. La résolution de la session key s’appuyait sur os.getcwd(), le dossier de lancement du processus backend. Sous Desktop ou via un messaging gateway, ce processus démarre généralement dans $HOME : quel que soit le dépôt depuis lequel vous écriviez, le workspace que voyait Honcho était votre répertoire personnel. Tous les projets s’effondraient dans un unique compartiment nommé home.

C’est exactement pourquoi tant de configurations semblaient globales alors que le fichier de configuration disait le contraire.

Ce que change la PR #112602

Le correctif est volontairement étroit : une modification par bug, les deux sur le chemin de résolution.

  • plugins/memory/honcho/client.py::_resolve_session_name_base — un titre dont la provenance est derived ou llm est une métadonnée d’affichage et saute entièrement la branche du titre. Un /title explicite (provenance user) reste prioritaire. Un titre sans source enregistrée conserve l’ancien comportement.
  • plugins/memory/honcho/__init__.py::_resolve_session_key — résout sur kwargs["cwd"] ou resolve_agent_cwd() (pinned session cwd → TERMINAL_CWD → dossier de lancement) : le même contrat que le system prompt et la découverte des fichiers de contexte, au lieu de os.getcwd().
  • hermes_state_common.py — les constantes TITLE_SOURCE_* vivent dans le module frère cycle-safe, donc SessionDB et le plugin lisent le même vocabulaire.
  • agent/agent_init.py — AIAgent(cwd=...) inscrit agent.session_cwd, et _memory_provider_init_kwargs transmet session_title_source et cwd au provider.
  • tui_gateway/* — les chemins eager-resume, branch, compute-host et deferred build passent cwd_override (leur enregistrement de session n’est pas encore dans _sessions, sinon _set_session_context effacerait le cwd). Un déplacement de workspace pendant un deferred build atteint également l’agent construit.

La priorité mérite d’être mémorisée. Les messaging gateways conservent leur session key stable par chat, quelle que soit la stratégie ou le titre. Pour les autres sessions : identité per-session → mapping manuel de répertoire → titre explicite → la stratégie configurée, premier match gagnant.

La fusion a été validée de bout en bout avec de vrais imports (vrai SessionDB, vrai HonchoMemoryProvider, cwd du processus pointé sur un faux $HOME, cwd de session lié à un dépôt git nommé myapp, stratégie per-repo) :

Cas Avant Après
pas de titre home myapp
titre LLM « Refactor the billing module » Refactor-the-billing-module myapp
/title My Explicit Name explicite My-Explicit-Name My-Explicit-Name

La troisième ligne est intentionnelle : un titre que vous avez écrit reste une priorité.

Configurer correctement sessionStrategy

L’assistant reste la voie la moins risquée : il interroge votre configuration de gateway et écrit les clés lui-même.

hermes memory setup    # choisir "honcho" dans la liste des providers

Configuré à la main, config.yaml doit contenir au minimum ceci :

# ~/.hermes/config.yaml
memory:
  provider: honcho
echo 'HONCHO_API_KEY=***' >> ~/.hermes/.env

La clé d’API s’obtient sur honcho.dev. Les réglages comme sessionStrategy vivent dans le bloc de configuration du provider Honcho, celui qu’écrit hermes memory setup. Si vous préférez éviter l’édition manuelle, appuyez sur [e] à l’invite de l’assistant et définissez les clés dans son éditeur.

Comment choisir votre stratégie :

  • per-repo — un monorepo plus plusieurs dépôts indépendants, chacun avec sa propre mémoire. C’est le scénario décrit plus haut.
  • per-directory — vous travaillez durablement dans un répertoire et n’avez pas besoin d’isolation entre sous-dossiers. Ce n’est pas un hasard si c’est la valeur par défaut.
  • per-session — chaque exécution repart proprement et la mémoire se récupère via les outils. C’est aussi le meilleur réglage de diagnostic, car il sépare le plus nettement mémoire de session et profil utilisateur.
  • global — uniquement si vous voulez réellement un profil partagé entre tous les projets.

Les autres réglages (surtout liés au gateway, regroupés ici pour référence) :

Réglage Défaut Effet
sessionStrategy per-directory Les quatre niveaux ci-dessus ; les stratégies par répertoire et les mappings manuels de sessions utilisent le répertoire de travail logique de la session, pas le dossier de lancement du backend
a2aSessions true Les DM d’autres bots sont écrits dans leur propre session par bot émetteur, jamais dans celle de l’humain ; false ignore complètement les tours écrits par un bot
pinUserPeer false Gateway uniquement. Si true, tous les utilisateurs de la plateforme s’effondrent sur peerName
userPeerAliases {} Gateway uniquement. Mapping des IDs runtime vers des peers ({"7654321": "alice"}), plusieurs vers un
runtimePeerPrefix "" Gateway uniquement. Namespace les IDs runtime inconnus (telegram_7654321) quand aucun alias ne correspond

La résolution des peers côté gateway teste de haut en bas, premier match gagnant : pinUserPeer → userPeerAliases[id] → runtimePeerPrefix + id → ID runtime brut → peerName → repli sur la session key. Si les faits de quelqu’un d’autre vous collent à la peau sur Telegram ou Discord, c’est ce tableau qu’il faut lire. Un avertissement de la doc : faire passer pinUserPeer de true à false ne migre aucune donnée — l’historique sous peerName reste où il est. Les détails au niveau des commandes sont dans la référence hermes memory.

Savoir dans quelle session la mémoire a atterri

Après le correctif, le nom de session est dérivable : vous pouvez donc raisonner à l’envers.

  1. Regardez la forme du nom. Avec les stratégies par répertoire ou par dépôt, c’est le nom du répertoire ou du dépôt (dans la validation, myapp) ; sans information de workspace, c’est le dossier de lancement (home) ; un titre explicite devient une forme à tirets (My-Explicit-Name). Un nom de session en forme de titre est la signature de l’ancien bug : si vous voyez Refactor-the-billing-module, le titre a pris le contrôle de la session.
  2. Faites un test croisé. Dans le dépôt A, demandez à l’agent d’enregistrer une conclusion qui n’appartient qu’à A (une conclusion écrite par honcho_conclude, ou la user card derrière honcho_profile). Passez ensuite au dépôt B et posez la question. En per-repo, B devrait rester muet. S’il répond, les deux dépôts parlent à la même session.
  3. Vérifiez le répertoire de travail lui-même. Demandez à l’agent de rapporter le répertoire de travail de l’exécution courante et comparez-le au dépôt où vous croyez être. La chaîne est : contexte de session → terminal.cwd scopé → dossier de lancement ; si un maillon renvoie $HOME, votre mémoire part dans le compartiment home.
  4. Utilisez per-session comme témoin. Basculez temporairement dessus : chaque nouvelle session doit démarrer vide. Si des faits apparaissent malgré tout, ils viennent du profil utilisateur (user representation / peer card), pas de la mémoire de session — c’est voulu, pas une contamination croisée.

Les sessions créées avant le correctif

La doc est sans ambiguïté : les sessions créées avant l’enregistrement de la provenance des titres conservent l’ancien comportement. Un ancien titre automatique est indiscernable d’un ancien titre utilisateur, donc un titre sans source est traité comme une priorité explicite. Une mise à jour ne ramène pas ces sessions sur celle du dépôt.

Il existe une seconde limite : ce correctif ne migre pas les messages déjà écrits dans des sessions mal routées. L’historique tombé dans le mauvais compartiment y reste. En pratique : ouvrez une nouvelle session dans le bon répertoire — elle se résoudra sur le bon nom de session — et continuez d’utiliser /title explicitement quand vous voulez une priorité assumée, car ce comportement n’a pas été touché.

Si vous aimez transformer vos conclusions en notes durables, faire écrire l’agent dans votre vault Obsidian depuis le bon répertoire de projet contourne tout le problème : le système de fichiers est déjà partitionné par projet. Et si vous planifiez du travail, la même chaîne de mémoire apparaît dans cron et continuité de mémoire.

À retenir

  • La mémoire Honcho a une destination précise, et cette destination est décidée par sessionStrategy et par le répertoire de travail de la session.
  • Deux bugs en ont cassé chacun une moitié : les titres automatiques (derived / llm) ne neutralisent plus la stratégie, et la résolution suit désormais le workspace de la conversation au lieu du dossier de lancement du processus. Un /title explicite reste votre priorité manuelle.
  • Utilisez per-repo pour plusieurs dépôts, per-directory pour un travail durable dans un seul répertoire, et per-session pour repartir proprement ou traquer un bug de routage.
  • Pour diagnostiquer, lisez d’abord la forme du nom de session, puis posez une question d’un dépôt à l’autre.
  • Les sessions héritées et l’historique déjà mal routé ne se déplacent pas tout seuls : ouvrez de nouvelles sessions depuis le bon répertoire.