Pourquoi le message « Rate limited — switching to fallback provider » apparaît-il en boucle ?

Ce n'est pas vraiment un « bug de basculement », mais le modèle principal qui subit une limitation de débit (rate limiting) en amont. Hermes passe alors automatiquement au modèle de secours

sg claude opus 4.7 via custom

Que signifie concrètement ce message ?

• Hermes bascule automatiquement vers un fournisseur de secours quand le fournisseur principal rencontre une erreur : limite de débit, erreur serveur, échec d'authentification, erreur 404, ou réponse endommagée/en boucle.
• Après le basculement, Hermes conserve le contexte de la conversation et continue avec le modèle de secours, sans perte de données.
• Mais ce basculement ne vaut que pour le tour en cours. Au tour suivant, Hermes revient au fournisseur principal, puis rebascule si celui-ci est toujours en échec.

Pourquoi le message se répète-t-il sans cesse ?

• La cause directe est que le fournisseur principal en amont est encore en situation de rate limiting, donc chaque nouveau tour échoue à nouveau et déclenche le basculement vers

  sg claude opus 4.7

  .
• Si l'erreur réelle est un HTTP 429, la documentation OpenClaw la classe dans la famille des erreurs de limite de débit / limite amont, ce qui nécessite un diagnostic au niveau de la passerelle, pas un simple souci d'interface.
• Dans certains cas, une erreur 429 peut aussi être liée à des requêtes avec des contextes très longs : l'amont refuse alors la requête ou applique un quota plus strict.

Le point le plus suspect dans votre situation

• La mention

  sg claude opus 4.7 via custom

  indique que le basculement transite par un point de terminaison personnalisé (custom endpoint / provider) déjà configuré dans Hermes, et non par un changement vers un fournisseur natif complètement différent.
• Si le fournisseur principal et le fournisseur de secours s'appuient sur le même serveur/pool amont saturé, vous verrez un changement de fournisseur tout en ayant l'impression que « rien ne s'arrange ». Les preuves manquent pour l'affirmer avec certitude, mais c'est une piste très probable à vérifier dans votre configuration effective.
• La documentation d'Hermes précise que le point de terminaison personnalisé est stocké dans config.yaml, et que la chaîne de basculement se trouve aussi dans config.yaml, sous la clé fallback_providers.

Par où commencer le diagnostic ?

• Vérifiez quel est le fournisseur principal actuel et où pointe la chaîne de secours dans config.yaml.
• Examinez si le fournisseur principal et

  sg claude opus 4.7 via custom

  utilisent la même passerelle, le même pool ou la même clé d'API en arrière-plan.
• Si vous passez par une passerelle OpenClaw ou une passerelle personnalisée, lancez une sonde ou une vérification d'état (probe/status) pour voir si l'erreur réelle est 429, une erreur d'authentification, ou une inadéquation de version entre client et passerelle.
• Si la passerelle ou le service lit les clés depuis des variables d'environnement, assurez-vous que la clé est bien présente sur la machine qui exécute la passerelle, puis redémarrez-la après tout changement.
• Si le problème survient principalement avec des contextes longs, examinez la limitation liée aux requêtes longues : la documentation OpenClaw mentionne que le 429 peut venir d'une exigence d'« utilisation supplémentaire » pour les requêtes à contexte long.

En résumé

• Le message se répète parce qu'Hermes applique correctement le mécanisme de basculement tour par tour, alors que le fournisseur principal n'est pas encore sorti de sa limitation de débit.
• Pour faire disparaître le message, il faut résoudre la cause racine au niveau du fournisseur principal, de la passerelle ou du pool, et non se focaliser sur la ligne « switching to fallback ».

Si vous le souhaitez, je peux examiner directement votre fichier de configuration pour identifier immédiatement le fournisseur principal qui échoue, la destination précise du basculement sg-* et la raison pour laquelle il retente le fournisseur principal à chaque tour.