Plusieurs agents et modèles OpenClaw : routage, isolation et coût

Les agents multiples et les modèles multiples d’OpenClaw sont deux couches différentes d’un même fichier de configuration : plusieurs agents sont des entrées indexées sous agents.entries, chacun possédant son propre espace de travail, son répertoire d’état et son magasin de sessions, tandis que plusieurs modèles sont des valeurs model propres à chaque agent, à l’intérieur de ces entrées. Deux autres couches leur sont adjacentes — bindings détermine quel agent répond, et une chaîne de secours détermine ce qu’un agent fait lorsque son modèle échoue. Modifier la mauvaise couche est la raison la plus fréquente pour laquelle un changement semble ne rien faire.

Exécuter davantage d’agents ne coûte rien en logiciel. La vue d’ensemble de la documentation d’OpenClaw indique que le projet est développé ouvertement par « l’OpenClaw Foundation, une organisation indépendante 501(c)(3) », avec « aucun niveau payant, aucune télémétrie par défaut au-delà d’une vérification de version que vous pouvez désactiver, aucun laboratoire qui en est propriétaire », et openclaw.ai ajoute « Aucun abonnement. Aucun niveau hébergé. Aucun token. » Le paquet npm openclaw est sous licence MIT, avec latest à 2026.9.5 aux côtés d’un canal extended-stable à 2026.7.35 et de engines.node de >=24.16.0 <25 || >=26.1.0 (registre npm, vérifié le 21 septembre 2026). Ce qu’un deuxième agent ajoute à votre facture, ce sont des tokens.

Agents multiples OpenClaw : quatre couches et le symptôme lorsque vous modifiez la mauvaise

Les quatre éléments ont été consultés dans la documentation d’OpenClaw le 21 septembre 2026 : entries et multi-agent, liaisons d’agents et basculement de modèles. Deux structures des anciens tutoriels sont obsolètes : un registre sous forme de tableau agents.list est l’ancien format que Doctor migre, et un marqueur default: true sur une entrée a été retiré — la page des entrées indique clairement que « default est retiré » et que les opérations multi-agent nécessitent une liaison ou une cible explicite. OpenClaw a également porté deux noms antérieurs ; toute configuration datant de l’époque Moltbot ou Clawdbot est donc antérieure à ce schéma.

Configuration OpenClaw de plusieurs agents : configuration minimale à deux agents et deux modèles

Cet extrait suppose que vous disposez déjà d’un bloc models.providers fonctionnel — meilleure API pour OpenClaw contient celui de Kunavo, notamment api: "anthropic-messages" et l’URL de base publiée sous URL de base Anthropic. La suite ne concerne que la couche des agents et du routage.

{
  "agents": {
    "defaults": {
      "modelSelectionScope": "session",
      "model": {
        "primary": "kunavo/claude-haiku-4-5",
        "fallbacks": [
          "kunavo/claude-sonnet-5"
        ]
      }
    },
    "entries": {
      "ops": {
        "name": "Ops",
        "workspace": "~/.openclaw/workspace-ops",
        "agentDir": "~/.openclaw/agents/ops/agent",
        "model": "kunavo/claude-haiku-4-5",
        "modelPolicy": {
          "allow": [
            "kunavo/claude-haiku-4-5"
          ]
        }
      },
      "build": {
        "name": "Build",
        "workspace": "~/.openclaw/workspace-build",
        "agentDir": "~/.openclaw/agents/build/agent",
        "model": {
          "primary": "kunavo/claude-opus-5",
          "fallbacks": [
            "kunavo/claude-sonnet-5"
          ]
        },
        "utilityModel": "kunavo/claude-haiku-4-5"
      }
    }
  },
  "bindings": [
    {
      "agentId": "build",
      "match": {
        "channel": "discord",
        "accountId": "build"
      }
    },
    {
      "agentId": "ops",
      "match": {
        "channel": "discord",
        "accountId": "*"
      }
    }
  ]
}

