Du gibst Hermes einen Batch: acht Subtasks. Sechs sind Lookups — ein Dokument lesen, ein Log greppen, eine Tabelle umformatieren. Zwei sind die harten — einen Concurrency-Bug entwirren, eine Modulgrenze neu ziehen. Und du bekommst ein Modell für alle. Nimm ein teures, und die sechs trivialen Aufgaben verbrennen Geld; nimm ein billiges, und die zwei harten kommen mit plausiblem Unsinn zurück. Diese erzwungene Wahl ist mit PR #142563, gemergt am 22. Oktober 2026, nicht mehr Pflicht.

Die alte Regel: ein delegation.model für jedes Kind

Das Kind-Modell war global in config.yaml festgenagelt — delegation.model, delegation.provider, delegation.base_url. Unter der Standard-Strategie hat delegate_task keinen Modell-Parameter pro Aufgabe, also läuft jeder Subagent in einem Batch auf derselben Route. Die Doku sagte es klar: Für eine qualitätskritische Subtask lässt du delegation.model in dieser Session entweder ungesetzt, oder du gibst die Arbeit an das Kanban-Board, das eine Modell-Überschreibung pro Aufgabe unterstützt.

Also traf jeder denselben Kompromiss: ein Modell der Mittelklasse festnageln und damit leben.

Die neue Regel: delegation.backend entscheidet, wie Arbeit geroutet wird

Die Änderung in einem Satz: Delegation ist zu einer pluggable Provider-Kategorie geworden, in derselben Form wie TTS, Bildgenerierung und Terminal-Backends. delegation.backend wählt die Strategie. default bedeutet genau das, was du hattest — ungesetzt oder default lässt das delegate_task-Schema und jede hermes-cli-Tool-Definition byte-identisch zu vorher.

Die beiden anderen Strategien kommen aus dem offiziellen Plugin advanced-delegation:

• model_map — du listest benannte Optionen (fast, deep, …), jede mit einer einzeiligen Beschreibung plus Provider und Modell, und das Modell wählt pro Aufgabe eine aus;
• profile_routes — jede Aufgabe läuft als eines deiner Hermes-Profile, mit dem Modell, den Credentials, den Skills und der Persona dieses Profils.

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      # optional; wird beim Spawn abgelehnt, wenn diese Route keine fast-Stufe hat
      default: fast                # optional: Option für Aufgaben, die keine setzen
    profile_routes:                # gelesen, wenn backend: profile_routes
      profiles:
        - name: coder
          description: Writes and refactors code; runs tests.

Die Beschreibungen sind keine Dekoration. Das Modell sieht immer nur die Namen und Beschreibungen, die du konfiguriert hast — nie die rohen Provider-, Modell- oder Key-Felder. Schreibst du „Cheap and quick; lookups, summaries“, bringst du ihm bei, wann es sparen soll; schreibst du „Slow and careful; hard debugging and design work“, bringst du ihm bei, wann es ausgeben soll.

Core behält in beiden Fällen den gesamten Lifecycle: Spawn, Isolation, Leaf-/Orchestrator-Rollen, Tiefe, Concurrency, Background-Units, Stop-Fan-out, Ergebnisse, output_schema, Fortschritt. Verschoben hat sich nur die Routing-Entscheidung.

Jedes geroutete Ergebnis trägt jetzt einen route-Receipt

Eine Aufgabe, die durch ein Backend lief, meldet, wo sie tatsächlich lief: das Backend, den Namen der Option oder des Profils und den Provider, das Modell, den Reasoning-Effort und die Speed-Stufe, die das Kind benutzt hat. Hat ein Fallback-Provider übernommen, ist fallback_activated true.

Das ist wichtiger, als es klingt. Vorher hast du das Modell des Kindes aus „ich habe delegation.model gesetzt“ abgeleitet. Jetzt meldet es zurück — wenn ein Batch plötzlich teuer wird, liest du den Receipt, statt zu raten.

Fehler sind laut, nie ein stiller Wechsel

Hier steckt der größte Teil der Arbeit in dieser PR:

