2026 OpenClaw Multi-Modell-Routing & Degradationsketten: Kanal-/Aufgaben-Umschaltung, 429 vs. Timeout-Fail-over auf ZoneMac-Remote-Physisch-Mac (openclaw.json + FAQ)

2. Schmerzpunkte

1. Limits hinter „ein Modell für alle“. Ein teures Modell für alle Kanäle macht Spitzen-429s zur Totalausfallzeit; interaktiv vs. Batch sowie intern vs. extern brauchen verschiedene Profile und Parallelitätsbudgets.
2. Versteckte Kosten, wenn 429 und Timeouts vermischt werden. 429 braucht Retry-After und Kontingent-Respekt; Lese-Timeouts oder TLS-Fehler passen zu Fallback-Sprüngen oder höheren Stream-Idle-Limits—eine generische „dreimal wiederholen“-Politik verlangsamt die Warteschlange und verschleiert die Ursache.
3. Stabilität und Nachvollziehbarkeit der Konfiguration. Am Remote-Physisch-Mac können unreviewte Änderungen an openclaw.json das Standardprofil zerstören oder die Fallback-Reihenfolge aus dem Finanz-Kostenmodell reißen. Profile benennen, Primär/Sekundär dokumentieren und Verantwortliche im Runbook festlegen.

3. Entscheidungsmatrix: Dimension × Strategie

Vor dem Rollout abzeichnen; links die verführerische Abkürzung, rechts ein sinnvoller Baseline-Wert.

4. Reproduzierbare openclaw.json-Fragmente

Folgendes ist eine illustrative Struktur: Schlüssel müssen zur OpenClaw-Version passen; in eine bestehende Datei mergen ohne produktionsspezifische Pfade (Kanäle, Credential-Referenzen) zu überschreiben—immer Backup behalten.

4.1 Router-Profile, Kanäle und Aufgaben-Tags

{
  "gateway": {
    "router": {
      "defaultProfile": "balanced",
      "profiles": {
        "fast": {
          "primaryModel": "gpt-4o-mini",
          "fallbackChain": ["claude-3-5-haiku", "local-qwen-14b"]
        },
        "balanced": {
          "primaryModel": "gpt-4.1",
          "fallbackChain": ["gpt-4o", "gpt-4o-mini"]
        },
        "quality": {
          "primaryModel": "gpt-4.1",
          "fallbackChain": ["claude-3-5-sonnet", "gpt-4o"]
        }
      },
      "routeByChannel": {
        "telegram": { "profile": "fast" },
        "slack_public": { "profile": "balanced" },
        "api_internal": { "profile": "quality" }
      },
      "routeByTaskTag": {
        "ci": { "profile": "fast" },
        "support": { "profile": "quality" },
        "ops_summary": { "profile": "balanced" }
      }
    }
  }
}

4.2 Upstream-Retries, 429 und Timeouts

{
  "gateway": {
    "upstream": {
      "http": {
        "maxRetries": 4,
        "retryOnStatus": [408, 409, 425, 429, 500, 502, 503, 504],
        "respectRetryAfter": true,
        "backoff": { "baseMs": 400, "maxMs": 8000, "jitter": 0.2 }
      },
      "circuitBreaker": {
        "errorRateThreshold": 0.35,
        "minSampleSize": 40,
        "openDurationMs": 60000
      },
      "timeouts": {
        "connectMs": 8000,
        "requestMs": 180000,
        "streamIdleMs": 240000
      },
      "failover": {
        "onTimeout": "nextInFallbackChain",
        "on429": "retryWithBackoffThenFallback",
        "maxFallbackHops": 3
      }
    }
  }
}

streamIdleMs deckt lange Lücken zwischen Tokens im Streaming; getrennte Blöcke für on429 und onTimeout ermöglichen getrennte SLOs in Logs und Dashboards—passende Zähler nach Prometheus oder Grafana exportieren und Fallback-Tiefe vs. 429-Rate getrennt alarmieren.

5. Sieben-Schritte-Runbook (Remote-Physisch-Mac)

1. Verkehrsdimensionen einfrieren. Mit Produkt und Ops Kanal-IDs und Aufgaben-Tag-Enums abstimmen; unbenannte Defaults entfernen, damit nicht still balanced greift.
2. JSON sichern. cp openclaw.json openclaw.json.bak.$(date +%Y%m%d%H%M); Diff am Ticket anhängen.
3. Router-Blöcke mergen. Zuerst profiles und fallbackChain, dann routeByChannel / routeByTaskTag.
4. Lokaler Golden Request. Pro Profil festes curl (oder kleines SDK-Skript) gegen 127.0.0.1, Modell-ID und Latenz notieren.
5. Zwei Fehlerklassen injizieren. Mit Mock oder Drosselung 429 erzeugen und getrennt Time-to-first-Byte strecken; 429 soll backoffen ohne die ganze Kette in drei Versuchen zu verbraten, Timeouts die Kette entlang gehen.
6. Observability verdrahten. Mindestens exportieren: Requests pro Profil, 429-Rate, Verteilung der Fallback-Tiefe, Lese-Timeout-Rate—Panel-Schwellen an Ihr Prometheus/Grafana-Runbook koppeln.
7. Archivieren und reviewen. JSON-Fragmente, Golden-Befehle und Rollback (bak + Reload) neben interner Doku einchecken.

6. Triage: 429 vs. Timeout-Fail-over

7. Zitierfähige Kennzahlen (für Runbooks)

• Backoff-Start: baseMs: 400 und maxMs: 8000 als erste Größenordnung für 429; mit kommerziellen QPS-Obergrenzen abstimmen.
• Stream-Idle: streamIdleMs: 240000 (vier Minuten) für lange Antworten; kürzere Werte für schnellen Chat.
• Fallback-Obergrenze: maxFallbackHops: 3 verhindert Latenz-Explosionen; danach explizite Fehlerlast und Eskalation.

8. FAQ

9. Fazit und Knotenwahl

Multi-Modell-Routing hebt Kosten, Latenz und Verfügbarkeit aus der Ad-hoc-Feuerwehr in einen auditierbaren Vertrag: Kanäle und Aufgaben wählen Profile, 429 und Timeouts haben unterschiedliche Fail-over-Semantik, und geordnete Ketten liefern ein deterministisches letztes Mittel, wenn Upstream schwanken.

Das Gateway auf einem ZoneMac-Remote-Physisch-Mac zu betreiben verankert diesen Pfad auf einem langlebigen, gering-jitter Unix-Host: natives Terminal und SSH, launchd-Aufsicht und Ausrichtung mit der macOS-Toolchain reduzieren Umgebungsdrift, die sich als rätselhafte Timeouts äußert. Apple-Silicon-Unified Memory macht ein lokales Backup-Kleinmodell auf der Kiste praktischer. Ein Mac mini M4—mit rund 4 W Leerlauf, leisem Betrieb und stabilem macOS—eignet sich stark für 7×24-Gateway-Footprint; Gatekeeper und SIP erleichtern zudem den Betrieb exponierter Dienste.

Wenn Sie diesen Routing-Stack auf vorhersehbarer Hardware mit minimalem Ops-Aufwand betreiben wollen, ist der Mac mini M4 einer der besten Preis-Leistungs-Einstiege—holen Sie sich einen Remote-Physisch-Mac über ZoneMac und landen Sie Multi-Modell-Verkehr auf reproduzierbarer Gateway-Konfiguration.