Basculement de modèle

OpenClaw gère les échecs en deux étapes :

1. Rotation des profils d’authentification au sein du fournisseur actuel.
2. Repli de modèle vers le modèle suivant dans agents.defaults.model.fallbacks.

Ce document explique les règles d’exécution et les données qui les prennent en charge.

Flux d’exécution

Pour une exécution textuelle normale, OpenClaw évalue les candidats dans cet ordre :

C’est volontairement plus étroit que « enregistrer et restaurer toute la session ». Le runner de réponse ne persiste que les champs de sélection de modèle qu’il possède pour le repli :

• providerOverride
• modelOverride
• modelOverrideSource
• authProfileOverride
• authProfileOverrideSource
• authProfileOverrideCompactionCount

Cela évite qu’une nouvelle tentative de repli échouée écrase des mutations de session plus récentes et sans rapport, comme des changements manuels /model ou des mises à jour de rotation de session survenus pendant l’exécution de la tentative.

Politique de source de sélection

OpenClaw sépare le fournisseur/modèle sélectionné de la raison de cette sélection. Cette source contrôle si la chaîne de repli est autorisée :

• Valeur par défaut configurée : agents.defaults.model.primary utilise agents.defaults.model.fallbacks.
• Modèle principal de l’agent : agents.list[].model est strict sauf si l’objet de modèle de cet agent inclut ses propres fallbacks. Utilisez fallbacks: [] pour rendre le comportement strict explicite, ou fournissez une liste non vide pour activer le repli de modèle pour cet agent.
• Substitution de repli automatique : un repli d’exécution écrit providerOverride, modelOverride, modelOverrideSource: "auto" et le modèle d’origine sélectionné avant de réessayer. Cette substitution automatique peut continuer à parcourir la chaîne de repli configurée sans sonder le modèle principal à chaque message, mais OpenClaw sonde périodiquement à nouveau l’origine configurée et efface la substitution automatique lorsqu’elle récupère. /new, /reset et sessions.reset effacent également les substitutions provenant de l’automatisation. Les exécutions Heartbeat sans heartbeat.model explicite effacent les substitutions automatiques directes lorsque leur origine ne correspond plus à la valeur par défaut configurée actuelle.
• Substitution de session utilisateur : /model, le sélecteur de modèle, session_status(model=...) et sessions.patch écrivent modelOverrideSource: "user". Il s’agit d’une sélection de session exacte. Si le fournisseur/modèle sélectionné échoue avant de produire une réponse, OpenClaw signale l’échec au lieu de répondre depuis un repli configuré sans rapport.
• Substitution de session héritée : d’anciennes entrées de session peuvent avoir modelOverride sans modelOverrideSource. OpenClaw les traite comme des substitutions utilisateur afin qu’une ancienne sélection explicite ne soit pas silencieusement convertie en comportement de repli.
• Modèle de payload Cron : un payload.model / --model de tâche cron est un modèle principal de tâche, pas une substitution de session utilisateur. Il utilise les replis configurés sauf si la tâche fournit payload.fallbacks ; payload.fallbacks: [] rend l’exécution cron stricte.

L’intervalle de sondage du modèle principal pour le repli automatique est de cinq minutes et n’est pas configurable. OpenClaw mémorise les sondages récents par session et par modèle principal afin qu’un modèle principal défaillant ne soit pas réessayé à chaque tour. OpenClaw envoie un avis visible lorsqu’une session passe sur un repli et un autre avis lorsqu’elle revient au modèle principal sélectionné ; il ne répète pas l’avis à chaque tour de repli persistant.

Cache d’évitement des échecs d’authentification

Par défaut, chaque nouveau tour conserve le comportement existant de nouvelle tentative de repli : OpenClaw réessaiera chaque candidat de repli configuré, y compris les candidats non principaux qui ont récemment échoué avec auth ou auth_permanent.

Les opérateurs qui préfèrent supprimer ces échecs d’authentification répétés peuvent l’activer avec :

OPENCLAW_FALLBACK_SKIP_TTL_MS=60000

Lorsqu’il est activé, OpenClaw enregistre en mémoire, à portée de session, un marqueur d’évitement pour un candidat de repli non principal après un échec de classe auth. Le marqueur est indexé par identifiant de session, fournisseur et modèle. Les candidats principaux ne sont jamais ignorés, donc une sélection explicite de modèle utilisateur expose toujours la véritable erreur d’authentification. Le cache est local au processus et est effacé au redémarrage du Gateway.

