2026-04-27 OpenClaw, HTTP 429/503 amont LLM, budgets de retry et façonnage des requêtes par organisation sur Mac cloud headless loué (HK / JP / KR / SG / US)

Lorsque OpenClaw tourne 24/7 sur un Mac mini M4 loué visible seulement en SSH ou parfois VNC, les symptômes de « rate limit » ressemblent le plus souvent à un modèle cassé : réponses qui hésitent, appels d outils qui échouent au milieu d une trace, questions sur la rotation de clé API. En réalité, les HTTP 429 et HTTP 503 sur le chemin sortant vers le fournisseur LLM sont une classe d incident différente d un 429 que vous émettez vous-même depuis nginx sur le bord webhook entrant, et encore différents d une route morte dans le travail egress / DNS / TLS. Ce guide du 2026-04-27 vise les SRE et staff engineers qui veulent une séparation répétable entre notre abus des quotas et leur dégradation de service, avec des défauts de backoff numériques, un budget de retry par organisation que la passerelle ne peut dépasser sans pager, et des champs de log indexables par votre logging JSON structuré. Si le même nœud compile avec Xcode, lisez multi-version Xcode et DEVELOPER_DIR pour arbitrer CPU et réseau.

Deux surfaces « 429 » : votre nginx vs leur passerelle API

Les jours bruyants—grosses sorties modèle, pannes régionales, script démo marketing qui lance 40 skills concurrents—il est facile de confondre : (A) webhook entrant volontairement limité, (B) 429/503 amont, (C) 401/403 par clé erronée ou expirée. Triage pratique : IP source dans les logs (loopback processus 127.0.0.1:18789 vs bord public), user-agent ou tag bibliothèque renvoyé par le fournisseur, et si retry-after vaut quelques secondes ou des minutes. Les opérateurs 2026-04-27 à Hong Kong et Tokyo voient souvent un proxy d entreprise 429 une rafale tandis que le vendeur modèle est sain, ou l inverse. Étiquetez chaque ligne edge=inbound|outbound dans votre schéma de logs.

Évitez de superposer inbound et outbound sur le même panneau sans légende : un pic sur un bord peut ressembler à une régression globale de la passerelle.

HTTP 401/403 vs 429 vs 503/529 : posture différente

Statut	Sens pratique	Posture opérateur
401 / 403	Identifiants, allow-list ou mismatch org — souvent immédiat jusqu au changement de config	Arrêter le retry auto après 0–1 sonde ; vérifier rotation de clé et secrets launchd.
429	Throttle côté fournisseur ou seau tokens / requêtes atteint	Backoff avec jitter ; réduire le travail en vol avant d incriminer « les bugs OpenClaw ».
503 / 529	Région ou pool surchargé ou indisponible	Premier délai court, moins de tentatives max, routage vers modèle secondaire si politique OK (triage allowlist).

Restez honnêtes sur les clients HTTP internes : une boucle qui retry toujours 401 peut verrouiller un compte via heuristiques côté fournisseur. Une boucle sans backoff sur 503 transforme un glitch vendeur en auto-DDoS depuis une passerelle sur Mac au NIC 10 Gbps capable de parallélisme excessif.

Concurrence, fenêtres de tokens, budgets au niveau org

La plupart des tickets « rate-limités » sont de l auto-infligé : un schedule type cron depuis tâches launchd qui chevauche une rafale d invocations Discord ou Slack, chacune spawnant des HTTP parallèles, chacune plus large qu un humain ne taperait. Corrigez d abord la forme du trafic :

• Plafonner les tours avec outils simultanés à une valeur inscrite dans la politique, par ex. 4 requêtes HTTP amont en vol par processus passerelle.
• Dimensionner des plafonds journaliers de tokens par organisation en termes métier (support vs marketing vs R&D), pas seulement un MAX_TOKENS global dans un JSON.
• Décaler les jobs planifiés pour éviter les empilements sur les heures UTC pleines quand US et UE se croisent dans les régions SG et JP.

