N’attendez pas qu’Hermes plante : une configuration de secours à 3 couches qui garde les tâches en cours

Quand on commence à utiliser Hermes, on se demande généralement : quel modèle est assez puissant ? Après l’avoir utilisé un moment, une autre question devient plus ennuyeuse : le modèle peut-il mener une tâche à bien de manière fiable ?

Imaginez ceci : vous confiez à Hermes une tâche de longue durée — organiser des documents, suivre une page web, exécuter une tâche Cron, écrire un script ou analyser un lot de fichiers. Les vingt premières minutes se passent bien. Puis, vers la fin, vous voyez :

HTTP 429
rate limit exceeded
quota exhausted
usage limit reached
provider overloaded

C’est le pire moment. La tâche est déjà à mi-chemin, le contexte s’est accumulé, les appels d’outils ont été exécutés, et soudain le quota du modèle est épuisé, l’API est limitée ou le fournisseur rencontre des problèmes. Changer de modèle manuellement à ce stade signifie généralement réexpliquer tout le contexte.

Hermes ne peut pas fonctionner de manière fiable sur un seul modèle, une seule clé et un seul point d’accès. Une approche plus robuste consiste à préparer trois couches de secours à l’avance :

  1. Plusieurs clés pour le même fournisseur
  2. Basculement automatique vers un modèle de secours quand le principal échoue
  3. Secours distinct pour les tâches auxiliaires comme les images, l’extraction web et la compression

Parcourons chaque couche.

1. Pourquoi les tâches longues sont les plus vulnérables aux échecs en cours d’exécution

Dans les conversations courtes, un échec du modèle n’est pas grave. Vous posez une question, cela échoue, vous réessayez avec un autre modèle.

Les tâches longues sont différentes. Hermes a peut-être lu des fichiers, ouvert des pages web, exécuté des commandes, généré des résultats intermédiaires, et s’exécute peut-être sans surveillance dans un job Cron. S’il s’interrompt à mi-chemin, vous perdez non seulement la réponse, mais aussi le temps, les tokens et l’effort de construction du contexte déjà investis.

Les cinq points de défaillance les plus courants sont :

Statut Signification
429 Limite de débit : trop de requêtes en peu de temps
402 Problème de facturation, de solde ou de quota
500 / 502 / 503 Erreur serveur du fournisseur
401 / 403 Clé invalide ou permissions incorrectes
404 / invalid response Nom de modèle, endpoint ou format de réponse incorrect

Ces problèmes ne sont pas résolus en « utilisant un modèle plus intelligent ». Ce dont vous avez besoin, c’est de tracer des itinéraires de secours pour Hermes à l’avance.

Pensez au modèle principal comme à une autoroute principale. C’est généralement la plus rapide, mais quand elle est embouteillée, vous ne devriez pas rester immobile. Vous avez besoin de routes secondaires, de véhicules de rechange et de chauffeurs de secours. Les trois couches de secours d’Hermes sont exactement cela.

2. Couche 1 : Conserver plusieurs clés pour le même fournisseur

La première couche est la plus simple et la plus souvent négligée : les pools d’identifiants.

Elle résout les problèmes au sein d’un même fournisseur : une clé est épuisée, limitée ou devient invalide. Par exemple, si votre modèle principal est deepseek-v4-pro et que vous n’avez qu’une seule clé API DeepSeek, Hermes n’a d’autre choix que de renvoyer une erreur une fois cette clé épuisée ou limitée.

Si vous ajoutez plusieurs clés sous le même fournisseur, Hermes peut basculer vers une clé saine et continuer.

Vérifiez les identifiants actuels :

hermes auth list

Ajoutez une seconde clé DeepSeek :

hermes auth add deepseek --api-key sk-your-second-deepseek-key

Si vous utilisez aussi OpenRouter, ajoutez-y une seconde clé :

hermes auth add openrouter --api-key sk-or-v1-your-second-key

La valeur ici est pratique :

  • Même modèle principal
  • Même fournisseur
  • Même style de modèle
  • Seule la clé change sous le même fournisseur

Recommandation : toute personne exécutant régulièrement des tâches longues devrait conserver au moins deux clés pour le fournisseur principal. Cela vaut particulièrement la peine si vous utilisez Hermes Cron pour des rapports quotidiens, de la surveillance ou l’organisation de documents.

3. Comment faire tourner les clés pour qu’une seule ne soit pas épuisée

Après avoir ajouté plusieurs clés, vous devez décider comment les utiliser. Hermes prend en charge les stratégies de rotation par fournisseur. En résumé : utilisez-vous la première clé jusqu’à ce qu’elle tombe en panne, ou faites-vous tourner les clés ?

Exemple de configuration :

credential_pool_strategies:
  deepseek: round_robin
  openrouter: least_used

Stratégies courantes :