Quatre éléments de ce bloc sont essentiels. Chaque agent possède son propre agentDir, car la page consacrée au multi-agent avertit : « Ne réutilisez jamais agentDir entre plusieurs agents — cela provoque des collisions d’état d’authentification/de session. » L’agent ops utilise la forme chaîne de model, que la page des entrées définit comme « un modèle principal strict par agent, sans modèle de secours » : une défaillance est donc signalée au lieu de déplacer silencieusement le travail courant vers un niveau plus coûteux. L’agent build utilise la forme objet avec une liste fallbacks explicite, ce qui permet d’autoriser le basculement d’un agent ; la page sur le basculement ajoute qu’un agent peut définir uniquement model: { fallbacks: [...] } et continuer à hériter du modèle principal partagé. Enfin, la liaison précise est placée au-dessus du caractère générique, car au sein d’un même niveau de correspondance, « la première entrée bindings correspondante l’emporte ».

Les valeurs par défaut de l’espace de travail diffèrent entre l’agent par défaut et les autres, et méritent d’être définies explicitement : l’espace de travail de l’agent par défaut est <stateDir>/workspace, tandis que celui des autres agents est par défaut <stateDir>/workspace-<agentId>. La mémoire suit l’espace de travail, puisque le moteur intégré d’OpenClaw « mémorise les éléments en écrivant des fichiers Markdown ordinaires dans l’espace de travail de votre agent » — isoler les espaces de travail est donc ce qui isole la mémoire. Les modes d’autorisation de session constituent encore un axe distinct : read-only, guarded, workspace et full, où « full nécessite operator.admin. Les autres modes nécessitent operator.write » (modes d’autorisation, 21 septembre 2026). Un modèle peu coûteux sur un agent permissif reste un agent permissif.

Ce que des agents distincts séparent — et ce qu’ils ne séparent pas

C’est la limite que les tableaux de prix ne montrent pas. Des entrées distinctes vous donnent des fichiers, une mémoire, un historique, une politique d’outils et des profils d’authentification stockés distincts. Elles ne vous donnent pas, à elles seules, une clé API propre à chaque agent pour un fournisseur personnalisé configuré par environnement — le schéma documenté par agent ne comporte aucun champ baseUrl, apiKey ou providers. L’absence dans la documentation ne prouve pas que le code l’interdit ; lisez donc ceci comme « non documenté ». Si vous avez besoin d’une séparation stricte des clés par locataire, exécutez des Gateways distinctes. Une limite connexe concerne l’identité : l’exemple de séparation des DM WhatsApp d’OpenClaw précise que « les réponses proviennent toujours du même numéro WhatsApp — il n’existe pas d’identité d’expéditeur par agent », et que « les discussions directes se regroupent par défaut sous la clé de session principale de l’agent ; une véritable isolation nécessite donc un agent par personne ». Cette phrase concerne WhatsApp ; consultez la page de votre propre canal avant de la généraliser.

Une limite de capacité à noter pendant que vous répartissez les rôles : Kunavo ne fournit aucun modèle de synthèse vocale, de reconnaissance vocale ou d’embedding ; un agent qui a besoin d’une sortie vocale ou d’un index vectoriel doit donc appeler un fournisseur externe pour cette étape.

Plusieurs modèles OpenClaw : comportement strict, secours, politique et voie utilitaire

La sélection du modèle par agent comporte quatre contrôles qu’il vaut la peine de définir délibérément. model sous forme de chaîne est strict. { primary, fallbacks: [...] } autorise cet agent à utiliser le basculement. modelPolicy.allow est une liste autorisée qui « remplace la politique par défaut pour cet agent » — en acceptant les alias, les références exactes et les caractères génériques finaux — ce qui permet d’empêcher un agent courant d’atteindre un modèle coûteux. Enfin, utilityModel est un modèle distinct, généralement moins cher, pour les « tâches internes courtes telles que les titres de session et de fil générés », avec une surcharge par agent.