• Fehlt das gewählte Backend (Plugin nicht installiert oder deaktiviert) oder meldet es, dass es nicht laufen kann, gibt delegate_task einen Tool-Fehler zurück, der das Backend und die Lösung nennt (Plugin installieren oder aktivieren, /delegation default oder hermes config set delegation.backend default). Es startet kein Subagent, und die Kinder laufen nie still auf der Standard-Route.
• Innerhalb eines Batches wird eine Aufgabe, die ihr Backend nicht routen kann — eine unbekannte Option, ein Parameter, den das gewählte Backend nicht nimmt, ein Profil, das nicht existiert, ein service_tier, das die Route nicht anbietet, ein unbekannter reasoning_effort, fehlende Credentials — allein abgelehnt. Ihr Ergebnis-Eintrag hat status: "error", den Grund und route.refused: true; die Geschwister laufen weiter.
• Zum Tool-Fehler wird der Aufruf erst, wenn jede Aufgabe abgelehnt wurde.
• Eine Modell-Route ohne eigene fallback_providers erbt delegation.fallback_providers; fallback_providers: [] auf der Route schaltet den Fallback für sie ab. Eine Profil-Route nutzt die eigene Fallback-Kette dieses Profils.

Eine Grenze, die man kennen sollte: Solange model_map oder profile_routes aktiv ist, sind delegation.model und delegation.provider inaktiv — die Routen entscheiden. Konfiguriere keine Optionen und wundere dich dann, warum der alte Pin plötzlich keine Rolle mehr spielt.

Umschalten und zurückschalten

Beide Strategien, der Slash-Command /delegation und hermes delegation config (Modell-Routen anlegen, bearbeiten und löschen, Profile auswählen) kommen im offiziellen Plugin:

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

Dann braucht das Umschalten keine Dateibearbeitung:

/delegation model_map               # nur diese Session
/delegation profile_routes --global # schreibt delegation.backend in config.yaml
/delegation default                 # zurück zur Standard-Strategie

Es gibt eine Feinheit, die die Doku ausdrücklich nennt: ein Session-Wechsel ändert das Routing, nicht das Tool-Schema. Die Parameter pro Aufgabe (option, profile) sind Teil des gecachten Prompts und folgen config.yaml, sie ändern sich also erst in der nächsten Session. Bis dahin kann das Modell noch den Parameter des vorherigen Backends senden — ein option: fast nach dem Wechsel zu profile_routes. So eine Aufgabe wird für sich abgelehnt, mit der Lösung in der Meldung: /delegation <backend> --global und dann /new (weil /new auf dem gespeicherten Backend startet), oder /delegation <saved backend>, um zurückzugehen. Sie läuft nie auf der Standard-Route des neuen Backends, nur um weiterzumachen.

Ohne das Plugin stellt hermes config set delegation.backend default das alte Verhalten wieder her.

Welche Strategie passt

• model_map — ein Credential-Satz, Geld nach Schwierigkeit aufgeteilt. Leichte Aufgaben gehen an ein billiges Modell, harte an ein starkes. Passt zu Batches, deren Subtasks sich stark in der Schwierigkeit unterscheiden: zehn Issues in einem Lauf beheben, zwanzig Recherche-Threads laufen lassen.
• profile_routes — das Kind wechselt die Identität. Jedes Profil trägt sein eigenes Modell, seinen Credential-Pool, seine SOUL.md und seine Terminal-Policy, was zu „diese Subagents sollen unter anderen Rechten laufen“ passt, zum Beispiel Code-Arbeit innerhalb einer restriktiven Terminal-Policy zu halten.

Eine Warnung kommt direkt aus der Doku und ist es wert, zitiert zu werden: Ein Profil in delegation.backends.profile_routes zu listen, erlaubt den Subagents dieses Profils, die Credentials, den Credential-Pool, die SOUL.md und die Terminal-Policy jenes Profils zu benutzen. Liste nur Profile, deren Keys und Terminal-Zugriff du diesem Agenten gern überlässt.

Release-Status

PR #142563 wurde am 22. Oktober 2026 nach main gemergt. Das Follow-up #142564 verschiebt die Standard-Strategie selbst in ein mitgeliefertes Plugin, und #143126 ergänzt die Delegation-Einstellungen im Desktop (Modus-Auswahl, Modell-Routen-Editor, Profil-Routen). Das jüngste Release ist v0.22.4 vom 21. Oktober, all das liegt heute also nur auf main und erreicht den Stable-Kanal mit dem nächsten Release. Wenn du jetzt umsteigst, beachte den Kanal: Patch-Releases tragen es noch nicht.

Wenn du die Live-Steuerung von Subagents (list/steer/stop) noch nicht benutzt hast, fang mit der Anleitung zur Subagent-Orchestrierung an. Für den kompletten delegation-Abschnitt ist die hermes config-Referenz schneller als der Quellcode. Die andere Hälfte des Routings pro Modell steht im model_overrides-Leitfaden, und die Plugin-Installation deckt der Plugin-Katalog-Leitfaden ab.