Vous confiez à Hermes un lot : huit sous-tâches. Six sont des recherches — lire une doc, lancer un grep sur un log, remettre un tableau en forme. Deux sont les difficiles — démêler un bug de concurrence, redessiner une frontière de module. Et vous n’avez qu’un modèle pour toutes. Prenez-en un cher, et les six tâches triviales brûlent de l’argent ; prenez-en un bon marché, et les deux difficiles reviennent avec un non-sens plausible. Ce choix forcé cesse d’être obligatoire avec la PR #142563, fusionnée le 22 octobre 2026.

L’ancienne règle : un seul delegation.model pour tous les enfants

Le modèle enfant était épinglé globalement dans config.yaml — delegation.model, delegation.provider, delegation.base_url. Sous la stratégie par défaut, delegate_task n’a aucun paramètre de modèle par tâche : chaque subagent d’un lot tourne donc sur la même route. La doc le disait sans détour : pour une sous-tâche sensible à la qualité, soit vous laissez delegation.model non défini pour cette session, soit vous confiez le travail au tableau kanban, qui accepte, lui, une surcharge de modèle par tâche.

Tout le monde a donc fait le même compromis : épingler un modèle de milieu de gamme et vivre avec.

La nouvelle règle : delegation.backend décide du routage

Le changement en une phrase : la délégation est devenue une catégorie de provider enfichable, de la même forme que le TTS, la génération d’images et les backends de terminal. delegation.backend choisit la stratégie. default signifie exactement ce que vous aviez — non défini ou default laisse le schéma de delegate_task et chaque définition d’outil hermes-cli identiques à l’octet près.

Les deux autres stratégies viennent du plugin officiel advanced-delegation :

• model_map — vous listez des options nommées (fast, deep, …), chacune avec une description d’une ligne plus un provider et un modèle, et le modèle en choisit une par tâche ;
• profile_routes — chaque tâche tourne en tant que l’un de vos profils Hermes, avec le modèle, les identifiants, les skills et la persona de ce profil.

delegation:
  backend: model_map
  backends:
    model_map:
      options:
        - name: fast
          description: Cheap and quick; lookups, summaries, simple edits.
          provider: openrouter
          model: google/gemini-3-flash-preview
        - name: deep
          description: Slow and careful; hard debugging and design work.
          provider: anthropic
          model: claude-opus-5
          reasoning_effort: high
          service_tier: fast      # facultatif ; refusé au spawn si cette route n'a pas de palier fast
      default: fast                # facultatif : option pour les tâches qui n'en définissent aucune
    profile_routes:                # lu quand backend: profile_routes
      profiles:
        - name: coder
          description: Writes and refactors code; runs tests.

Les descriptions ne sont pas décoratives. Le modèle ne voit jamais que les noms et les descriptions que vous avez configurés — jamais les champs bruts provider, modèle ou clé. Écrivez « Cheap and quick; lookups, summaries » et vous lui apprenez quand économiser ; écrivez « Slow and careful; hard debugging and design work » et vous lui apprenez quand dépenser.

Le core conserve dans les deux cas tout le cycle de vie : spawn, isolation, rôles leaf/orchestrator, profondeur, concurrence, unités en arrière-plan, arrêt du fan-out, résultats, output_schema, progression. Seule la décision de routage a bougé.

Chaque résultat routé porte désormais un reçu route

Une tâche passée par un backend indique où elle a réellement tourné : le backend, le nom de l’option ou du profil, et le provider, le modèle, l’effort de raisonnement et le palier de vitesse utilisés par l’enfant. Si un provider de fallback a pris le relais, fallback_activated vaut true.

C’est plus important que ça n’en a l’air. Avant, vous déduisiez le modèle de l’enfant à partir de « j’ai réglé delegation.model ». Maintenant, il vous le rapporte — quand un lot devient soudain cher, vous lisez le reçu au lieu de deviner.

Les échecs sont bruyants, jamais un basculement silencieux

C’est là que la PR met l’essentiel de son effort :

