La semana pasada probaste un modelo nuevo. Escribiste /model, cambiaste, lo usaste diez minutos y luego quisiste recuperar tu modelo de siempre. Editaste el valor por defecto en config.yaml, reiniciaste la gateway… y la sesión seguía corriendo con el modelo nuevo. Al final ejecutaste /new y viste desaparecer dos días de contexto.

No es un bug de caché. El cambio que hiciste dentro de la sesión es un pin guardado en la sesión: se escribe en el almacén de sesiones (y en la fila de sesión de Desktop), y tiene prioridad sobre cualquier cosa que cambies después en el valor por defecto. La única forma de sacar ese pin era abrir una sesión nueva, a costa del historial.

Tres capas de configuración de modelo, y cuál gana

Para entender por qué, mira de dónde sale realmente un modelo. Hay tres capas:

1. model.default en config.yaml — el valor por defecto global, la capa que normalmente editas.
2. channel_overrides — un modelo definido por canal o por chat, que tiene prioridad sobre config.yaml.
3. El override de sesión — el modelo al que cambiaste con /model en una conversación concreta. Máxima prioridad y, además, persistido.

La persistencia es la trampa. No es una simple variable en memoria: tras un reinicio, la restauración de la sesión lo recupera, y editar config.yaml no sirve de nada porque la capa de sesión se lee primero. El resultado es ese estado desconcertante en el que la configuración dice claramente modelo A y la sesión sigue con el modelo B.

La única escapatoria era /new: una sesión nueva no tiene pin, así que vuelve al valor por defecto. El precio era el contexto.

/model reset: quita el pin y conserva el historial

El recién fusionado /model reset cierra ese hueco. Sin argumentos hace una cosa muy concreta: borra el override de modelo de esta sesión para que vuelva a resolver su modelo pasando por los overrides de canal y luego por config.yaml, con la transcripción intacta.

Las superficies difieren un poco en la mecánica, pero coinciden en el significado:

Superficie	Qué hace
Gateway de mensajería (Telegram, Discord, Slack, …)	Borra el override en memoria, el override persistido y cualquier restauración --once armada; expulsa el agente en caché para que el siguiente turno se construya desde la ruta por defecto; deja una nota de modelo para el siguiente turno para que el modelo no siga identificándose como el anterior
Gateway de la TUI / Desktop (config.set model)	Elimina el pin y la restauración de un turno, adopta config.yaml mediante el interruptor de sincronización de configuración sin escribir un pin nuevo, y persiste la fila de sesión para que session.resume no pueda resucitar el pin viejo
CLI clásica	Lee config.yaml de nuevo (sin caché) para obtener el valor por defecto actual; si no hay model.default, avisa de que no hay a qué volver

El mensaje de éxito dice exactamente qué pasó, en lugar de un “cambiado” vago:

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

Y cuando no había ningún pin, no finge lo contrario:

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

La CLI tiene su propia copia para dos casos límite: cuando ya estás en el valor por defecto configurado (“nothing to reset”) y cuando no hay model.default en config.yaml (“nothing to reset to”).

Reglas que conviene conocer

No admite flags. Cualquier cosa después de /model reset se rechaza, con un mensaje que explica por qué: “/model reset takes no flags — it clears this session’s model override so the configured default applies again.” Para cambiar a un modelo concreto usa /model <name>; para cambiar el valor por defecto global usa --global. No mezcles las dos cosas en un mismo comando.

No es un alias de default. /model default conserva su significado anterior (MoA tiene un preset que se llama literalmente default), y por eso reset se implementó como un tipo de petición aparte en lugar de como “cambiar a un modelo llamado default”. Si alguno de tus ids de modelo es de verdad reset, la forma cualificada (vendor/reset o vendor:reset) sigue llegando a él.

“Default” puede no ser lo que hay en config.yaml. La resolución pasa primero por los overrides de canal, así que dentro de ese chat /model reset vuelve al modelo que el canal debe usar. Si configuraste un modelo para un grupo, es el comportamiento esperado: overrides de modelo por chat explica la cadena de precedencia completa.

No toca tu configuración. /model reset solo cambia la capa de sesión. Para cambiar el valor por defecto global, usa /model <name> --global o edita config.yaml. Mantener ambas cosas separadas es lo que evita que un experimento se convierta en silencio en el valor por defecto de todo el mundo.

Cuándo merece la pena

• Probar modelos: cambias, comparas un par de turnos, vuelves con reset; no hace falta una sesión nueva.
• Un --once equivocado: el modelo de un turno debe durar un turno; si se quedó pegado, el reset también limpia esa restauración armada.
• Depurar la sesión de otra persona: cuando “cambié la configuración y no pasó nada”, haz un reset y mira con qué modelo corre de verdad.
• Después de cambiar de proveedor: quita el pin viejo para que el nuevo enrutado pueda surtir efecto.

Sobre el estado, sin rodeos: /model reset se fusionó el 2026-11-01 (PR #80448) y ya está en la v0.22.6 (2026-11-02), así que basta actualizar; la v0.22.5 y anteriores no tienen el comando.

Lecturas relacionadas: cómo declarar ventanas de contexto y capacidades cuando el catálogo de modelos está mal — la guía de model_overrides; cómo la compresión y las aprobaciones corren en un carril de modelo aparte — el carril de modelo auxiliar; la lista completa de argumentos — referencia del comando hermes model.