Une fois le OpenClaw Gateway en place, la production demande souvent comment maîtriser coût et latence ensemble. Le modelRouting étagne le trafic avant l’appel amont selon la taille de contexte estimée au lieu de toujours payer le prix du modèle le plus haut. Ce guide explique quel problème il résout, comment il se place à côté de agents.defaults et des fallbacks dans openclaw.json, comment mapper les SLO vers des paliers maxTokens, et livre une checklist de déploiement en six étapes plus un diagnostic de mauvaise configuration—en complément des articles d’installation, systemd et Docker sur ce site.
En production, les requêtes OpenClaw emportent souvent prompts système, historique, sorties d’outils et morceaux RAG. Tout envoyer indéfiniment dans un seul modèle phare fait exploser factures et latence de queue ; ne compter que sur des fallbacks après échec signifie avoir déjà brûlé un énorme contexte avant de réaliser que le chemin était mauvais. Le modelRouting estime la taille en tokens du contexte avant l’inférence amont et choisit un palier pour que « les petites questions prennent par défaut de petits modèles »—pas après coup.
Six signaux de douleur fréquents—si plusieurs se cumulent, mettez le routage à l’ordre du jour de revue de config plutôt que de fixer Grafana :
Latence de queue : p95/p99 s’écartent de la moyenne au même QPS et suivent la longueur de conversation—les chemins à gros contexte sont sur-utilisés.
Dépenses non linéaires : trafic +30 %, facture +100 %—souvent « chaque session par défaut sur le plus gros modèle ».
Les appels d’outils gonflent le contexte : une sortie multi-sauts en un tour fait grimper les tokens, provoquant troncature silencieuse ou retries surprises.
Chaînes de fallback trop longues : l’utilisateur ne voit rien, mais vous enchaînez des modèles sur une requête—latence et coût s’empilent.
Pas d’observabilité du routage : vous ne loguez que le nom du modèle final, pas pourquoi ce palier—la triage devient du devinage.
Isolation multi-locataire faible : des sessions lourdes sur un Gateway partagé tirent les SLO des sessions légères—il faut un garde-fou par forme de contexte.
Après la série install/déploiement OpenClaw du site, vous avez déjà « processus vivant, ports/tunnels sains ». Cet article couvre la sélection de modèle dans ce même processus longue durée. Il est orthogonal à l’exécution distante (runners auto-hébergés ou Mac distants dédiés) : le routage choisit quel cerveau ; la couche exécuteur choisit quelle machine fait le travail.
Un mythe : le modelRouting serait « un autre équilibreur de charge ». C’est plutôt du routage par forme de contexte—estimer la taille, puis choisir un modèle—pas du round-robin aléatoire, sinon les traces paraissent malines et les factures restent honnêtes.
Ils ne s’excluent pas, mais séparez les rôles : les fallbacks conviennent à la sémantique d’échec—modèle indisponible, erreurs, limites de débit ; le modelRouting à la sémantique coût/latence—à quel point ce tour est lourd. Si vous les mélangez, vous obtenez « la route a pris le gros modèle, puis l’échec est retombé sur le petit »—payer deux fois le drame.
| Dimension | primary + fallbacks (classique) | modelRouting (paliers de contexte) |
|---|---|---|
| Déclencheur | Codes d’erreur, timeouts, échecs réessayables | Seuils de tokens de contexte estimés (ex. stratégie taille de contexte) |
| Gain principal | Disponibilité : secours depuis un mauvais modèle | Efficacité : les chats légers ne paient pas les prix phares |
| Risque typique | Longues chaînes gonflent la latence de queue et la double facturation | Mauvais seuils classifient mal lourd vs léger |
| Observabilité | Taux d’échec, retries, raison du basculement | Mix des hits de route, erreurs près des seuils, percentiles de tokens |
| agents.defaults | Déclarer primary + liste de fallback | Ajouter un bloc de routage sous defaults pour scinder avant l’appel |
Écrivez « échange sur échec » et « choix avant échec » sur deux pages distinctes—votre astreinte vous remerciera.
Journalisez les décisions de routage de façon structurée (palier touché, bande de tokens estimée, ID de modèle final) ; sinon la prod ne montre que le modèle final et vous ne pouvez pas revoir les seuils. Les six étapes ci-dessous en font une barrière de release.
Pour les ingénieurs qui savent déjà livrer des changements de config—chaque étape a un livrable pour que le modelRouting ne reste pas un griffonnage JSON ponctuel.
Figez le langage SLO : latence p95 cible, plafond de coût par session, part supposée de sessions « lourdes ». Pas de SLO, pas de seuils sérieux.
Échantillonnez les distributions de tokens : vrais chats et sorties d’outils—y compris les queues, pas seulement la longueur moyenne.
Esquissez trois paliers : IDs léger/moyen/lourd et tâches qui ne doivent jamais atterrir sur le palier léger (ex. outils multi-sauts).
Câblez modelRouting + télémétrie : hits, tokens estimés, modèle final vers logs structurés et votre pile métrique.
Canary contrôlé : double exécution ancien vs nouveau sur une tranche, surveillez percentiles coût et latence, puis promouvoir.
Interrupteur de rollback : gardez un instantané pour revenir à « defaults + courte chaîne de fallback » si le routage déraille.
{
"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
}
}
}
}
Note : Ceci montre la forme et la sémantique ; les vraies clés/valeurs par défaut doivent correspondre à votre version OpenClaw. Diffez les configs et lancez des fixtures d’intégration avant de mettre à jour le Gateway.
Modèle mental utile : defaults déclare le modèle primary et les fallbacks généraux ; le modelRouting (selon votre version) effectue un découpage par contexte en coopération avec defaults ; les fallbacks gèrent toujours les échecs amont. En staging, vérifiez trois choses : le routage ne doit pas faire osciller les modèles sur des chemins sains (sinon seuils trop serrés) ; les fallbacks après routage se comportent encore ; les logs séparent hits de route et échanges sur échec.
Avec du calcul distant, une topologie courante est Gateway sur VPS Linux ou conteneurs tandis que les grosses toolchains ou étapes macOS-only passent par une file vers des exécuteurs Mac distant dédié. Le modelRouting ne fait qu’étagner l’inférence dans le Gateway—il ne remplace pas l’ordonnancement inter-machines (toujours votre problème file/runner).
Pour des agents multi-locataires sur un Gateway, donnez des profils de routage ou des clés distincts par locataire—sinon l’estimation de contexte d’un locataire lourd remonte la ligne pour tout le monde.
Avertissement : Traitez fallbackOnOverflow comme « le contexte ne rentre pas dans le modèle », pas comme un levier « économiser »—une mauvaise utilisation invite troncature silencieuse ou retries cachés.
Utilisez ceci pour un routage d’astreinte rapide ; si les tokens estimés et les factures fournisseur divergent fortement, vérifiez si les sorties d’outils sont exclues de l’estimation ou si les logs sont échantillonnés.
fallbackOnOverflow.Faire tourner le Gateway sur un portable jetable ou un hôte sans garantie de capacité ruinera le p95 même avec un routage parfait ; sans plan d’exécution macOS exclusif, toujours disponible et contractuel, toolchains et builds locaux résistent à l’automatisation. Les équipes qui ont besoin d’OpenClaw avec builds iOS/macOS, CI ou agents sous un SLO de production durable se stabilisent souvent plus vite en plaçant l’exécution lourde sur des nœuds Mac distants dédiés plutôt que sur des environnements jetables permanents. Pour équilibrer politique de routage et économie des exécuteurs, la location cloud Mac Mini NodeMini sert de base : étagner l’inférence avec le modelRouting dans le Gateway, poser les grosses toolchains sur des nœuds dédiés, et encoder clés et capacité dans vos runbooks.
Le modelRouting étagne avant l’appel amont selon le contexte estimé pour le coût et la latence ; les fallbacks réagissent en général aux échecs. Ils peuvent coexister—définissez les frontières. Parcourez d’autres articles OpenClaw via le filtre catégorie.
Rejouez de vrais transcripts avec fixtures en staging, vérifiez les hits de route, puis canary en surveillant les percentiles tokens et latence. Pour le calcul parallèle, alignez la capacité via la page tarifaire pour les nœuds exécuteurs Mac distants.
Ces guides couvrent démons et exposition ; cet article couvre le routage dans le Gateway. Stabilisez le déploiement, puis resserrez openclaw.json. Pour connectivité et droits, voir le centre d’aide.