2026-04-27 OpenClaw, upstream LLM HTTP 429/503, Retry-Budgets und Request-Shaping pro Organisation auf gemietetem headless Cloud-Mac (HK / JP / KR / SG / US)

Wenn OpenClaw 24/7 auf einem gemieteten Mac mini M4 läuft, den Sie nur per SSH oder gelegentlich VNC sehen, wirken die lautesten «Rate-Limit»-Symptome wie ein kaputtes Modell: Antworten stottern, Tool-Calls brechen mitten in der Trace, jemand fragt nach rotierter API-Key. Tatsächlich sind HTTP 429 und HTTP 503 auf dem ausgehenden LLM-Provider-Pfad eine andere Incident-Klasse als ein 429, den Sie selbst mit nginx am Inbound-Webhook ausgeben, und wieder anders als tote Routen im Egress-/DNS-/TLS-Resilienz-Work. Dieser Leitfaden 2026-04-27 richtet sich an SREs: wiederholbare Trennung von unserem Quotenmissbrauch vs. deren Degradation, numerische Backoff-Defaults, org-weites Retry-Budget ohne Paging-Überschreitung, Log-Felder für strukturiertes JSON-Logging. Derselbe Knoten baut mit Xcode? Siehe mehrere Xcode und DEVELOPER_DIR.

Zwei «429»-Flächen: euer nginx vs. deren API-Gateway

An lauten Tagen—große Modell-Releases, Regionalausfälle, Marketing-Demo mit 40 parallelen Skills—vermischen sich leicht: (A) absichtlich gedrosselter Inbound-Webhook, (B) Upstream 429/503, (C) 401/403 durch falschen oder abgelaufenen Credential. Praktisches Triage: Quell-IP (Loopback 127.0.0.1:18789 vs. Public Edge), User-Agent oder Library-Tag vom Provider, ob retry-after Sekunden oder Minuten bedeutet. Betreiber in Hongkong und Tokio sehen oft Firmenproxy-429 bei Bursts, während der Modellanbieter gesund ist—oder umgekehrt. Taggen Sie edge=inbound|outbound im Log-Schema.

Trennen Sie Inbound- und Outbound-Zeitreihen in Dashboards, sonst wirkt ein Spike auf einer Kante wie Gesamtregression.

401/403 vs. 429 vs. 503/529: unterschiedliche Reaktion

Status	Praxisbedeutung	Default-Haltung
401 / 403	Credential, Allow-List oder Org-Mismatch—oft deterministisch bis Config-Wechsel	Auto-Retry nach 0–1 Sonde stoppen; Keys und launchd-Secrets prüfen.
429	Provider-Throttle oder Token-/Request-Bucket	Backoff mit Jitter; Inflight reduzieren bevor «OpenClaw-Bugs» beschuldigt werden.
503 / 529	Überlastete Region oder Pool	Kürzerer erster Delay, weniger max. Versuche, ggf. sekundäres Modell (Allowlist-Triage).

Naive Clients, die 401 immer retryen, können Konten sperren. Endlosschleifen ohne Backoff auf 503 verwandeln kleine Provider-Glitches in Self-DDoS von einem Mac mit 10-Gbps-NIC.

Parallelität, Token-Fenster, Org-Budgets

Die meisten «wir wurden rate-limited»-Tickets sind selbst verursachte Parallelität: Cron aus launchd kollidiert mit Discord- oder Slack-Tool-Bursts. Zuerst die Verkehrsform korrigieren:

• Gleichzeitige Tool-Turns pro Gateway-Prozess deckeln, z. B. 4 ausgehende HTTP-Requests in flight.
• Tages-Token-Obergrenzen pro Organisation in Geschäftsbegriffen (Support, Marketing, R&D), nicht nur globales MAX_TOKENS.
• Geplante Jobs verschieben, damit UTC-Vollstunden nicht US+EU mit SG/JP überlagern.

Jitter, exponentielles Cap, Wandzeit-Budget

• Erster 429-Retry nach 0,4–1,2 s Jitter.
• Exponentielles Cap 32–64 s zwischen Versuchen; längere Lücken eskalieren Menschen.
• Harter Stopp nach 180 s kumulativer Retry-Wartezeit für sichtbare Chat-Turns.

sleep $((2 + RANDOM % 3)) curl -sS -D - "https://api.example/v1/health" -o /dev/null | head -n1