La valeur est un TTL en millisecondes. 0 ou une valeur non définie désactive le cache. Les valeurs positives sont bornées entre 1 seconde et 10 minutes.

Avis de repli visibles par l’utilisateur

Lorsqu’une session passe à un repli sélectionné automatiquement, OpenClaw envoie un avis d’état dans la même surface de réponse :

↪️ Model Fallback: <fallback> (selected <primary>; <reason>)

Lorsqu’un sondage ultérieur réussit et que la session revient au modèle principal sélectionné, OpenClaw envoie :

↪️ Model Fallback cleared: <primary> (was <fallback>)

Ces avis sont des messages opérationnels, pas du contenu d’assistant. Ils sont livrés une fois par changement d’état, y compris pour les tours à effets secondaires uniquement lorsque c’est possible, mais les tours de repli persistants ne les répètent pas. La livraison contourne la suppression normale des réponses sources, l’avis ne consomme pas le premier emplacement de réponse d’assistant pour les canaux avec fils de discussion, et il est exclu de la synthèse vocale et de l’extraction des engagements.

Stockage d’authentification (clés + OAuth)

OpenClaw utilise des profils d’authentification pour les clés API comme pour les jetons OAuth.

• Les secrets et l’état de routage d’authentification à l’exécution résident dans ~/.openclaw/agents/<agentId>/agent/openclaw-agent.sqlite.
• La configuration auth.profiles / auth.order contient uniquement des métadonnées + du routage (pas de secrets).
• Fichier OAuth hérité uniquement importé : ~/.openclaw/credentials/oauth.json (importé dans le magasin d’authentification par agent lors de la première utilisation).
• Les fichiers hérités auth-profiles.json, auth-state.json et les fichiers par agent auth.json sont importés par openclaw doctor --fix.

Plus de détails : OAuth

Types d’identifiants :

• type: "api_key" → { provider, key }
• type: "oauth" → { provider, access, refresh, expires, email? } (+ projectId/enterpriseUrl pour certains fournisseurs)

Identifiants de profil

Les connexions OAuth créent des profils distincts afin que plusieurs comptes puissent coexister.

• Par défaut : provider:default lorsqu’aucune adresse e-mail n’est disponible.
• OAuth avec e-mail : provider:<email> (par exemple google-antigravity:user@gmail.com).

Les profils résident dans le magasin de profils d’authentification openclaw-agent.sqlite par agent.

Ordre de rotation

Lorsqu’un fournisseur possède plusieurs profils, OpenClaw choisit un ordre comme suit :

Si aucun ordre explicite n’est configuré, OpenClaw utilise un ordre en tourniquet :

• Clé principale : type de profil (OAuth avant les clés API).
• Clé secondaire : usageStats.lastUsed (le plus ancien d’abord, au sein de chaque type).
• Les profils en refroidissement/désactivés sont déplacés à la fin, ordonnés par expiration la plus proche.

Persistance de session (compatible avec le cache)

OpenClaw épingle le profil d’authentification choisi par session afin de garder les caches du fournisseur chauds. Il ne le fait pas tourner à chaque requête. Le profil épinglé est réutilisé jusqu’à ce que :

• la session soit réinitialisée (/new / /reset)
• une Compaction se termine (le compteur de Compaction augmente)
• le profil soit en refroidissement/désactivé

La sélection manuelle via /model …@<profileId> définit une substitution utilisateur pour cette session et n’est pas automatiquement remplacée tant qu’une nouvelle session ne démarre pas.

Abonnement OpenAI Codex plus secours par clé API

Pour les modèles d’agent OpenAI, l’authentification et l’exécution sont séparées. openai/gpt-* reste sur le harnais Codex tandis que l’authentification peut tourner entre un profil d’abonnement Codex et une clé API OpenAI de secours.

Utilisez auth.order.openai pour l’ordre visible par l’utilisateur :

{  auth: {    order: {      openai: ["openai:user@example.com", "openai:api-key-backup"],    },  },}

Utilisez openai:* pour les profils OAuth ChatGPT/Codex comme pour les profils à clé API OpenAI. Lorsque l’abonnement atteint une limite d’utilisation Codex, OpenClaw enregistre l’heure exacte de réinitialisation lorsque Codex en fournit une, essaie le profil d’authentification ordonné suivant et conserve l’exécution dans le harnais Codex. Une fois l’heure de réinitialisation passée, le profil d’abonnement redevient éligible et la prochaine sélection automatique peut y revenir.

