L'été dernier, j'ai ouvert cinq comptes de fournisseurs LLM en un mois. OpenAI, Anthropic, OpenRouter, Fireworks, Together. En octobre, je ne savais plus quelle carte bancaire payait quoi. En décembre, l'un d'eux a modifié ses tarifs en douce, et je ne m'en suis aperçu que trois semaines plus tard en recevant la facture.
C'est la réalité peu glamour de tout ce qui tourne sur des LLMs en 2026 : le zoo de fournisseurs est une condition permanente. De nouveaux modèles sortent chaque semaine. Les prix bougent. Les tiers gratuits se redistribuent. Un modèle qui était à la pointe en mars devient une note de bas de page en mai. Si ton framework d'agent te fixe un provider à l'installation, tu signes pour reconstruire ton setup tous les deux mois.
Hermes Agent parie dans l'autre sens depuis le premier jour. Le fournisseur est une valeur de config, pas un choix que l'architecture fait pour toi. Trois fonctionnalités s'empilent pour que ça marche vraiment.
Le routeur central (v0.2.0)
La base, c'est un point d'appel unique. Dès la v0.2.0, le projet a introduit un routeur de providers centralisé — une seule fonction call_llm() / async_call_llm() par laquelle passe chaque partie de l'agent. Vision, résumé, compression, sauvegarde de trajectoire, boucle de chat principale. Tout passe par le même chemin de code.
Ça a l'air d'un détail de refactoring jusqu'à ce que tu essaies de changer de fournisseur dans un agent qui ne l'a pas. Dans la plupart des frameworks, il y a onze endroits qui appellent le LLM, et chacun lit les credentials un peu différemment. Tu en changes un, tu en oublies un autre, ça casse de façon difficile à repérer. Hermes a rendu ça impossible en faisant en sorte qu'il n'y ait qu'un seul endroit.
La chaîne de fallback (v0.6.0)
Deux semaines plus tard, la v0.6.0 a ajouté la couche suivante : des chaînes de fallback ordonnées entre providers. Tu listes les providers dans config.yaml, et quand ton principal tombe sur une erreur — 429 rate limit, 500 transitoire, endpoint injoignable — Hermes passe automatiquement au suivant dans la chaîne.
Point crucial : c'est ordonné, pas du round-robin. Tu choisis ta préférence et ton backup. Un setup classique : OpenRouter en défaut bon marché, Anthropic en direct comme backup fiable, et le tier gratuit de Nous Portal en dernier recours. Si le haut de la chaîne passe une mauvaise journée, tu ne t'en rends pas compte. La v0.6.0 a corrigé au passage un bug subtil : changer de provider via hermes model nettoie désormais le api_mode périmé au lieu de coder en dur chat_completions, ce qui empêche les endpoints compatibles Anthropic de renvoyer des 404 cryptiques après un changement.
Les pools de credentials (v0.7.0)
La release dédiée à la résilience a ajouté la troisième couche : les pools de credentials au sein d'un même provider. L'idée, c'est que « mon fournisseur principal » et « la clé API spécifique que j'ai chez ce fournisseur » sont deux choses différentes. Tu peux avoir trois clés Anthropic — personnelle, équipe, et un backup sur un second compte — et tu veux que Hermes utilise celle qui est la moins sollicitée.
Tu les configures via l'assistant de setup ou un bloc credential_pool, et Hermes choisit la clé least_used par défaut. Si une clé retourne 401, le pool passe automatiquement à la suivante et met la clé morte en période de refroidissement. L'implémentation est thread-safe, ce qui veut dire que tu peux faire tourner le CLI, un gateway Telegram et un cron job sur le même pool sans qu'ils se marchent dessus. La v0.7.0 s'est aussi assurée que l'état du pool survit aux bascules de fallback — un 429 sur ton provider principal n'efface pas la connaissance du pool sur quelles clés sont fatiguées.
Pourquoi l'empilement compte
Chacune de ces fonctionnalités résout un problème précis, mais la raison pour laquelle l'ensemble est puissant, c'est qu'elles se composent sans chevauchement :
- •Le routeur te permet de changer quel provider à un seul endroit.
- •La chaîne de fallback te permet de gérer les pannes de provider sans redémarrer.
- •Le pool de credentials te permet de gérer les pannes de clés et la charge au sein d'un même provider.
Et depuis le CLI, hermes model te permet de reconfigurer tout ça sans éditer de fichiers à la main. Au final : quand un nouveau modèle sort — peu importe lequel, de qui, à quel prix — le coût de migration se résume à « changer une ligne de config ». Pas « reconstruire mon assistant ». Pour un projet qui doit traverser de nombreuses générations de modèles, c'est probablement la seule décision d'architecture qui compte vraiment.