Sobald das OpenClaw Gateway läuft, fragt die Produktion meist, wie man Kosten und Latenz gemeinsam im Griff behält. modelRouting staffelt den Verkehr vor dem Upstream-Aufruf nach geschätzter Kontextgröße, statt immer Flaggschiff-Preise zu zahlen. Dieser Leitfaden erklärt welches Problem es löst, wie es neben agents.defaults und Fallbacks in openclaw.json steht, wie man SLOs auf maxTokens-Leitern abbildet, und liefert eine sechsstufige Rollout-Checkliste plus Fehlerkonfiguration—ergänzend zu Install-, systemd- und Docker-Artikeln auf dieser Site.
In Produktion tragen OpenClaw-Anfragen oft Systemprompts, Chatverlauf, Tool-Ausgaben und RAG-Chunks zusammen. Alles dauerhaft in ein Flaggschiff-Modell zu schicken explodiert Rechnungen und Tail-Latenz; sich nur auf Fallbacks nach Fehlern zu verlassen bedeutet, Sie haben schon einen riesigen Kontext verbrannt, bevor Sie merken, dass der Pfad falsch war. modelRouting schätzt die Kontext-Tokengröße vor der Upstream-Inferenz und wählt eine Stufe, sodass „kleine Fragen standardmäßig kleine Modelle“ bekommen—nicht nachträglich.
Sechs typische Schmerzsignale—treffen mehrere zu, gehört Routing auf die Config-Review-Agenda, statt nur Grafana anzustarren:
Long-Tail-Latenz: p95/p99 entkoppeln sich vom Mittelwert bei gleicher QPS und folgen der Gesprächslänge—schwere Kontextpfade werden übernutzt.
Nichtlineare Kosten: Traffic +30 %, Rechnung +100 %—oft „jede Session defaultet auf das größte Modell“.
Tool-Calls blähen den Kontext auf: mehrstufige Tool-Ausgabe in einem Turn spitzt Tokens, stiller Truncation oder überraschende Retries.
Zu lange Fallback-Ketten: Nutzer merken nichts, aber Sie haben Modelle in einer Anfrage verkettet—Latenz und Kosten summieren sich.
Keine Routing-Observability: Sie loggen nur den finalen Modellnamen, nicht warum diese Stufe—Triage wird Rätselraten.
Schwache Multi-Tenant-Isolation: schwere Sessions auf einem gemeinsamen Gateway ziehen leichte Session-SLOs mit—hartes Gating nach Kontextform nötig.
Nach der OpenClaw Install/Deploy-Serie der Site sollten Sie bereits „Prozess bleibt oben, Ports/Tunnel gesund“ haben. Dieser Artikel behandelt Modellauswahl innerhalb desselben lang laufenden Prozesses. Er ist orthogonal zu Remote-Ausführung (Self-Hosted-Runner oder dedizierte Remote-Macs): Routing wählt welches Gehirn; die Executor-Schicht wählt welche Maschine die Arbeit macht.
Ein Mythos: modelRouting sei „noch ein Load Balancer“. Es ist näher an Kontextform-Routing—Größe schätzen, dann Modell wählen—nicht Round-Robin, sonst wirken Traces clever und Rechnungen ehrlich.
Sie schließen sich nicht aus, aber trennen Sie die Jobs: Fallbacks passen zu Fehlersemantik—Modell nicht verfügbar, Fehler, Rate Limits; modelRouting zu Kosten-/Latenzsemantik—wie schwer dieser Turn ist. Vermischen Sie beides, erhalten Sie „Route wählte großes Modell, dann fiel Fehler auf kleines zurück“—doppelt bezahlt fürs Drama.
| Dimension | Primary + Fallbacks (klassisch) | modelRouting (Kontextstufen) |
|---|---|---|
| Auslöser | Fehlercodes, Timeouts, retrybare Fehler | Geschätzte Kontext-Token-Schwellen (z. B. Kontextgrößen-Strategie) |
| Hauptgewinn | Verfügbarkeit: Rettung vom schlechten Modell | Effizienz: leichte Chats zahlen keine Flaggschiff-Preise |
| Typisches Risiko | Lange Ketten blähen Tail-Latenz und doppelte Abrechnung | Schlechte Schwellen klassifizieren schwer vs. leicht falsch |
| Observability | Fehlerraten, Retries, warum gewechselt | Route-Treffermix, Fehler nahe Schwellen, Token-Perzentile |
| agents.defaults | Primary + Fallback-Liste deklarieren | Routing-Block unter defaults ergänzen, vor dem Aufruf splitten |
Schreiben Sie „Tausch bei Fehler“ und „Wahl vor Fehler“ auf zwei Seiten—Ihr On-Call wird es danken.
Loggen Sie Routing-Entscheidungen strukturiert (Stufen-Treffer, geschätztes Token-Band, finales Modell-ID); sonst zeigt Prod nur das finale Modell und Schwellen sind nicht reviewbar. Die sechs Schritte unten sind das Release-Gate.
Für Ingenieure, die Config-Änderungen bereits ausliefern—jeder Schritt hat ein Artefakt, damit modelRouting kein einmaliges JSON-Gekritzel wird.
SLO-Sprache einfrieren: Ziel-p95-Latenz, Kostenobergrenze pro Session, angenommener Anteil „schwerer“ Sessions. Ohne SLO keine ernsthaften Schwellen.
Token-Verteilungen samplen: echte Chats und Tool-Ausgaben—inklusive Schwänze, nicht nur mittlere Sessionlänge.
Drei Stufen skizzieren: leicht/mittel/schwere Modell-IDs und explizite Tasks, die nie auf die leichte Stufe dürfen (z. B. mehrstufige Tools).
modelRouting + Telemetrie verdrahten: Treffer, geschätzte Tokens, finales Modell in strukturierte Logs und Ihre Metrik-Stack.
Kontrolliertes Canary: Alt vs. neu auf einem Slice parallel, Kosten- und Latenz-Perzentile beobachten, dann promoten.
Rollback-Schalter: Snapshot behalten, um bei Routing-Fehlzündungen zu „defaults + kurze Fallback-Kette“ zurückzukehren.
{
"agents": {
"defaults": {
"model": { "primary": "anthropic/claude-sonnet-4-5" },
"modelRouting": {
"enabled": true,
"strategy": "context-size",
"thresholds": [
{ "maxTokens": 4000, "model": "anthropic/claude-haiku-4-5", "description": "light" },
{ "maxTokens": 100000, "model": "anthropic/claude-sonnet-4-5", "description": "medium" },
{ "maxTokens": null, "model": "anthropic/claude-opus-4-5", "description": "xlarge context" }
],
"fallbackOnOverflow": true
}
}
}
}
Hinweis: Dies zeigt Form und Semantik; echte Keys/Defaults müssen zu Ihrer OpenClaw-Version passen. Configs diffen und Integrations-Fixtures vor Gateway-Upgrade fahren.
Nützliches Mentalmodell: defaults deklariert Primary und allgemeine Fallbacks; modelRouting (je nach Version) führt kontextbasierte Aufteilung mit defaults aus; Fallbacks behandeln weiter Upstream-Fehler. In Staging drei Dinge prüfen: Routing soll auf gesunden Pfaden nicht wild zwischen Modellen springen (sonst zu enge Schwellen); Fallbacks nach Routing verhalten sich noch; Logs trennen Route-Treffer von Fehler-Tausch.
Bei Remote-Compute ist Gateway auf Linux-VPS oder Containern, schwere Toolchains oder nur-macOS-Schritte laufen oft über eine Queue zu dedizierten Remote-Mac-Executors. modelRouting staffelt nur Inferenz im Gateway—kein Ersatz für maschinenübergreifendes Scheduling (bleibt Queue/Runner-Thema).
Bei Multi-Tenant-Agenten auf einem Gateway: eigene Routing-Profile oder Keys pro Mandant—sonst hebt eine schwere Mandanten-Kontextschätzung die Leitplanke für alle.
Warnung: Behandeln Sie fallbackOnOverflow als „Kontext passt nicht ins Modell“, nicht als „Geld sparen“-Regler—Missbrauch lädt zu stiller Kürzung oder versteckten Retries ein.
Nutzen Sie dies für schnelles On-Call-Routing; weichen geschätzte Tokens und Provider-Rechnungen stark ab, prüfen Sie ob Tool-Ausgaben aus der Schätzung fallen oder Logs weggesampelt werden.
fallbackOnOverflow-Semantik neu validieren.Gateway auf Wegwerf-Laptop oder Host ohne Kapazitätsgarantien zerstört p95 selbst bei perfektem Routing; ohne exklusive, dauerhaft verfügbare, vertraglich absicherbare macOS-Ausführungsebene wehren sich Toolchains und lokale Builds gegen Automatisierung. Teams, die OpenClaw neben iOS/macOS-Builds, CI oder Agenten unter einem langfristigen Produktions-SLO brauchen, stabilisieren schneller, indem sie schwere Ausführung auf dedizierte Remote-Mac-Knoten legen statt dauerhaft Wegwerfumgebungen. Im Spannungsfeld Routing-Politik und Executor-Ökonomie passt NodeMini Mac Mini Cloud-Miete als Basis: Inferenz im Gateway mit modelRouting staffeln, schwere Toolchains auf dedizierte Knoten legen, Keys und Kapazität in Runbooks festhalten.
modelRouting staffelt vor dem Upstream-Aufruf nach geschätztem Kontext für Kosten und Latenz; Fallbacks reagieren meist auf Fehler. Beides kann koexistieren—Grenzen definieren. Weitere OpenClaw-Beiträge über den Kategoriefilter.
Echte Transkripte mit Fixtures in Staging abspielen, Route-Treffer prüfen, dann Canary mit Token- und Latenz-Perzentilen. Bei Parallelbedarf Kapazität über die Preisseite für Remote-Mac-Executor-Knoten ausrichten.
Diese behandeln Daemons und Exposure; dieser Artikel Routing im Gateway. Deployment stabilisieren, dann openclaw.json straffen. Für Konnektivität und Berechtigungen siehe das Hilfezentrum.