• Si le backend sélectionné manque (plugin non installé ou désactivé) ou signale qu’il ne peut pas tourner, delegate_task renvoie une erreur d’outil qui nomme le backend et le correctif (installer ou activer le plugin, /delegation default, ou hermes config set delegation.backend default). Aucun subagent ne démarre, et les enfants ne tournent jamais discrètement sur la route par défaut.
• Dans un lot, une tâche que son backend ne peut pas router — option inconnue, paramètre que le backend choisi n’accepte pas, profil inexistant, service_tier que la route ne propose pas, reasoning_effort inconnu, identifiants manquants — est refusée seule. Son entrée de résultat porte status: "error", la raison et route.refused: true ; ses voisines continuent.
• L’appel ne devient une erreur d’outil que si toutes les tâches ont été refusées.
• Une route de modèle sans ses propres fallback_providers hérite de delegation.fallback_providers ; fallback_providers: [] sur la route désactive le fallback pour elle. Une route de profil utilise la chaîne de fallback propre à ce profil.

Une limite à connaître : tant que model_map ou profile_routes est actif, delegation.model et delegation.provider sont inactifs — ce sont les routes qui décident. Ne configurez pas des options puis ne vous demandez pas pourquoi l’ancien épinglage a cessé de compter.

Basculer, et revenir

Les deux stratégies, la commande slash /delegation et hermes delegation config (créer, modifier et supprimer des routes de modèle, choisir des profils) arrivent dans le plugin officiel :

hermes plugins search advanced-delegation
hermes plugins install advanced-delegation
hermes plugins enable advanced-delegation

Ensuite, basculer ne demande plus d’éditer des fichiers :

/delegation model_map               # cette session uniquement
/delegation profile_routes --global # écrit delegation.backend dans config.yaml
/delegation default                 # retour à la stratégie par défaut

Un détail que la doc souligne explicitement : un basculement de session change le routage, pas le schéma de l’outil. Les paramètres par tâche (option, profile) font partie du prompt mis en cache et suivent config.yaml : ils changent donc à la session suivante. D’ici là, le modèle peut encore envoyer le paramètre du backend précédent — un option: fast après être passé à profile_routes. Cette tâche est refusée pour elle-même, avec le correctif dans le message : /delegation <backend> --global puis /new (parce que /new démarre sur le backend enregistré), ou /delegation <saved backend> pour revenir. Elle ne tourne jamais sur la route par défaut du nouveau backend juste pour continuer.

Sans le plugin, hermes config set delegation.backend default rétablit l’ancien comportement.

Quelle stratégie choisir

• model_map — un seul jeu d’identifiants, l’argent réparti selon la difficulté. Les tâches légères vont à un modèle bon marché, les dures à un modèle fort. Ça convient aux lots dont les sous-tâches varient énormément en difficulté : corriger dix issues en une passe, lancer vingt fils de recherche.
• profile_routes — l’enfant change d’identité. Chaque profil porte son propre modèle, son pool d’identifiants, son SOUL.md et sa politique de terminal, ce qui convient à « ces subagents doivent tourner sous d’autres permissions », par exemple garder le travail de code dans une politique de terminal restreinte.

Un avertissement vient droit de la doc et mérite d’être cité : lister un profil dans delegation.backends.profile_routes autorise les subagents de ce profil à utiliser les identifiants, le pool d’identifiants, le SOUL.md et la politique de terminal de ce profil. Ne listez que les profils dont les clés et l’accès terminal vous conviennent pour cet agent.

État de la release

La PR #142563 a été fusionnée dans main le 22 octobre 2026. Le suivi #142564 déplace la stratégie par défaut elle-même dans un plugin fourni avec l’agent, et #143126 ajoute les réglages de délégation du desktop (sélecteur de mode, éditeur de routes de modèle, routes de profil). La release la plus récente est la v0.22.4 du 21 octobre : tout cela n’est donc aujourd’hui que sur main et arrivera dans le canal stable avec la prochaine version. Si vous basculez maintenant, notez le canal : les releases de correctifs ne l’embarquent pas encore.

Si vous n’avez pas encore utilisé le contrôle des subagents en direct (list/steer/stop), commencez par le guide d’orchestration des subagents. Pour la section delegation complète, la référence hermes config est plus rapide que le code source. L’autre moitié du routage par modèle se trouve dans le guide model_overrides, et l’installation des plugins est couverte par le guide du catalogue de plugins.