Utilisez un profil épinglé par l’utilisateur uniquement lorsque vous voulez forcer un compte/une clé pour cette session. Les profils épinglés par l’utilisateur sont volontairement stricts et ne basculent pas silencieusement vers un autre profil.

Refroidissements

Lorsqu’un profil échoue en raison d’erreurs d’authentification/de limite de débit (ou d’un délai d’attente qui ressemble à une limitation de débit), OpenClaw le marque en refroidissement et passe au profil suivant.

Les temporisations utilisent un backoff exponentiel :

• 1 minute
• 5 minutes
• 25 minutes
• 1 heure (plafond)

L’état est stocké dans l’état d’authentification SQLite par agent sous usageStats :

{  "usageStats": {    "provider:profile": {      "lastUsed": 1736160000000,      "cooldownUntil": 1736160600000,      "errorCount": 2    }  }}

Désactivations de facturation

Les échecs de facturation/crédit (par exemple "insufficient credits" / "credit balance too low") sont traités comme justifiant un basculement, mais ils ne sont généralement pas transitoires. Au lieu d’une courte temporisation, OpenClaw marque le profil comme désactivé (avec un backoff plus long) et passe au profil/fournisseur suivant.

L’état est stocké dans l’état d’authentification SQLite par agent :

{  "usageStats": {    "provider:profile": {      "disabledUntil": 1736178000000,      "disabledReason": "billing"    }  }}

Valeurs par défaut :

• Le backoff de facturation commence à 5 heures, double à chaque échec de facturation et est plafonné à 24 heures.
• Les compteurs de backoff sont réinitialisés si le profil n’a pas échoué pendant 24 heures (configurable).
• Les nouvelles tentatives en cas de surcharge autorisent 1 rotation de profil chez le même fournisseur avant le repli de modèle.
• Les nouvelles tentatives en cas de surcharge utilisent par défaut un backoff de 0 ms.

Repli de modèle

Si tous les profils d’un fournisseur échouent, OpenClaw passe au modèle suivant dans agents.defaults.model.fallbacks. Cela s’applique aux échecs d’authentification, aux limites de débit et aux délais d’expiration qui ont épuisé la rotation des profils (les autres erreurs ne font pas avancer le repli). Les erreurs de fournisseur qui n’exposent pas assez de détails restent étiquetées avec précision dans l’état de repli : empty_response signifie que le fournisseur n’a renvoyé aucun message ou statut utilisable, no_error_details signifie que le fournisseur a explicitement renvoyé Unknown error (no error details in response), et unclassified signifie qu’OpenClaw a conservé l’aperçu brut mais qu’aucun classificateur ne lui correspond encore.

Les erreurs de surcharge et de limite de débit sont gérées plus agressivement que les temporisations de facturation. Par défaut, OpenClaw autorise une nouvelle tentative avec un profil d’authentification du même fournisseur, puis passe au repli de modèle configuré suivant sans attendre. Les signaux d’occupation du fournisseur tels que ModelNotReadyException arrivent dans ce compartiment de surcharge. Ajustez cela avec auth.cooldowns.overloadedProfileRotations, auth.cooldowns.overloadedBackoffMs et auth.cooldowns.rateLimitedProfileRotations.

Lorsqu’une exécution démarre depuis le primaire par défaut configuré, le primaire d’une tâche Cron, le primaire d’un agent avec des replis explicites ou une substitution de repli sélectionnée automatiquement, OpenClaw peut parcourir la chaîne de repli configurée correspondante. Les primaires d’agent sans replis explicites et les sélections utilisateur explicites (par exemple /model ollama/qwen3.5:27b, le sélecteur de modèle, sessions.patch ou des substitutions ponctuelles de fournisseur/modèle via la CLI) sont stricts : si ce fournisseur/modèle est inaccessible ou échoue avant de produire une réponse, OpenClaw signale l’échec au lieu de répondre depuis un repli sans rapport.

Règles de chaîne de candidats

OpenClaw construit la liste de candidats à partir du provider/model actuellement demandé, plus les replis configurés.

Quelles erreurs font avancer le repli

Comportement de saut de temporisation ou de sonde

Lorsque tous les profils d’authentification d’un fournisseur sont déjà en temporisation, OpenClaw ne saute pas automatiquement ce fournisseur pour toujours. Il prend une décision par candidat :

Substitutions de session et changement de modèle en direct

Les changements de modèle de session sont un état partagé. L’exécuteur actif, la commande /model, les mises à jour de compaction/session et la réconciliation de session en direct lisent ou écrivent tous des parties de la même entrée de session.