La équité entre orgs doit être mesurable (tokens, requêtes), pas seulement subjective (« qui crie le plus fort »).

Jitter, plafond exponentiel, budget temps mur

Adoptez une politique écrite que l astreinte peut coller dans un ticket :

• Premier retry 429 après 0,4–1,2 s de jitter, pas une boucle chaude à 0 s.
• Plafond exponentiel 32–64 s entre tentatives — au-delà, escalade humaine même si le vendeur dit « revenez dans deux minutes ».
• Arrêt dur du job après 180 s d attente de retry cumulée pour des tours de chat visibles utilisateur, sinon la passerelle paraît « gelée » et les canaux se spamment, créant une autre couche 429.

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

Runbook : six étapes quand les graphiques jaunissent

1. Geler les releases du paquet openclaw sauf rollback ; changements config-only OK si revus en 2 minutes sous règles incident.
2. Classifier le bord via le label inbound/outbound ; si 429 sortant, snapshot concurrence et limites par org depuis la config live en masquant les secrets.
3. Réduire l échelle : couper les exécuteurs d outils parallèles de 50 % ; si la latence p95 s améliore, vous étiez en famine de file, pas sous-dimensionnés.
4. Comparer aux baselines egress et DNS : si les erreurs TLS montent dans la même fenêtre, vous classez peut-être des échecs transport comme 503.
5. Relancer openclaw doctor dans l environnement du démon, selon le runbook doctor / allowlist, pour attraper env périmé ou allowlist qui imite un throttle.
6. Post-mortem le trio : (1) pic in-flight, (2) % 429, (3) médiane tokens par appel — si (3) saute, régression de prompt, pas faute du fournisseur.

Ce qu il faut logger pour une requête Grafana / Loki

Émettez au minimum : ts, provider, route (completions vs embeddings), attempt, status, request_id si retourné, ms. Ajoutez org et surface (chat vs run headless) pour séparer SLO visibles client et travail batch. Prolongez les probes readiness existantes ; une petite complétion canari basse QPS en fenêtre de maintenance reste acceptable si la ligne tokens est pré-approuvée. Croisez avec upgrades npm : un bug HTTP Node peut ressembler à des 5xx aléatoires si les versions divergent entre processus.

FAQ : throttles, équité, confiance opérationnelle

Question	Réponse courte
Acheter plus de quota API est-il le fix par défaut ?	Parfois pour une croissance soutenue, mais façonnez d abord le trafic — un for-each parallèle mal configuré dans une skill peut brûler un quota neuf en heures.
Faut-il un second Mac physique in-region ?	Si le CPU est bas mais le HTTP saturé, un second nœud bat souvent une dépense vendeur plus large — voir offres régionales et séparez orgs ou environnements.

Runbooks liés sur le même nœud headless

Associez à egress DNS/TLS (vérité transport), webhooks entrants (un autre 429), et triage sous-agents canaux quand le symptôme est « coincé sur Discord », pas un HTTP 429 littéral. Pour le câblage stable des secrets : launchd et clés API.

Pourquoi le Mac mini M4 à HK / JP / KR / SG / US pour du trafic modèle en rafales

OpenClaw mélange CPU en rafales (orchestration d outils, embeddings locaux occasionnels) et usage toute la journée du NIC (HTTP/2 streaming, TLS répétés, heartbeats ponts). Un Mac mini M4 physique garde ces charges sur une pile prévisible : pas d hyperviseur qui ment sur la qualité des timers pour les algorithmes de backoff, et assez de mémoire unifiée pour des buffers de logs JSON verbeux sans les flaps OOM des petites slices Linux 8 Go. Colocaliser la passerelle avec votre QA mobile et la flotte Xcode simplifie contrat fournisseur pour SSH, disque et heures de support — simplifiez d abord, puis scalez à deux nœuds avec preuves.