Ein Modell beim Client: Das Gateway staffelt automatisch
Nehmen Sie die Modellwahl aus der UI — der Client stellt einen einzigen Modellnamen bereit, Planung läuft auf dem starken Modell und Ausführung landet auf dem kosteneffizienten, gestaffelt auf dem Hop, den die Anfrage ohnehin nahm.
Worüber die Community tatsächlich klagt
„Jeder hat ein anderes Modell in den Einstellungen und derselbe Prompt kommt bei zwei Personen unterschiedlich heraus“, „die häufigste Frage in der ersten Woche ist, welches Modell soll ich wählen“, „ein Modell außer Betrieb zu nehmen bedeutet, Umgebungsvariablen auf jeder Entwicklermaschine zu ändern“. Die Modellwahl wurde den Personen übergeben, die die wenigsten Informationen haben, um sie zu treffen: Sie können ihre eigenen Ausgaben nicht sehen und haben keine Möglichkeit zu wissen, ob diese konkrete Anfrage das starke Modell verdient.
Stellen Sie stattdessen alle auf ein günstiges Modell, und die Arbeit leidet — übertragen Sie Planung und Architektururteil einem kleinen Modell, und die Nacharbeit kostet mehr als die Ersparnis. Die entscheidende Trennung ist, was diese Anfrage gerade tut: Planung oder Ausführung. Und der Client hat dem Gateway das nie mitgeteilt.
Wie GateLLM es macht
Der Client behält einen einzigen Modellnamen; eine Catch-all-Zuordnung (von „*“) am Gateway normalisiert, welchen Namen der Client auch anfragt, sodass das Bearbeiten persönlicher Einstellungen nicht länger ändert, wo die Anfrage landet. Es bleibt nichts zu erklären, welches Modell zu wählen ist.
Das Staffelungssignal ist bereits in der Unterhaltung: Der Plan-Modus von Claude Code injiziert beim Eintritt „Plan mode is active“ und beim Verlassen „Exited Plan Mode“. Ein Before-Slot-Skript scannt rückwärts von der letzten Nachricht, nimmt den zuletzt gesehenen Marker, um den aktuellen Zustand zu bestimmen, und ruft dann context.useModel() auf, um das Routing zu wechseln. Die Entscheidung ist ein String-Positionsvergleich — kein separater Klassifizierungsaufruf, kein zusätzlicher Netzwerk-Hop.
Die Staffelung muss im Before-Slot leben: Der After-Slot sieht den übersetzten Upstream-Body und kann die client-injizierten Marker nicht lesen, und after-slot-useModel wechselt nur innerhalb desselben Protokolls, während Plan → Ausführung eine modellübergreifende Routenänderung ist. request_payload-Regeln (prompt_cache_key und Verwandte) müssen auf beiden Modellen konfiguriert werden: Das Einstiegsmodell behält seine eigenen während der Planung, die des Zielmodells gelten, sobald der Wechsel erfolgt.
5 Hebel, die tatsächlich wirken
- Ein einziger Ingress-Name: Der Client stellt einen Modellnamen bereit, und eine Catch-all-Zuordnung von „*“ normalisiert jeden angefragten Namen auf ein Landemodell
- Automatische Staffelung: Ein Before-Slot-Skript nimmt den letzten Marker beim Rückwärtsscannen — der Eintrittsmarker bleibt für immer in der Historie, sodass eine „enthält“-Prüfung den Zustand dauerhaft als Plan-Modus liest
- Protokoll-Schutz: Das Skript prüft zuerst context.sourceProtocol und kehrt für Nicht-Anthropic-Datenverkehr früh zurück, sodass ein Einstiegsmodell, das mehrere Clients bedient, nie falsch geroutet wird
- Transparent: Ein SW-Tag in der Log-Spalte „Modell“ markiert einen Skriptwechsel und MM eine Identitätszuordnung; Statistiken und Abrechnung ordnen dem endgültigen Modellnamen zu, sodass jede Staffelungsentscheidung auditierbar ist
- Kein Client-Rollout: Konfigurationsänderungen erfordern keine Bearbeitung pro Maschine, und Zuordnungen werden hot-reloaded (die einzige Ausnahme ist das Skript-Heap-Limit SCRIPT_MEMORY_LIMIT_MB, das einen Neustart erfordert)