La liste des déclencheurs documentés est précise. OpenClaw bascule en cas « d’échecs d’authentification, de limites de débit et d’épuisement des périodes de refroidissement, d’erreurs de surcharge ou de fournisseur occupé, d’erreurs de basculement ressemblant à des expirations de délai, de désactivations de facturation, model_not_found », ainsi qu’en cas d’autres erreurs non reconnues tant qu’il reste des candidats — mais pas en cas d’erreurs de dépassement de contexte, qui restent dans la logique de compactage et de nouvelle tentative, ni en cas « d’abandons explicites qui ne ressemblent ni à une expiration de délai ni à un basculement ». En dehors des conversations de groupe et de canal, le comportement est visible : ces surfaces publient une notification d’état de la forme Model Fallback: <fallback> (selected <primary>; <reason>) ainsi qu’une notification correspondante de rétablissement, tandis que les conversations de groupe et de canal « masquent les notifications visibles tout en conservant le même état de basculement » ; ne comptez donc pas sur le fait d’en voir une dans un salon partagé. Une sélection explicite de session — /model, le sélecteur de modèle, session_status(model=...) ou sessions.patch — est stricte : si ce modèle échoue avant de produire une réponse, OpenClaw signale l’échec au lieu de répondre avec un modèle de secours configuré. Le --model d’une tâche cron n’en fait pas partie ; la documentation le qualifie de modèle principal de la tâche, qui continue d’utiliser les modèles de secours configurés, sauf si la tâche définit payload.fallbacks: [].

Deux autres mécanismes déterminent si votre intention est conservée. Les paramètres de requête sont fusionnés sur quatre couches, de agents.defaults.params à agents.entries.*.params, les couches ultérieures remplaçant les valeurs par clé. Le parallélisme possède également un plafond calculé : agents.defaults.maxConcurrent vaut par défaut max(8, available CPU parallelism * 4) entre les sessions, tandis que chaque session reste sérialisée — deux messages adressés au même agent ne s’exécutent pas simultanément. Pour choisir le modèle adapté à chaque rôle, Opus vs Sonnet vs Haiku traite l’aspect des capacités.

Attribution des coûts par route, pas par agent

Puisqu’aucune commande documentée ne fournit les dépenses par agent, attribuez-les par route. Le calcul ci-dessous est illustratif, non une facture mesurée et non un plafond. Il suppose un mois de 30 jours, la valeur par défaut documentée du heartbeat 30m (1 440 exécutions), 300 tokens de sortie par heartbeat, aucun succès de cache, et une voie de conversation principale de 8 M de tokens d’entrée et 500 000 tokens de sortie. Les valeurs de contexte d’environ 100 000 et environ 2 000 à 5 000 par exécution sont l’illustration fournie par OpenClaw de ce que isolatedSession supprime, et non des mesures effectuées ici ; 3 000 est le point médian. Les tarifs sont les prix actuels du catalogue Kunavo par million de tokens.

Claude Haiku 4.5 indique $0.70 / $3.50 et Claude Opus 5 indique $3.50 / $17.50 par million de tokens d’entrée / de sortie dans le catalogue actuel. Ce qu’il faut retenir : dans ces hypothèses, la voie planifiée domine. Un heartbeat en session partagée sur le modèle puissant revient à $511.56 par mois, contre $4.54 pour la même cadence avec isolatedSession: true sur le modèle économique. OpenClaw le dit lui-même : « Les heartbeats exécutent des tours d’agent complets. Des intervalles plus courts consomment davantage de tokens », et cite isolatedSession, lightContext, un model moins cher et target: "none" comme leviers.

L’astuce du heartbeat économique possède un mode d’échec documenté, et c’est pourquoi isolatedSession est un meilleur levier que le simple changement de modèle. Les heartbeats « conservent le modèle d’exécution existant de la session partagée une fois l’exécution terminée » ; un heartbeat qui passe une session à un modèle plus petit peut donc le laisser actif pour le tour suivant de la session principale, qui peut alors signaler un dépassement de contexte — le message de récupération d’OpenClaw appelle cela la propagation du modèle du heartbeat. L’exemple détaillé de la documentation utilise un modèle local avec une fenêtre de 32k ; l’importance du risque dépend donc de la différence entre la fenêtre de contexte du modèle de heartbeat et celle requise par la session partagée. Une remarque sur la planification : l’intervalle par défaut documenté est 30m, porté à 1h uniquement lorsque le mode d’authentification résolu est OAuth/token Anthropic ; une route utilisant une simple clé API conserve 30m, sauf si vous définissez vous-même heartbeat.every. Vérifiez votre propre valeur avant d’établir votre budget.

