Vous connaissez ce moment : Hermes est à mi-chemin d’une longue tâche — refactorisation d’un codebase, réorganisation d’un dépôt, surveillance d’un déploiement — et une question connexe vous traverse l’esprit : « dans quel fichier se trouvait déjà cette erreur ? » Vos options étaient jusqu’ici également mauvaises : interrompre l’agent et lui faire retrouver sa concentration, ou ouvrir une nouvelle session qui n’a aucun souvenir de ce qui se passe. Les deux font des dégâts. La PR #97937 (fusionnée le 29 août, avec le suivi #97974) transforme la troisième voie en commande intégrée : /btw <question> répond à votre question annexe sur-le-champ, en utilisant tout le contexte de la conversation en cours, sans arrêter la tâche. La même modification met /background à la retraite et fait de /bg la commande canonique des tâches en arrière-plan — /btw n’est plus seulement son alias.

Pourquoi c’était si pénible avant

/bg et /btw étaient tous deux des alias de /background : « envoyer cette phrase à une session d’arrière-plan et l’exécuter. » Cela semble acceptable jusqu’à ce qu’on tombe sur le défaut fatal : la session d’arrière-plan est toute neuve et ne sait rien de votre contexte actuel.

L’usage classique s’effondrait donc :

/btw which file was that error in?

L’agent d’arrière-plan sans contexte ne pouvait que répondre « je ne sais pas de quelle erreur vous parlez » — ou vous forcer à coller le contexte. Tout l’intérêt d’une question annexe — emprunter le contexte de la conversation en cours pour obtenir une réponse rapide — n’aboutissait jamais.

Comment /btw fonctionne maintenant

L’idée centrale : la question n’entre jamais dans la session principale. Elle est traitée « de côté », à partir d’un instantané de la session principale. L’implémentation (agent/side_question.py) comporte deux chemins, choisis automatiquement :

Premier chemin : un fork à parité de cache (préféré). Si l’agent de la session courante est toujours vivant, /btw construit un « fork à parité de cache » — le même mécanisme que celui utilisé par la revue d’auto-amélioration en arrière-plan. Le fork hérite du runtime du parent, d’un prompt système et d’une liste d’outils identiques octet pour octet, et du session_id partagé, puis rejoue l’instantané de la conversation à l’identique. Comme le cache de préfixe du fournisseur est déjà chaud pour ce replay exact, la réponse annexe voit toute la conversation, non tronquée, au prix de lecture du cache. Chaque appel d’outil est refusé à la distribution (liste blanche de threads vide), la persistance est entièrement détachée — aucune écriture dans state.db, aucune rotation de session, aucun hook de mémoire externe. L’utilisation est imputée à la session parente.

Deuxième chemin : un digest à usage unique (repli). Si l’agent de la session a été expulsé (par exemple le gateway a largué l’agent mis en cache — le cache du fournisseur est de toute façon froid à ce moment-là), le système se dégrade et rend un digest en texte brut, biaisé vers les éléments les plus récents, de la conversation, puis répond via un appel auxiliaire à usage unique. Le digest exclut le prompt système et résume les appels d’outils et leurs résultats.

Sur les deux chemins, l’historique de la session principale, l’alternance des rôles et le cache de prompt restent intouchés par construction — c’est la contrainte dure de la conception.

Comment l’utiliser

Disponible dans la CLI, la TUI et sur les plateformes gateway (Telegram, Discord, Slack, …) — et cela fonctionne pendant que l’agent est occupé (busy_policy="dispatch", vous pouvez donc intervenir en plein déroulement) :

# Task running, sudden question
/btw which file was that error in?
→ /btw answers with the full conversation context: it's in src/utils/parser.py, line 42 …

# A background question about the current task
/btw what approach did we settle on for retries?

Envie d’un modèle différent pour répondre aux questions annexes ? Il existe un réglage de tâche auxiliaire dédié :

auxiliary:
  side_question:
    provider: anthropic
    model: claude-sonnet-4-5

Sans lui, c’est le modèle principal qui est utilisé. À noter : un modèle différent signifie un cache froid, donc le système retombe sur le chemin du digest compact.

Le changement annexe : /bg devient officiel

Le nom verbeux /background a disparu (suggestion de la communauté : suivre la convention courte du style /btw). Les tâches d’arrière-plan n’ont plus qu’un seul nom :

/bg compile a report of every TODO in this directory

/btw et /bg ont chacun leur couloir : /bg distribue les tâches indépendantes, /btw répond aux petites questions en utilisant le contexte courant. Si vous avez l’habitude de taper /background, il est temps de rééduquer votre mémoire musculaire.

Quand /btw est le plus rentable

• En pleine longue tâche : déploiements, migrations par lots, revue de code en cours — demandez « où en sommes-nous ? » ou « c’était quoi cet avertissement ? » sans rien mettre en pause.
• Questions dépendantes du contexte : « quelle convention de nommage avons-nous validée ? » « que dit le AGENTS.md de ce dépôt ? » — la réponse annexe voit toute la conversation.
• Garder la session principale propre : l’instantané est en lecture seule ; aucune trace dans l’historique, aucun impact sur la compression ou la mise en cache.

Un bémol honnête : les deux PR ont atterri le 29 août, donc elles n’existent pour l’instant que sur main — aucune étiquette de release ne les contient encore (v0.20.6 a été taguée le 27 août). Pour les essayer aujourd’hui, lancez hermes update et tournez avec le code le plus récent ; sinon, attendez la prochaine release.

Résumé

/btw transforme le besoin très fréquent de « poser une petite question avec le contexte courant » en commande de première classe à coût nul : pas d’interruption, pas de cache brûlé sur la session principale, pas de pollution de l’historique. Avec /bg qui reprend la distribution des tâches, « demander » et « déléguer » dans une session sont enfin nettement séparés. La prochaine fois qu’une question surgit en plein travail, essayez d’ouvrir par /btw — il comprend de quoi vous parlez mieux que vous ne le pensez.

Pour approfondir l’écosystème des slash commands, consultez notre guide de la palette de commandes ; pour d’autres façons de gérer un agent occupé (intervenir, mettre en file, piloter sans interrompre), la famille /busy vaut aussi le détour. Les deux PR font partie du flux post-v0.20.6 sur main — les notes de version v0.20.6 résument toute cette fenêtre.