openclaw models · files ordonnées · observabilité · checklist console sur Mac distant
Sur OpenClaw v2026, le passage à un routage multi-modèles ne se résume pas à une liste de noms dans openclaw models : il engage une politique de résilience (files de secours ordonnées), une comptabilité des coûts (jetons, appels, sauts de fallback) et une lecture honnête des erreurs lorsque la passerelle renvoie HTTP 429 ou d’autres signaux de saturation. Ce guide relie ces briques à l’observabilité Gateway — histogrammes par modèle, taux d’échec, latence jusqu’au premier paquet utile — puis propose une checklist console en session graphique sur Mac distant, parce que le même binaire peut sembler sain en SSH et échouer sur le bureau à cause du trousseau, du navigateur ou des autorisations macOS. Pour cadrer le multicanal et les garde-fous Gateway, ouvrez la checklist multicanal v2026.4.12 ; pour les mises à jour récentes et le doctor, v2026.4.5 : mise à jour, breaking et doctor ; quand la session semble « muette », croisez avec sans réponse : heartbeat et journaux. Les symptômes d’outillage local se traitent avec échec d’outil, codes de sortie et permissions, tandis que la gouvernance du contexte et du retrieval complète le tableau dans mémoire vérifiable : Palace et imports.
La surface openclaw models regroupe typiquement un modèle primaire pour la qualité attendue sur les tâches ouvertes, un ou plusieurs modèles de secours pour la disponibilité, et parfois un modèle économique pour les lots batch ou les résumés mécaniques. L’erreur classique consiste à empiler des identifiants sans documenter qui décide du saut, sur quels codes d’erreur, et combien de tentatives sont autorisées avant d’abandonner proprement. Une politique lisible commence par trois invariants : ordre stable (la file ne doit pas être réordonnancée implicitement à chaud), critères explicites (timeout réseau, 429, 5xx, refus de contenu) et bornes de coût (plafond de sauts, plafond de jetons cumulés sur la chaîne). Sans ces trois lignes, les journaux affichent une succession de modèles sans que l’équipe puisse expliquer si le comportement relève d’une règle métier ou d’un bug de configuration.
Le routage interagit avec la charge contextuelle : un prompt volumineux consomme plus vite les quotas du premier modèle et déclenche plus tôt le fallback, ce qui peut donner l’illusion d’une « préférence » pour le second modèle alors que la cause est purement arithmétique de fenêtre. D’où l’intérêt de corréler chaque série de sauts avec la taille des messages et le nombre d’outils invoqués, plutôt que de réécrire la persona. Les imports et le retrieval, traités dans l’article sur Palace et les imports, peuvent gonfler silencieusement le contexte et pousser le routeur vers des chemins plus coûteux sans message d’erreur explicite.
Sur un Mac distant, vérifiez que la configuration effective est bien celle du compte utilisateur qui porte le Gateway : chemins homonymes, copies de dépôt et variables d’environnement divergentes sont fréquents lorsque plusieurs expérimentations cohabitent. La console graphique aide à confirmer quel fichier est lu, quelle version d’OpenClaw tourne, et si des outils graphiques complètent la chaîne. Pour les canaux multiples et la manière dont le Gateway agrège les flux, la lecture détaillée se fait dans la checklist multicanal v2026.4.12, complément direct de cette section lorsque Telegram, le web et d’autres surfaces se superposent.
Inventaire : listez chaque modèle avec rôle (primaire, secours, économie), fournisseur, et contraintes contractuelles (région, fin de vie annoncée).
Règles de saut : associez chaque type d’échec à au plus un saut suivant ; évitez les boucles A→B→A masquées par des timeouts différents.
Garde-fous coût : fixez un plafond de jetons par requête multi-tentatives et un plafond de sauts ; documentez l’exception temporaire s’il faut les lever.
Observabilité : exigez un identifiant de corrélation par requête utilisateur pour relier sauts, erreurs HTTP et traces d’outil.
Relecture post-déploiement : comparez deux fenêtres horaires avant et après changement de file ; ne validez pas sur un seul succès isolé.
Enfin, rappelez-vous que le multicanal amplifie les collisions de quotas : une rafale sur un canal peut saturer le même fournisseur utilisé par un autre. Le Gateway doit donc exposer des métriques par canal et par modèle, pas seulement un total global flatteur.
Un fallback ordonné est une file déterministe : lorsque le modèle d’indice i échoue selon une règle prévue, on tente i+1 jusqu’à épuisement ou succès. L’ordonnancement n’est pas neutre : mettre un modèle rapide mais capricieux avant un modèle stable peut réduire la latence médiane tout en augmentant la variance et le coût des retry. À l’inverse, un primaire conservateur peut masquer des problèmes réseau jusqu’à ce qu’une charge réelle les révèle en cascade. La bonne pratique consiste à simuler des échecs contrôlés (coupure DNS simulée, réponses 429 injectées en préproduction) et à mesurer durée totale, jetons consommés et taux de résolution au premier saut.
Le HTTP 429 « Too Many Requests » n’implique pas automatiquement une mauvaise configuration OpenClaw : il signale que le débit ou le quota côté fournisseur ou intermédiaire est dépassé. Les en-têtes de réponse, lorsqu’ils sont présents, indiquent parfois une fenêtre de réessai ; les ignorer et relancer immédiatement le même modèle aggrave la saturation et peut déclencher des bannissements temporaires plus longs. La stratégie saine combine backoff exponentiel avec jitter, translation vers le modèle suivant lorsque la politique l’autorise, et diminution de la concurrence en amont plutôt qu’une tempête de retry identiques. Sur passerelle, journalisez le corps minimal de l’erreur et le nom de la clé utilisée pour distinguer un quota « projet » d’un quota « utilisateur final ».
Les coûts se déclinent en plusieurs axes : coût direct (prix au million de jetons ou au appel), coût indirect (latence utilisateur, tickets support), et coût d’opportunité (capacité gaspillée sur des retries inutiles). Un tableau simple — avant / après changement de file — suffit souvent à convaincre : taux de succès au premier modèle, nombre moyen de sauts, jetons moyens par conversation résolue. Si le nombre de sauts augmente alors que le taux d’erreur réseau est stable, suspectez plutôt un contexte trop lourd ou un outil lent ; si les sauts corrèlent avec des pics d’erreurs 429, recentrez-vous sur quota et concurrence. Les journaux « sans réponse » et les heartbeats, abordés dans l’article sur l’absence de réponse, aident à ne pas confondre attente modèle et attente canal muette.
| Signal | Interprétation probable | Action prioritaire | Piège à éviter |
|---|---|---|---|
| 429 en rafale sur un seul modèle | Quota ou débit dépassé | Ralentir, backoff, réduire concurrence | Ajouter un modèle coûteux sans régler le débit |
| Sauts fréquents sans 429 | Timeouts, refus de contenu, instabilité outil | Isoler réseau et outils | Changer toute la file de modèles |
| Coût/jeton en hausse sans saut | Contexte ou retrieval plus lourd | Auditer Palace et imports | Accuser le fournisseur « en aveugle » |
| Succès mais latence élevée | Queueing côté Gateway ou charge CPU | Métriques files et CPU du nœud | Surdimensionner uniquement le modèle |
Les mises à jour peuvent modifier subtilement les chemins d’erreur ; après chaque upgrade, rejouez un jeu de scénarios documenté. Le guide v2026.4.5 rappelle comment le doctor et les correctifs breaking recadrent attentes et journaux : intégrez-le à votre check-list de release avant d’interpréter une régression de routage.
Le 429 est une mesure, pas une insulte : cadrez débit, backoff et file avant de toucher à la persona.
Sans métriques, le routage devient une opinion : chaque incident finit par une discussion sur « le modèle qui déraille » alors que la donnée manquante est souvent la latence jusqu’au premier paquet utile, le nombre de tentatives, ou la profondeur de file d’attente côté Gateway. Commencez par un socle minimal : taux de succès par modèle, taux d’erreur par famille (4xx, 5xx, timeout), durée par étape (authentification, normalisation prompt, appel amont, post-traitement), et coût estimé agrégé par conversation. Ajoutez ensuite des étiquettes : canal d’entrée, version d’OpenClaw, région, type d’outil dominant. Ce découpage permet d’attribuer une dérive à un déploiement plutôt qu’à un fournisseur.
Les histogrammes valent mieux que les moyennes seules : une moyenne flatteuse peut cacher une double population — requêtes courtes instantanées et requêtes longues bloquées derrière une file. Surveillez particulièrement la queue dwell time : lorsqu’elle croît alors que le taux d’erreur amont reste bas, le goulet est local au nœud (CPU, disque, verrous). Les métriques doivent aussi compter les abandons utilisateur : une conversation fermée pendant une attente prolongée n’apparaît pas comme erreur modèle mais dégrade l’expérience autant qu’un 500.
Reliez ces séries aux événements opérationnels : mises à jour, changements de clés API, bascules DNS, modifications de politique de secrets. Le multicanal décrit dans la checklist Gateway v2026.4.12 impose de séparer visuellement les séries par canal avant de fusionner les tableaux de bord ; sinon, un canal bruyant masque la dérive d’un canal critique. Pour les incidents où le modèle répond mais l’action locale échoue, croisez avec les codes de sortie et permissions d’outil afin de ne pas « soigner » le routage alors que le problème est filesystem ou sandbox macOS.
{
"gateway_metrics_min": [
"success_rate_by_model",
"error_rate_by_class",
"ttfb_ms_p50_p95",
"queue_dwell_ms",
"fallback_hops_avg",
"tool_failures_correlated"
],
"labels": ["channel","openclaw_version","region"]
}
Indication : gardez les noms de champs stables entre versions ; les ruptures de séries rendent les comparaisons « avant / après » illisibles exactement quand vous en avez le plus besoin.
Valider uniquement en SSH laisse des angles morts : le trousseau accessible à la session graphique, les certificats du navigateur embarqué, les autorisations « Confidentialité » pour capture d’écran ou accessibilité, et parfois le fuseau horaire des journaux diffèrent de ce que vous croyez lire dans un terminal détaché. La console VNC doit reproduire le même utilisateur que celui qui exécute le Gateway, sinon vous diagnostiquez un fantôme. Ouvrez la session graphique, connectez-vous, lancez le moniteur d’activité et le navigateur de service, puis rejouez une requête représentative en observant simultanément les métriques côté passerelle.
Première passe réseau : depuis la session graphique, vérifiez que les domaines du fournisseur modèle répondent sans proxy surprise, que les horodatages TLS sont valides, et qu’aucune extension ne réécrit les en-têtes. Deuxième passe identité et secrets : confirmez que la clé utilisée par le Gateway est bien celle attendue (pas une clé de compte de build présente dans le trousseau graphique). Troisième passe outils : si votre chaîne déclenche des binaires ou scripts, observez les codes de sortie et messages stderr dans la même session ; l’article sur les échecs d’outil donne la méthode pour séparer erreur d’outil et erreur modèle.
Quatrième passe concurrence : avec VNC, vous voyez les pics CPU synchrones aux rafales de requêtes ; si le processeur sature alors que le réseau est calme, la file Gateway ou un post-traitement local est suspect. Cinquième passe multicanal : ouvrez les clients réels (messagerie, webhooks) plutôt que des simulations curl isolées ; la checklist associée est dans v2026.4.12 multicanal. Sixième passe silence apparent : si rien ne revient, ne supposez ni mort du modèle ni corruption magique — suivez heartbeat et journaux sans réponse pour distinguer attente, blocage et erreur non surfacée.
| Vérification | Comment (session graphique) | Critère de réussite |
|---|---|---|
| Alignement utilisateur | Comparer nom de session, répertoire maison, variables visibles dans Terminal intégré. | Même UID que le service Gateway documenté. |
| Réseau et 429 | Onglet Réseau des outils développeur sur l’UI locale ; filtres sur endpoints modèle. | 429 rares, backoff visible, pas de tempête identique. |
| Doctor post-mise à jour | Exécuter openclaw doctor depuis Terminal graphique. | Aucun avertissement nouveau vs baseline documentée ; voir v2026.4.5. |
| Contexte et Palace | Comparer taille de retrieval et blocs visibles avec fichier disque. | Pas de divergence durable ; méthode dans Palace / imports. |
| Disque et RAM | Moniteur d’activité pendant charge. | Pas de swap pathologique ; espace libre confortable pour index et journaux. |
Terminez par une capture d’écran annotée et un extrait de métriques horodatées : cela accélère la relecture croisée entre équipes et évite les « ça marchait chez moi » lorsque « chez moi » n’était pas le même bureau que le nœud loué.
Les formulations suivantes sont volontairement copiables dans un outil de suivi ; remplacez les chiffres par vos mesures réelles. Elles incitent à joindre métriques et contexte utilisateur, deux éléments souvent absents lorsque seul le modèle est mis en cause.
Attention : si votre ticket mélange sans preuve « modèle faible » et « 429 », la revue technique renverra souvent le dossier pour mesures incomplètes — perdez une demi-journée ou documentez correctement dès l’ouverture.
Trois entrées pour approfondir le multicanal, le silence apparent et la mémoire contextuelle ; les deux autres références utiles figurent dans les sections ci-dessus et la FAQ.
Garde-fous, files et validation quand plusieurs surfaces alimentent la même passerelle.
Lire →Distinguer attente modèle, canal muet et erreur non affichée côté client.
Lire →Rendre le retrieval auditable et maîtriser le volume qui pousse les fallbacks.
Lire →Pas nécessairement. Un 429 traduit surtout un quota ou un débit atteint. Vérifiez les métriques Gateway par clé et modèle, appliquez backoff et réduisez la concurrence avant de réécrire la file. Croisez avec la checklist multicanal si plusieurs canaux tirent sur les mêmes ressources.
Si l’appel modèle réussit mais l’action locale échoue, priorisez codes de sortie et permissions. Si les erreurs précèdent l’amont modèle, recentrez-vous sur files, authentification et multicanal. La session VNC aide à reproduire ce que le service voit réellement.
Parce que trousseau, navigateur et autorisations macOS diffèrent souvent entre sessions. Le Gateway et les outils interactifs tournent dans le même contexte utilisateur que le bureau — à valider ainsi. Combinez avec doctor et notes de version après mise à jour.
Chaque saut peut coûter des jetons ou des appels. Mesurez taux de résolution au premier modèle, nombre moyen de sauts et coût marginal ; ajustez la politique plutôt que d’empiler des secours « au cas où ». Le volume contextuel décrit dans Palace et imports influence aussi la facture sans changer de modèle.
Le routage multi-modèles d’OpenClaw gagne en puissance lorsqu’il est traité comme un système distribué miniature : files, quotas, observabilité et validation utilisateur se tiennent ensemble. Les 429 et autres signaux de limitation demandent une hygiène de débit ; les fallbacks demandent une comptabilité ; le Mac distant demande une preuve graphique que le service voit le même monde que votre terminal SSH. En combinant les guides multicanal, sans réponse, mise à jour et doctor, échecs d’outil et mémoire et Palace, vous disposez d’un parcours de lecture cohérent du Gateway jusqu’au bureau macOS — sans angles morts inutiles.
Héberger soi-même un Mac haute performance implique veille matérielle, électricité et cycles de mise à jour ; un Mac cloud avec session VNC reproductible simplifie la validation graphique tout en vous laissant la politique de routage et les secrets sous contrôle documenté. Pour activer un nœud rapidement, rendez-vous sur Louer un Mac cloud ; pour comparer les offres, commencez par l’accueil du site.