Stratégie Comportement
fill_first Utilise la première clé jusqu’à échec, puis change
round_robin Fait tourner les clés une par une
least_used Privilégie la clé la moins utilisée jusqu’à présent
random Choisit une clé au hasard
  • Si vous n’avez que deux clés de secours et voulez un usage équilibré, utilisez round_robin.
  • Si vous avez plusieurs clés avec des quotas différents et voulez éviter d’en épuiser une trop tôt, essayez least_used.

Une petite mise en garde : changer de clé peut invalider le cache de prompt. Quand Hermes passe à une nouvelle clé, celle-ci peut ne pas avoir le cache de contexte précédent, donc la requête suivante peut avoir besoin de relire le contexte complet. Cela coûte des tokens d’entrée supplémentaires.

Les pools d’identifiants ne sont donc pas vraiment une question d’économie. Il s’agit de garder la tâche en vie. Pour les tâches longues, il vaut mieux payer un peu plus que perdre toute l’exécution.

4. Couche 2 : Basculement automatique vers un modèle de secours

La couche 1 résout les problèmes au niveau des clés au sein d’un fournisseur. La couche 2 résout le problème plus grand : l’ensemble du fournisseur ou du modèle principal devient instable.

Supposons que votre modèle principal soit deepseek-v4-pro. Si le point d’accès DeepSeek est congestionné ou que le quota de votre compte est épuisé, changer pour une autre clé DeepSeek peut ne pas aider, car le problème est du côté du service ou au niveau du compte.

C’est là que les fournisseurs de secours entrent en jeu.

Utilisez la configuration interactive :

hermes fallback

Ou modifiez directement ~/.hermes/config.yaml. Voici un exemple pratique :

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

Ce que cela signifie :

  1. Utilisez normalement deepseek-v4-pro
  2. En cas de panne DeepSeek, basculez vers GLM 5.2
  3. Si GLM 5.2 échoue aussi, basculez vers Kimi K2.7

Les noms de modèles doivent correspondre aux IDs affichés dans votre console de fournisseur réelle, hermes model ou la liste des modèles. La dénomination varie selon les fournisseurs, alors vérifiez toujours l’ID exact.

Cette configuration est idéale pour les tâches longues : organiser un lot de documents, exécuter un job en arrière-plan de 30 minutes ou analyser une base de code. Quand le modèle principal bronchotte, Hermes continue sans que vous interveniez à mi-chemin.

5. Couche 3 : Donnez aussi un secours aux tâches auxiliaires

Beaucoup de gens ne configurent le secours que pour le modèle de chat principal. Mais Hermes dépend aussi de nombreuses tâches auxiliaires :

  • Analyse d’images
  • Extraction web
  • Compression de contexte
  • Génération de titres de session
  • Recherche de skills
  • Actions auxiliaires MCP
  • Jugement d’approbation de commandes

Ces tâches peuvent aussi appeler des modèles. Si elles n’ont pas de secours, elles peuvent faire échouer tout le déroulement.

Par exemple, quand vous demandez à Hermes de lire une page web, il peut d’abord effectuer une extraction web ; quand le contexte devient trop long, il peut le compresser ; quand vous téléchargez une capture d’écran, il peut appeler un modèle de vision.

Vous pouvez configurer un secours distinct pour ces tâches :

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

Cela signifie :

  • La compression de contexte commence avec GLM 5.2, bascule vers Kimi K2.7, puis finalement vers DeepSeek
  • L’extraction web commence avec Kimi K2.7, puis bascule vers GLM 5.2

Les tâches auxiliaires privilégient la stabilité, le faible coût et une vitesse appropriée. Vous pouvez réserver le modèle le plus fort pour la tâche principale et utiliser des modèles moins chers et plus rapides pour l’extraction, la compression et la génération de titres. Mais si la tâche est critique — révision de contrats, organisation de base de code à long contexte ou résumés de documents clients — il vaut la peine de donner aux tâches auxiliaires leur propre secours.

6. Réduisez les tentatives pour basculer plus vite vers le secours

Hermes réessaie quelques fois par défaut avant de déclencher le secours. C’est logique, car certains erreurs 429 ou réseau ne sont que de brèves perturbations. Attendre quelques secondes peut éviter le coût et le changement de style d’un changement de modèle.

Mais si un fournisseur est fréquemment instable sur de longues périodes, vous pouvez faire basculer Hermes plus rapidement :

agent:
  api_max_retries: 1

Ou encore plus agressivement :

agent:
  api_max_retries: 0

Paramètres suggérés :

  • Conversation informelle : conservez la valeur par défaut
  • Tâches longues : envisagez 1
  • Jobs Cron sans surveillance : envisagez 0 ou 1
  • Tâches sensibles au coût : évitez d’être trop agressif

