Semana passada você testou um modelo novo. Digitou /model, trocou, usou por dez minutos e depois quis de volta o modelo antigo. Editou o padrão no config.yaml, reiniciou o gateway — e a sessão continuava rodando no modelo novo. No fim, você executou /new e viu dois dias de contexto desaparecerem.

Isso não é um bug de cache. A troca que você fez dentro da sessão é um pin guardado na sessão: ele é gravado no session store (e na linha da sessão no Desktop) e tem precedência sobre qualquer coisa que você altere no padrão depois. A única forma de arrancar esse pin costumava ser abrir uma sessão nova — ao custo do histórico.

Três camadas de configuração de modelo, e qual vence

Para entender o motivo, veja de onde um modelo realmente vem. São três camadas:

1. model.default no config.yaml — o padrão global, a camada que você normalmente edita.
2. channel_overrides — um modelo definido por canal ou chat, que tem precedência sobre o config.yaml.
3. O override da sessão — o modelo para o qual você trocou com /model em uma conversa. Prioridade máxima, e persistido.

A persistência é a armadilha. Não se trata de uma variável em memória do processo: depois de um restart, a restauração da sessão traz o pin de volta, e editar o config.yaml não resolve nada porque a camada da sessão é lida primeiro. O resultado é aquele estado confuso em que a config diz claramente modelo A e a sessão continua rodando o modelo B.

A única escapatória era /new: uma sessão nova não tem pin, então cai no padrão. O preço era o contexto.

/model reset: arranque o pin, mantenha o histórico

O recém-integrado /model reset fecha essa lacuna. Sem argumentos, ele faz uma coisa bem específica: limpa o override de modelo desta sessão para que a sessão volte a resolver seu modelo pelos channel overrides e depois pelo config.yaml — com o transcript intacto.

As superfícies diferem um pouco na mecânica, mas concordam no significado:

Superfície	O que faz
Gateway de mensageria (Telegram, Discord, Slack, …)	Limpa o override em memória, o override persistido e qualquer restauração --once armada; descarta o agente em cache para que o próximo turno seja montado a partir da rota padrão; deixa uma nota de modelo para o próximo turno, para que o modelo não continue se identificando como o antigo
Gateway do TUI / Desktop (config.set model)	Descarta o pin e a restauração de um turno, adota o config.yaml pelo switch de sincronização de config sem gravar um novo pin, e persiste a linha da sessão para que session.resume não ressuscite o pin antigo
CLI clássica	Lê o config.yaml do zero (sem cache) para pegar o padrão atual; se não houver model.default, informa que não há para onde voltar

A mensagem de sucesso diz exatamente o que aconteceu, em vez de um vago “trocado”:

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

E quando não havia pin, ela não finge o contrário:

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

A CLI tem sua própria versão para dois casos de borda: já estar no padrão configurado (“nada para resetar”) e não haver model.default no config.yaml (“nada para resetar para”).

Regras que vale a pena saber

Nenhuma flag é permitida. Qualquer coisa depois de /model reset é rejeitada, com uma mensagem que explica o motivo: “/model reset takes no flags — it clears this session’s model override so the configured default applies again.” Para trocar para um modelo específico use /model <nome>; para mudar o padrão global use --global. Não misture as duas coisas em um comando.

Não é um alias de default. /model default mantém o significado antigo (o MoA tem um preset literalmente chamado default), e por isso reset virou um tipo de requisição separado em vez de “trocar para um modelo chamado default”. Se algum dos seus ids de modelo for realmente reset, a forma qualificada (vendor/reset ou vendor:reset) ainda chega nele.

“Padrão” pode não ser o que está no config.yaml. A resolução passa primeiro pelos channel overrides, então dentro daquele chat o /model reset volta para o modelo que o canal deve usar. Se você configurou um modelo para um grupo, esse é o comportamento esperado — overrides de modelo por chat explica a cadeia de precedência completa.

Não mexe na sua config. O /model reset só altera a camada da sessão. Para mudar o padrão global, use /model <nome> --global ou edite o config.yaml. Manter as duas coisas separadas é o que impede um experimento de virar silenciosamente o padrão de todo mundo.

Quando vale a pena

• Testando modelos: troque, compare alguns turnos, volte com reset — sem precisar de uma sessão nova.
• Um --once por engano: o modelo de um turno deveria durar um turno; se ficou preso, o reset limpa essa restauração armada também.
• Depurando a sessão de outra pessoa: quando o relato é “mudei a config e nada aconteceu”, dê um reset e veja em qual modelo ela roda de fato.
• Depois de trocar de provider: arranque o pin antigo para que o novo roteamento entre em vigor.

Sobre o status, sem rodeios: o /model reset entrou em 2026-11-01 (PR #80448) e já está na v0.22.6 (2026-11-02), então basta atualizar; o v0.22.5 e anteriores não têm o comando.

Leitura relacionada: como declarar janelas de contexto e capacidades quando o catálogo de modelos está errado — o guia de model_overrides; como compressão e aprovações rodam em uma faixa separada de modelo — a faixa de modelo auxiliar; a lista completa de argumentos — referência do comando hermes model.