Après avoir changé le modèle d'une session, impossible de revenir en arrière — désormais /model reset le ramène au modèle par défaut


La semaine dernière, vous avez essayé un nouveau modèle. Vous avez tapé /model, vous avez changé, vous l’avez utilisé dix minutes, puis vous avez voulu retrouver votre ancien modèle. Vous avez modifié la valeur par défaut dans config.yaml, redémarré la gateway — et la session tournait toujours sur le nouveau modèle. Au final, vous avez lancé /new et regardé deux jours de contexte disparaître.

Ce n’est pas un bug de cache. Le changement effectué dans la session est un épinglage stocké sur la session : il est écrit dans le stockage des sessions (et dans la ligne de session côté Desktop), et il prime sur tout ce que vous modifiez ensuite dans la valeur par défaut. La seule façon de retirer cet épinglage consistait à démarrer une nouvelle session — au prix de l’historique.

Trois couches de configuration du modèle, et laquelle gagne

Pour comprendre pourquoi, regardez d’où vient réellement un modèle. Il y a trois couches :

  1. model.default dans config.yaml — la valeur par défaut globale, la couche que vous modifiez normalement.
  2. channel_overrides — un modèle défini par canal ou par chat, qui prime sur config.yaml.
  3. La surcharge de session — le modèle vers lequel vous avez basculé avec /model dans une conversation. Priorité la plus haute, et persistée.

La persistance, voilà le piège. Ce n’est pas une simple variable en mémoire : après un redémarrage, la restauration de session la ramène, et modifier config.yaml ne sert à rien puisque la couche de session est lue en premier. D’où cet état déroutant où la config dit clairement modèle A et où la session continue de tourner sur modèle B.

La seule échappatoire était /new : une session neuve n’a pas d’épinglage, elle retombe donc sur la valeur par défaut. Le prix à payer était le contexte.

/model reset : retirer l’épinglage, garder l’historique

Le /model reset récemment fusionné comble ce manque. Sans argument, il fait une chose très précise : il efface la surcharge de modèle de cette session, pour que la session résolve à nouveau son modèle via les surcharges de canal puis config.yaml — transcription intacte.

Les surfaces diffèrent légèrement dans la mécanique, mais s’accordent sur le sens :

Surface Ce qu’elle fait
Gateway de messagerie (Telegram, Discord, Slack, …) Efface la surcharge en mémoire, la surcharge persistée et toute restauration --once armée ; évince l’agent en cache pour que le tour suivant soit construit depuis la route par défaut ; dépose une note de modèle pour le tour suivant afin que le modèle ne continue pas à s’identifier comme l’ancien
TUI gateway / Desktop (config.set model) Retire l’épinglage et la restauration d’un tour, adopte config.yaml via le commutateur de synchro de config sans écrire de nouvel épinglage, et persiste la ligne de session pour que session.resume ne puisse pas ressusciter l’ancien épinglage
CLI classique Relit config.yaml à neuf (sans cache) pour la valeur par défaut courante ; s’il n’y a pas de model.default, elle indique qu’il n’y a rien vers quoi revenir

Le message de succès dit exactement ce qui s’est passé au lieu d’un vague « switched » :

Session model override cleared — now using `provider/your-default-model` (the channel/global default). Conversation history kept.

Et quand il n’y avait pas d’épinglage, il ne prétend pas le contraire :

No session model override is active — already using `provider/your-default-model` (the channel/global default).

La CLI a sa propre copie pour deux cas limites : déjà sur la valeur par défaut configurée (« rien à réinitialiser »), et pas de model.default dans config.yaml (« rien vers quoi réinitialiser »).

Règles à connaître

Aucun drapeau autorisé. Tout ce qui suit /model reset est rejeté, avec un message qui explique pourquoi : « /model reset takes no flags — it clears this session’s model override so the configured default applies again. » Pour basculer vers un modèle précis, utilisez /model <name> ; pour changer la valeur par défaut globale, utilisez --global. Ne mélangez pas les deux dans une seule commande.

Ce n’est pas un alias de default. /model default garde son ancien sens (MoA a un preset littéralement nommé default), et c’est pourquoi reset a été créé comme un type de requête distinct plutôt que comme « basculer vers un modèle appelé default ». Si l’un de vos identifiants de modèle est réellement reset, la forme qualifiée (vendor/reset ou vendor:reset) y accède toujours.

« Default » n’est peut-être pas ce qu’il y a dans config.yaml. La résolution passe d’abord par les surcharges de canal, donc dans ce chat /model reset revient au modèle que le canal est censé utiliser. Si vous avez configuré un modèle pour un groupe, c’est le comportement attendu — les surcharges de modèle par chat explique toute la chaîne de priorité.

Cela ne touche pas votre config. /model reset ne change que la couche de session. Pour changer la valeur par défaut globale, utilisez /model <name> --global ou modifiez config.yaml. Garder les deux séparés, c’est précisément ce qui empêche une expérimentation de devenir silencieusement la valeur par défaut de tout le monde.

Quand il est utile

  • Essayer des modèles : basculez, comparez quelques tours, revenez — sans nouvelle session.
  • Un --once par erreur : le modèle d’un seul tour est censé ne durer qu’un tour ; s’il est resté coincé, reset efface aussi cette restauration armée.
  • Déboguer la session de quelqu’un d’autre : quand « j’ai changé la config et rien ne s’est passé », faites un reset et voyez sur quel modèle ça tourne réellement.
  • Après un changement de fournisseur : retirez l’ancien épinglage pour que le nouveau routage prenne effet.

Côté statut, clairement : /model reset a été fusionné le 2026-11-01 (PR #80448) et figure dans la v0.22.6 (2026-11-02) : une mise à jour normale suffit ; la v0.22.5 et les versions antérieures n’ont pas la commande.

Lectures associées : comment déclarer les fenêtres de contexte et les capacités quand le catalogue de modèles est faux — le guide model_overrides ; comment la compression et les approbations tournent sur une voie de modèle séparée — la voie de modèle auxiliaire ; la liste complète des arguments — référence de la commande hermes model.