Pourquoi ne pas toujours le régler sur 0 ? Chaque changement de fournisseur peut invalider les caches, et dans les tâches à long contexte, les tokens d’entrée peuvent augmenter de manière notable. Ce paramètre n’est donc pas « plus petit est toujours meilleur ». Une approche équilibrée consiste à réduire les tentatives pour les tâches longues importantes tout en conservant la valeur par défaut pour les tâches ordinaires.

7. Une configuration de secours pratique pour les tâches de longue durée

Pour un environnement qui exécute régulièrement des tâches longues avec Hermes, voici une conception possible :

  • Principal : deepseek-v4-pro pour le contexte long et les capacités générales
  • Premier secours : glm-5.2 pour les tâches longues, le code, le raisonnement et les flux complexes
  • Deuxième secours : kimi-k2.7-code pour la continuation de code, la compréhension de projet et le traitement de documents longs

Exemple de configuration :

model:
  provider: deepseek
  default: deepseek-v4-pro

fallback_providers:
  - provider: zai
    model: glm-5.2
  - provider: kimi-coding
    model: kimi-k2.7-code

credential_pool_strategies:
  deepseek: round_robin
  zai: fill_first
  kimi-coding: fill_first

agent:
  api_max_retries: 1

auxiliary:
  compression:
    provider: zai
    model: glm-5.2
    fallback_chain:
      - provider: kimi-coding
        model: kimi-k2.7-code
      - provider: deepseek
        model: deepseek-v4-pro

  web_extract:
    provider: kimi-coding
    model: kimi-k2.7-code
    fallback_chain:
      - provider: zai
        model: glm-5.2

  title_generation:
    provider: deepseek
    model: deepseek-v4-pro

Après l’enregistrement, redémarrez la passerelle :

hermes gateway restart

Puis vérifiez la configuration :

hermes config check

Si vous préférez ne pas écrire le YAML à la main, commencez par les commandes interactives :

hermes model
hermes fallback
hermes auth list

Recommandation pour les nouveaux arrivants : ne configurez pas tous les modèles à la fois. Procédez en trois étapes :

  1. Ajoutez une seconde clé pour votre fournisseur principal
  2. Ajoutez un fournisseur de secours
  3. Configurez enfin le secours pour compression et web_extract

Cela facilite le dépannage.

8. Quelles tâches bénéficient le plus de cette configuration à trois couches

Toutes les tâches n’ont pas besoin de cette complexité. Si vous posez juste quelques questions occasionnelles, trois couches de secours sont excessives. Mais les scénarios suivants méritent d’être configurés tôt :

  • Jobs planifiés Hermes Cron
  • Tâches longues d’organisation de documents
  • Tâches d’analyse de base de code
  • Recherche et extraction multi-pages
  • Tâches qui compressent fréquemment les contextes longs
  • Tâches liées à des projets clients
  • Workflows en arrière-plan sans surveillance

Les jobs Cron sont l’exemple classique. Vous pourriez demander à Hermes de résumer les actualités IA chaque matin ou de vérifier un site web toutes les heures. Vous n’êtes pas devant votre ordinateur quand il s’exécute, et si le quota du modèle est épuisé, le job échoue. Avec les pools d’identifiants et le secours, la tâche a une autre voie à suivre.

L’analyse de base de code est un autre cas clé. Hermes lit de nombreux fichiers et construit le contexte du projet. Si le modèle tombe en panne à ce moment, recommencer à zéro gaspille beaucoup d’efforts. Le secours permet de continuer à partir du contexte existant.

Points clés à retenir

Souvenez-vous de cette phrase : Pour les tâches longues avec Hermes, configurez le secours du modèle avant que les choses ne cassent, pas après.

Les trois couches les plus pratiques sont :

  1. Credential Pools : conservez plusieurs clés pour le même fournisseur et faites-les tourner automatiquement en cas de limites de débit ou de problèmes de quota.
  2. Fallback Providers : basculez automatiquement vers un fournisseur et un modèle de secours quand le principal échoue.
  3. Auxiliary Fallback : donnez aux tâches auxiliaires comme l’extraction web, l’analyse d’images et la compression de contexte leurs propres routes de secours.

Une combinaison de modèles solide pourrait être :

  • Principal : deepseek-v4-pro
  • Premier secours : glm-5.2
  • Deuxième secours : kimi-k2.7-code

Commandes clés à retenir :

hermes auth list
hermes auth add deepseek --api-key sk-your-second-deepseek-key
hermes fallback
hermes config check
hermes gateway restart

Un dernier rappel : le secours vise à maintenir les tâches en cours d’exécution, pas à atteindre la perfection. Le coût peut être l’invalidation du cache, une utilisation accrue de tokens et de légères variations dans le style de réponse. Il est donc mieux adapté aux tâches longues importantes, aux tâches planifiées et aux workflows sans surveillance. Pour les conversations ordinaires, gardez les choses simples. Quand vous avez vraiment besoin qu’Hermes fonctionne, ne comptez pas sur un seul modèle.