Cela signifie que les nouvelles tentatives de repli doivent se coordonner avec le changement de modèle en direct :

• Seuls les changements de modèle explicitement déclenchés par l’utilisateur marquent un changement en direct en attente. Cela inclut /model, session_status(model=...) et sessions.patch.
• Les changements de modèle déclenchés par le système, comme la rotation de repli, les substitutions de Heartbeat ou la Compaction, ne marquent jamais d’eux-mêmes un changement en direct en attente.
• Les substitutions de modèle déclenchées par l’utilisateur sont traitées comme des sélections exactes pour la politique de repli, de sorte qu’un fournisseur sélectionné inaccessible apparaît comme un échec au lieu d’être masqué par agents.defaults.model.fallbacks.
• Avant le démarrage d’une nouvelle tentative de repli, l’exécuteur de réponse persiste les champs de substitution de repli sélectionnés dans l’entrée de session.
• Les substitutions de repli automatiques restent sélectionnées lors des tours suivants afin qu’OpenClaw ne sonde pas un primaire connu comme défaillant à chaque message. OpenClaw sonde périodiquement à nouveau l’origine configurée et efface la substitution automatique lorsqu’elle récupère ; /new, /reset et sessions.reset effacent immédiatement les substitutions d’origine automatique.
• Les réponses utilisateur annoncent les transitions de repli et la récupération avec repli effacé une fois par changement d’état. Les tours de repli persistants ne répètent pas l’avis.
• /status affiche le modèle sélectionné et, lorsque l’état de repli diffère, le modèle de repli actif et la raison.
• La réconciliation de session en direct préfère les substitutions de session persistées aux champs de modèle d’exécution obsolètes.
• Si une erreur de changement en direct pointe vers un candidat ultérieur dans la chaîne de repli active, OpenClaw saute directement à ce modèle sélectionné au lieu de parcourir d’abord des candidats sans rapport.
• Si la tentative de repli échoue, l’exécuteur annule uniquement les champs de substitution qu’il a écrits, et seulement s’ils correspondent encore à ce candidat échoué.

Cela empêche la course classique :

La substitution de repli persistée ferme cette fenêtre, et l’annulation étroite conserve intactes les modifications de session manuelles ou d’exécution plus récentes.

Observabilité et résumés d’échec

runWithModelFallback(...) enregistre les détails par tentative qui alimentent les journaux et les messages de temporisation visibles par l’utilisateur :

• fournisseur/modèle tenté
• raison (rate_limit, overloaded, billing, auth, model_not_found et raisons de basculement similaires)
• statut/code facultatif
• résumé d’erreur lisible par un humain

Les journaux structurés model_fallback_decision incluent aussi des champs plats fallbackStep* lorsqu’un candidat échoue, est sauté ou qu’un repli ultérieur réussit. Ces champs rendent la transition tentée explicite (fallbackStepFromModel, fallbackStepToModel, fallbackStepFromFailureReason, fallbackStepFromFailureDetail, fallbackStepFinalOutcome) afin que les exportateurs de journaux et de diagnostics puissent reconstruire l’échec primaire même lorsque le repli terminal échoue aussi.

Lorsque tous les candidats échouent, OpenClaw lance FallbackSummaryError. L’exécuteur de réponse externe peut l’utiliser pour construire un message plus spécifique tel que "all models are temporarily rate-limited" et inclure l’expiration de temporisation la plus proche lorsqu’elle est connue.

Ce résumé de temporisation tient compte du modèle :

• les limites de débit limitées à des modèles sans rapport sont ignorées pour la chaîne fournisseur/modèle tentée
• si le blocage restant est une limite de débit limitée au modèle correspondant, OpenClaw signale la dernière expiration correspondante qui bloque encore ce modèle

Configuration associée

Voir Configuration du Gateway pour :

• auth.profiles / auth.order
• auth.cooldowns.billingBackoffHours / auth.cooldowns.billingBackoffHoursByProvider
• auth.cooldowns.billingMaxHours / auth.cooldowns.failureWindowHours
• auth.cooldowns.overloadedProfileRotations / auth.cooldowns.overloadedBackoffMs
• auth.cooldowns.rateLimitedProfileRotations
• agents.defaults.model.primary / agents.defaults.model.fallbacks
• routage agents.defaults.imageModel

Consultez Modèles pour une vue d’ensemble plus large de la sélection de modèles et des fallbacks.