Runbook: sechs Schritte bei gelben Charts

1. Releases einfrieren für openclaw außer Rollback; Config-Only mit 2-Min-Review ok.
2. Kante klassifizieren per inbound/outbound-Label; bei outbound 429 Live-Config-Snapshot (Secrets redacted).
3. Herunterskalieren: parallele Tool-Runner 50 %; wenn p95 sinkt, wartet die Queue—nicht zu wenig CPU.
4. Mit Egress/DNS-Baselines vergleichen: gleichzeitig steigende TLS-Fehler können als 503 klassifiziert werden.
5. openclaw doctor im Daemon-Env, Doctor/Allowlist.
6. Postmortem-Trio: Peak in-flight, 429-%, Median Tokens pro Call.

Logging für eine Grafana/Loki-Query

Mindestens ts, provider, route, attempt, status, request_id, ms; optional org, surface. Erweitert Readiness-Probes. Korreliert mit npm-Upgrades.

Ergänzend lohnt sich ein Feld retry_budget_remaining oder ein einfacher Zähler pro Org, der vor jedem erneuten Versuch dekrementiert wird—so sehen Sie in einem Trace sofort, ob ein Job «noch Luft» hatte oder gegen eine interne Obergrenze gelaufen ist. Wenn Ihr Provider request_id oder x-request-id zurückgibt, speichern Sie es unverändert; Support-Tickets ohne diese IDs werden oft erst Tage später beantwortet. Für lange Nächte: exportieren Sie bei Incidents einen 15-Minuten-Logausschnitt vor dem ersten Spike, nicht nur danach—sonst fehlt der Beweis, welche Konfigurationsänderung oder welches Deployment den Druck ausgelöst hat.

Trennen Sie in Metriken strikt Client-Fehler (4xx, die Sie nach Backoff-Policy nicht erneut senden sollten) von Server-Fehlern (5xx), auch wenn Ihr HTTP-Client beides im selben Counter landet. Operations-Teams verwechseln sonst «wir haben zu aggressiv retryt» mit «der Anbieter brannte zusammen». Auf einem headless Mac ohne GUI ist diese Klarheit noch wichtiger, weil niemand «nebenbei» im Browser die Vendor-Statusseite offen hat.

Ein kurzer wöchentlicher «Canary»-Aufruf mit minimalem Token-Budget—nach Freigabe durch FinOps—deckt regressions in Routing oder DNS auf, bevor echte Nutzer sie spüren. Halten Sie die QPS absichtlich niedrig; der Zweck ist Signal, nicht Lasttest.

FAQ

Frage	Kurzantwort
Standard-Fix «mehr API-Kontingent kaufen»?	Manchmal bei Wachstum, aber zuerst Traffic formen—falsch konfigurierte parallele Skills verbrennen neues Kontingent in Stunden.
Zweiter physischer Mac in-Region?	Bei niedrigem CPU aber HTTP-Sättigung oft günstiger als größerer Vendor-Spend—regionale Pläne.

Verwandte Runbooks

Egress DNS/TLS, Inbound-Webhooks, Subagent-Kanäle, launchd API-Keys.

Warum Mac mini M4 für bursty Modell-Traffic

OpenClaw mischt Burst-CPU (Orchestrierung von Tools, gelegentlich lokale Embeddings) mit ganztägigem NIC (HTTP/2, TLS, Heartbeats). Ein physischer Mac mini M4 liefert ehrliche Timer für Backoff und genug unified memory für große JSON-Logs ohne ständige OOM-Zyklen kleiner Linux-Container. Wenn derselbe Host zusätzlich Xcode-Indexer oder Simulator-Last sieht, verschieben Sie schwere Batch-Jobs in Zeitfenster mit niedriger interaktiver Nachfrage—nicht weil der Rechner «zu schwach» ist, sondern weil Fairness zwischen Menschen (Chat) und Automatisierung (Cron) sonst kollidiert.

Colocation mit Mobile-QA und der Xcode-Farm vereinfacht Anbieterbeziehung für SSH, Festplatten- und Support-SLA: ein Ansprechpartner, eine Rechnung, klare Eskalationspfade in Hongkong, Tokio, Seoul, Singapur oder den USA. Skalieren Sie erst, wenn Grafana zeigt, dass p95-Latenzen nach Reduktion der Parallelität nicht besser werden—dann fehlt wirklich Kapazität, nicht Disziplin.