Deux réserves concernant les montants en dollars. Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque le fournisseur en amont communique son montant, la facture correspond au plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Et un fournisseur personnalisé déclaré sans objet cost par modèle rend l’affichage propre à OpenClaw inutilisable : il utilise par défaut cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 }, affiche 0 $ alors que le fournisseur facture normalement. Déclarez cost, contextWindow et maxTokens pour chaque modèle ajouté, puis faites le rapprochement avec le relevé du fournisseur. Le montant minimal de recharge Kunavo est de $10 en crédit prépayé — un minimum de financement, pas des frais de tâche ni un abonnement. Consultez les détails de facturation et l’optimisation des coûts de l’IA.

Quelle voie d’achat convient à une Gateway multi-agent

Une remarque sur les dialectes, car le cache est l’endroit où se trouve l’économie. Le bloc Kunavo du guide associé déclare api: "anthropic-messages", qu’OpenClaw traite comme un endpoint Anthropic non direct. Deux conséquences documentées en découlent. Les en-têtes bêta Anthropic implicites sont supprimés sur ces endpoints ; les fonctionnalités comme le raisonnement entrelacé doivent donc être activées par un headers["anthropic-beta"] explicite plutôt qu’automatiquement. Et la mise en cache doit être demandée : OpenClaw initialise cacheRetention: "short" uniquement pour les fournisseurs directs anthropic et anthropic-vertex, tandis que les « endpoints personnalisés compatibles avec anthropic-messages » sont pris en charge « lorsque cacheRetention est défini explicitement » — définissez donc vous-même params.cacheRetention au lieu de supposer une valeur par défaut (mise en cache des prompts, 21 septembre 2026). Une règle distincte concerne l’autre dialecte : une route openai-completions vers un endpoint non natif n’envoie « aucun indice de cache de prompt ». Vérifiez l’utilisation du cache signalée sur votre propre route avant de budgéter le contexte récurrent comme des accès au cache. La mise en cache des prompts traite l’aspect tarifaire.

Vérifiez que l’application s’est faite au bon endroit

openclaw config validate
openclaw gateway restart
openclaw agents list --bindings
openclaw models status --agent ops --json --check
openclaw models list --agent build

La validation de la configuration vérifie la structure, et le redémarrage de la Gateway la recharge ; ni l’un ni l’autre ne prouve qu’une requête facturée a abouti. openclaw agents list --bindings affiche le routage effectivement chargé — préférez-le à --tree, qui apparaît dans les pages consacrées aux concepts mais pas dans le tableau des commandes CLI. openclaw models status --agent <id> explique la valeur par défaut configurée pour cet agent, et models list --agent <id> affiche son inventaire. Si models set se termine avec un code différent de zéro pour un fournisseur inconnu, il s’agit de la couche modèle : le fournisseur doit être un plugin installé ou être déclaré sous models.providers. Si les messages n’atteignent aucun agent, il s’agit de la couche routage. Si des exécutions en double apparaissent lorsque plusieurs agents partagent un canal, OpenClaw documente les clés de protection contre les boucles de bot comme garde-fou — la documentation décrit une prévention, pas une cause racine ; établissez donc le diagnostic avant de le supposer.

Exécutez ensuite une tâche limitée par agent et consultez le montant facturé par votre compte fournisseur pour celle-ci. Kunavo n’a pas testé OpenClaw en conditions réelles, en mode mono-agent ou multi-agent : tout ce qui précède provient de la documentation publiée d’OpenClaw, et une configuration publiée ne constitue pas un test de compatibilité. Conservez une voie opérationnelle pendant vos essais. Commencez par la configuration du fournisseur, comparez la facture d’exploitation complète dans la tarification d’OpenClaw, puis créez un compte Kunavo lorsque vous serez prêt à approvisionner une clé.

Questions fréquentes

Documentation d’OpenClaw, référence CLI et entrée du registre npm vérifiées le 21 septembre 2026 pour la version de paquet 2026.9.5 ; aucun Gateway, agent, binding ni appel payant n’a été exécuté ici. Les tarifs des tokens Kunavo sont lus dans le catalogue en ligne, et chaque montant en dollars de cette page correspond à un calcul illustratif de tokens, non à une facture mesurée.