Letzte Woche hast du ein neues Modell ausprobiert. Du hast /model getippt, gewechselt, es zehn Minuten lang benutzt und dann dein altes Modell zurückhaben wollen. Du hast den Default in config.yaml geändert, das Gateway neu gestartet — und die Session lief weiter auf dem neuen Modell. Am Ende hast du /new ausgeführt und zugesehen, wie zwei Tage Kontext verschwanden.

Das ist kein Caching-Bug. Der Wechsel, den du in der Session gemacht hast, ist ein Pin, der an der Session hängt: Er wird im Session-Store (und in der Session-Zeile auf dem Desktop) geschrieben und steht über allem, was du danach am Default änderst. Diesen Pin wieder herauszuziehen ging bisher nur über eine neue Session — auf Kosten der Historie.

Drei Ebenen der Modellkonfiguration — und welche gewinnt

Um zu verstehen, warum, schau dir an, woher ein Modell tatsächlich kommt. Es gibt drei Ebenen:

1. model.default in config.yaml — der globale Default, die Ebene, die du normalerweise bearbeitest.
2. channel_overrides — ein Modell pro Channel oder Chat, das über config.yaml steht.
3. Der Session-Override — das Modell, zu dem du in einer Konversation mit /model gewechselt hast. Höchste Priorität, und persistiert.

Die Persistenz ist die Falle. Es ist nicht bloß eine Variable im Prozess: Nach einem Neustart bringt der Session-Restore sie zurück, und eine Änderung an config.yaml bewirkt nichts, weil die Session-Ebene zuerst gelesen wird. Das Ergebnis ist dieser verwirrende Zustand, in dem die Config klar Modell A sagt und die Session weiter Modell B fährt.

Der einzige Ausweg war /new: Eine frische Session hat keinen Pin und fällt deshalb auf den Default zurück. Der Preis war der Kontext.

/model reset: den Pin ziehen, den Verlauf behalten

Das neu gemergte /model reset schließt diese Lücke. Ohne Argumente tut es genau eine Sache: Es löscht den Modell-Override dieser Session, sodass die Session ihr Modell wieder über Channel-Overrides und dann über config.yaml auflöst — mit intaktem Transkript.

Die Oberflächen unterscheiden sich leicht in der Mechanik, sind sich aber in der Bedeutung einig:

Oberfläche	Was passiert
Messaging-Gateway (Telegram, Discord, Slack, …)	Löscht den Override im Speicher, den persistierten Override und einen eventuell scharfen --once-Restore; wirft den gecachten Agenten hinaus, damit der nächste Turn aus der Default-Route gebaut wird; hinterlässt eine Modell-Notiz für den nächsten Turn, damit sich das Modell nicht weiter als das alte ausgibt
TUI-Gateway / Desktop (config.set model)	Verwirft den Pin und den One-Turn-Restore, übernimmt config.yaml über den Config-Sync-Schalter, ohne einen neuen Pin zu schreiben, und persistiert die Session-Zeile, sodass session.resume den alten Pin nicht wiederbeleben kann
Klassische CLI	Liest config.yaml frisch (ohne Cache) für den aktuellen Default; existiert kein model.default, sagt sie, dass es nichts gibt, wohin man zurückgehen könnte

Die Erfolgsmeldung benennt genau, was passiert ist, statt eines vagen „gewechselt“:

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

Und wenn kein Pin da war, tut sie nicht so als ob:

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

Die CLI hat eine eigene Variante für zwei Randfälle: bereits auf dem konfigurierten Default („nothing to reset“) und kein model.default in config.yaml („nothing to reset to“).

Regeln, die man kennen sollte

Keine Flags erlaubt. Alles hinter /model reset wird abgelehnt, mit einer Meldung, die den Grund nennt: „/model reset takes no flags — it clears this session’s model override so the configured default applies again.“ Um auf ein bestimmtes Modell zu wechseln, nimm /model <name>; um den globalen Default zu ändern, --global. Beides nicht in einem Befehl vermischen.

Es ist kein Alias für default. /model default behält seine alte Bedeutung (MoA hat ein Preset, das buchstäblich default heißt), weshalb reset als eigener Request-Typ umgesetzt wurde und nicht als „wechsle zu einem Modell namens default“. Falls eine deiner Modell-IDs tatsächlich reset ist, erreichst du sie weiterhin über die qualifizierte Form (vendor/reset oder vendor:reset).

„Default“ muss nicht das sein, was in config.yaml steht. Die Auflösung läuft zuerst über Channel-Overrides, also kehrt /model reset innerhalb dieses Chats zu dem Modell zurück, das der Channel eigentlich nutzen soll. Wenn du für eine Gruppe ein Modell konfiguriert hast, ist das erwartetes Verhalten — Modell-Overrides pro Chat erklärt die vollständige Prioritätskette.

Es fasst deine Config nicht an. /model reset ändert nur die Session-Ebene. Um den globalen Default zu ändern, nutze /model <name> --global oder bearbeite config.yaml. Dass die beiden getrennt bleiben, ist genau das, was verhindert, dass ein Experiment stillschweigend zum Default aller wird.

Wann es sich lohnt

• Modelle ausprobieren: wechseln, ein paar Turns vergleichen, zurücksetzen — ohne neue Session.
• Ein versehentliches --once: Das One-Turn-Modell soll einen Turn gelten; wenn es hängen geblieben ist, räumt Reset auch diesen scharfen Restore weg.
• Fremde Sessions debuggen: Wenn „ich habe die Config geändert und nichts ist passiert“ kommt, einmal zurücksetzen und sehen, welches Modell tatsächlich läuft.
• Nach einem Provider-Wechsel: den alten Pin ziehen, damit das neue Routing greifen kann.

Zum Status, offen gesagt: /model reset wurde am 2026-11-01 gemergt (PR #80448) und ist mit v0.22.6 (2026-11-02) in ein Release gekommen – ein normales Update genügt; v0.22.5 und älter kennen den Befehl nicht.

Weiterlesen: wie man Kontextfenster und Fähigkeiten deklariert, wenn der Modellkatalog falsch liegt — der model_overrides-Leitfaden; wie Kompression und Approvals auf einer separaten Modell-Spur laufen — die Auxiliary-Model-Lane; die vollständige Argumentliste — Referenz zum Befehl hermes model.