Nicht warten, bis Hermes abstürzt: 3-Ebenen-Modell-Fallback, der Aufgaben am Laufen hält

Wenn Menschen Hermes zum ersten Mal nutzen, fragen sie meist: Welches Modell ist stark genug? Nach einiger Zeit stellt sich eine andere Frage als viel ärgerlicher heraus: Kann das Modell eine Aufgabe zuverlässig bis zum Ende durchführen?

Stell dir vor: Du gibst Hermes einen lang laufenden Auftrag — Dokumente organisieren, eine Webseite verfolgen, einen Cron-Job ausführen, ein Skript schreiben oder einen Stapel Dateien analysieren. Die ersten 20 Minuten laufen reibungslos. Dann, kurz vor Schluss, siehst du:

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

Das ist der schlimmste Moment. Die Aufgabe ist bereits halb erledigt, der Kontext hat sich aufgebaut, Tool-Aufrufe wurden ausgeführt, und plötzlich ist das Modellkontingent aufgebraucht, die API wird gedrosselt oder der Anbieter hat Probleme. An dieser Stelle manuell das Modell zu wechseln bedeutet meist, den gesamten Kontext neu zu erklären.

Hermes kann nicht zuverlässig auf einem einzigen Modell, einem einzigen Schlüssel und einem einzigen Endpoint laufen. Ein robusterer Ansatz ist es, drei Fallback-Ebenen im Voraus vorzubereiten:

  1. Mehrere Schlüssel für denselben Anbieter
  2. Automatischer Fallback auf ein Backup-Modell, wenn das primäre Modell ausfällt
  3. Separater Fallback für Hilfsaufgaben wie Bilder, Web-Extraktion und Komprimierung

Gehen wir jede Ebene durch.

1. Warum lang laufende Aufgaben besonders anfällig für Ausfälle zur Laufzeit sind

In kurzen Gesprächen ist ein Modellfehler kein großes Problem. Du fragst, es scheitert, du versuchst es mit einem anderen Modell erneut.

Lang laufende Aufgaben sind anders. Hermes hat möglicherweise Dateien gelesen, Webseiten geöffnet, Befehle ausgeführt, Zwischenergebnisse generiert und läuft möglicherweise unbeaufsichtigt in einem Cron-Job. Wenn es zur Hälfte abbricht, verlierst du nicht nur die Antwort, sondern auch die bereits investierte Zeit, Token und den Aufwand für den Aufbau des Kontexts.

Die fünf häufigsten Fehlerquellen sind:

Status Bedeutung
429 Rate Limit: zu viele Anfragen in kurzer Zeit
402 Abrechnungs-, Guthaben- oder Kontingentproblem
500 / 502 / 503 Serverfehler des Anbieters
401 / 403 Schlüssel ungültig oder Berechtigungen falsch
404 / invalid response falscher Modellname, Endpoint oder Antwortformat

Diese Probleme werden nicht durch „ein intelligenteres Modell verwenden“ gelöst. Was du brauchst, ist, alternative Routen für Hermes im Voraus festzulegen.

Stell dir das primäre Modell als Hauptautobahn vor. Sie ist meist am schnellsten, aber wenn sie verstopft ist, solltest du nicht stillsitzen. Du brauchst Nebenstraßen, Ersatzfahrzeuge und Ersatzfahrer. Die drei Fallback-Ebenen in Hermes sind genau das.

2. Ebene 1: Mehrere Schlüssel für denselben Anbieter bereithalten

Die erste Ebene ist die einfachste und am häufigsten übersehene: Credential Pools.

Sie löst Probleme innerhalb desselben Anbieters: ein Schlüssel ist aufgebraucht, wird gedrosselt oder wird ungültig. Wenn dein Hauptmodell beispielsweise deepseek-v4-pro ist und du nur einen DeepSeek-API-Schlüssel hast, hat Hermes keine andere Wahl, als einen Fehler auszugeben, sobald dieser Schlüssel erschöpft oder gedrosselt ist.

Wenn du mehrere Schlüssel unter demselben Anbieter hinzufügst, kann Hermes auf einen gesunden Schlüssel wechseln und fortfahren.

Aktuelle Anmeldeinformationen prüfen:

hermes auth list

Einen zweiten DeepSeek-Schlüssel hinzufügen:

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

Wenn du auch OpenRouter nutzt, füge dort ebenfalls einen zweiten Schlüssel hinzu:

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

Der Wert hier ist praktisch:

  • Gleiches Hauptmodell
  • Gleicher Anbieter
  • Gleicher Modellstil
  • Nur der Schlüssel ändert sich unter demselben Anbieter

Empfehlung: Wer regelmäßig lang laufende Aufgaben ausführt, sollte mindestens zwei Schlüssel für den Hauptanbieter haben. Das lohnt sich besonders, wenn du Hermes Cron für tägliche Berichte, Monitoring oder Dokumentenorganisation nutzt.

3. Wie man Schlüssel rotiert, damit einer nicht leer gezogen wird

Nachdem du mehrere Schlüssel hinzugefügt hast, musst du entscheiden, wie du sie nutzen willst. Hermes unterstützt Rotationsstrategien pro Anbieter. Kurz gesagt: Nutzt du den ersten Schlüssel, bis er ausfällt, oder rotierst du durch die Schlüssel?

Beispielkonfiguration:

credential_pool_strategies:
  deepseek: round_robin
  openrouter: least_used

Häufige Strategien:

Strategie Verhalten
fill_first Nutze den ersten Schlüssel, bis er ausfällt, dann wechseln
round_robin Schlüssel nacheinander durchrotieren
least_used Bevorzuge den Schlüssel mit der bisher geringsten Nutzung
random Wähle einen Schlüssel zufällig aus
  • Wenn du nur zwei Ersatzschlüssel hast und eine gleichmäßige Nutzung möchtest, verwende round_robin.
  • Wenn du mehrere Schlüssel mit unterschiedlichen Kontingenten hast und verhindern möchtest, dass einer zu früh erschöpft ist, probiere least_used aus.

Ein kleiner Hinweis: Das Wechseln von Schlüsseln kann den Prompt-Cache ungültig machen. Wenn Hermes zu einem neuen Schlüssel wechselt, hat dieser Schlüssel möglicherweise nicht den vorherigen Kontext-Cache, sodass die nächste Anfrage möglicherweise den vollständigen Kontext neu lesen muss. Das kostet zusätzliche Eingabetokens.

Credential Pools geht es also nicht wirklich um Kosteneinsparung. Es geht darum, die Aufgabe am Leben zu erhalten. Für lang laufende Aufgaben ist es besser, etwas mehr zu zahlen, als den gesamten Lauf zu verlieren.

4. Ebene 2: Automatisch auf ein Backup-Modell zurückgreifen

Ebene 1 löst Schlüsselprobleme innerhalb eines Anbieters. Ebene 2 löst das größere Problem: Der gesamte Anbieter oder das primäre Modell wird instabil.

Angenommen, dein Hauptmodell ist deepseek-v4-pro. Wenn der DeepSeek-Endpoint überlastet ist oder dein Kontokontingent erschöpft ist, hilft der Wechsel zu einem anderen DeepSeek-Schlüssel möglicherweise nicht, weil das Problem auf der Service-Seite oder auf Kontoebene liegt.

Dann sind Fallback-Provider wichtig.

Verwende die interaktive Konfiguration:

hermes fallback

Oder bearbeite ~/.hermes/config.yaml direkt. Hier ist ein praktisches Beispiel:

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

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

Das bedeutet:

  1. Normalerweise deepseek-v4-pro verwenden
  2. Bei DeepSeek-Fehler zu GLM 5.2 wechseln
  3. Wenn GLM 5.2 auch ausfällt, zu Kimi K2.7 wechseln

Modellnamen müssen mit den IDs übereinstimmen, die in deiner tatsächlichen Anbieterkonsole, hermes model oder der Modellliste angezeigt werden. Die anbieterspezifische Benennung variiert, also überprüfe immer die genaue ID.

Dieses Setup ist ideal für lang laufende Aufgaben: ein Stapel Materialien organisieren, einen 30-minütigen Hintergrundjob ausführen oder eine Codebase analysieren. Wenn das primäre Modell hickt, läuft Hermes weiter, ohne dass du eingreifen musst.

5. Ebene 3: Auch Hilfsaufgaben erhalten einen eigenen Fallback

Viele Menschen konfigurieren den Fallback nur für das Haupt-Chat-Modell. Aber Hermes verlässt sich auch auf viele Hilfsaufgaben:

  • Bildanalyse
  • Web-Extraktion
  • Kontextkomprimierung
  • Sitzungstitel-Generierung
  • Skill-Suche
  • MCP-Hilfsaktionen
  • Befehlsfreigabe-Entscheidung

Diese Aufgaben können ebenfalls Modelle aufrufen. Wenn sie keinen Fallback haben, können sie den gesamten Lauf ausbremsen.

Wenn du Hermes beispielsweise bittest, eine Webseite zu lesen, führt es möglicherweise zuerst eine Web-Extraktion durch; wenn der Kontext zu lang wird, komprimiert es ihn; wenn du einen Screenshot hochlädst, ruft es möglicherweise ein Vision-Modell auf.

Du kannst für diese Aufgaben separat Fallback konfigurieren:

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

Das bedeutet:

  • Die Kontextkomprimierung startet mit GLM 5.2, fällt auf Kimi K2.7 zurück und schließlich auf DeepSeek
  • Die Web-Extraktion startet mit Kimi K2.7 und fällt dann auf GLM 5.2 zurück

Hilfsaufgaben schätzen Stabilität, niedrige Kosten und angemessene Geschwindigkeit. Du kannst das stärkste Modell für die Hauptaufgabe reservieren und günstigere, schnellere Modelle für Extraktion, Komprimierung und Titelgenerierung verwenden. Aber wenn die Aufgabe kritisch ist — Vertragsprüfung, langkontextige Codebase-Organisation oder Zusammenfassungen von Kundenmaterialien — lohnt es sich, den Hilfsaufgaben einen eigenen Fallback zu geben.

6. Verringere die Wiederholungsversuche, um schneller zum Backup zu wechseln

Hermes wiederholt standardmäßig einige Male, bevor der Fallback ausgelöst wird. Das ist sinnvoll, da einige 429- oder Netzwerkfehler nur kurze Aussetzer sind. Einige Sekunden zu warten kann die Kosten und den Stilwechsel eines Modellwechsels vermeiden.

Aber wenn ein Anbieter über längere Zeiträume häufig instabil ist, kannst du Hermes schneller wechseln lassen:

agent:
  api_max_retries: 1

Oder noch aggressiver:

agent:
  api_max_retries: 0

Vorgeschlagene Einstellungen:

  • Gelegentlicher Chat: behalte den Standardwert bei
  • Lang laufende Aufgaben: erwäge 1
  • Unbeaufsichtigte Cron-Jobs: erwäge 0 oder 1
  • Kostenempfindliche Aufgaben: sei nicht zu aggressiv

Warum nicht immer auf 0 setzen? Jeder Anbieterwechsel kann Caches ungültig machen, und bei langkontextigen Aufgaben können die Eingabetokens deutlich steigen. Dieser Parameter ist also nicht „kleiner ist immer besser“. Ein ausgewogener Ansatz ist, die Wiederholungen für wichtige lang laufende Aufgaben zu reduzieren, während der Standardwert für gewöhnliche Aufgaben beibehalten wird.

7. Eine praktische Fallback-Konfiguration für lang laufende Aufgaben

Für eine Umgebung, die regelmäßig lang laufende Hermes-Aufgaben ausführt, hier ein mögliches Design:

  • Primär: deepseek-v4-pro für langen Kontext und allgemeine Leistung
  • Erster Fallback: glm-5.2 für lang laufende Aufgaben, Code, Reasoning und komplexe Workflows
  • Zweiter Fallback: kimi-k2.7-code für Codefortsetzung, Projektverständnis und Verarbeitung langer Materialien

Beispielkonfiguration:

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

Nach dem Speichern Gateway neu starten:

hermes gateway restart

Dann die Konfiguration überprüfen:

hermes config check

Wenn du YAML nicht per Hand schreiben möchtest, starte mit den interaktiven Befehlen:

hermes model
hermes fallback
hermes auth list

Empfehlung für Einsteiger: Konfiguriere nicht auf einmal alle Modelle. Mache es in drei Schritten:

  1. Füge einen zweiten Schlüssel für deinen Hauptanbieter hinzu
  2. Füge einen Fallback-Provider hinzu
  3. Konfiguriere schließlich den Fallback für compression und web_extract

Das erleichtert die Fehlersuche.

8. Welche Aufgaben profitieren am meisten von diesem Drei-Ebenen-Setup

Nicht jede Aufgabe braucht diese Komplexität. Wenn du nur ein paar gelegentliche Fragen stellst, sind drei Fallback-Ebenen übertrieben. Aber die folgenden Szenarien lohnen sich, frühzeitig zu konfigurieren:

  • Hermes Cron-Scheduled-Jobs
  • Lang laufende Dokumentenorganisationsaufgaben
  • Codebase-Analyseaufgaben
  • Mehrseitige Suche und Extraktion
  • Aufgaben, die häufig lange Kontexte komprimieren
  • Kundenprojektaufgaben
  • Unbeaufsichtigte Hintergrund-Workflows

Cron-Jobs sind das klassische Beispiel. Du könntest Hermes bitten, jeden Morgen KI-Nachrichten zusammenzufassen oder stündlich eine Website zu überprüfen. Du bist nicht an deinem Computer, wenn es läuft, und wenn das Modellkontingent aufgebraucht ist, schlägt der Job fehl. Mit Credential Pools und Fallback hat die Aufgabe einen weiteren Weg nach vorn.

Codebase-Analyse ist ein weiterer wichtiger Fall. Hermes liest viele Dateien und baut Projekt-Kontext auf. Wenn das Modell an diesem Punkt ausfällt, ist ein Neustart von vorne sehr verschwenderisch. Fallback ermöglicht es, aus dem bestehenden Kontext fortzufahren.

Wichtige Erkenntnisse

Merke dir diesen Satz: Konfiguriere für lang laufende Hermes-Aufgaben den Modell-Fallback, bevor etwas kaputt geht, nicht danach.

Die drei praktischsten Ebenen sind:

  1. Credential Pools: Halte mehrere Schlüssel für denselben Anbieter bereit und rotiere sie automatisch bei Rate Limits oder Kontingentproblemen.
  2. Fallback Providers: Wechsle automatisch zu einem Backup-Anbieter und -Modell, wenn das primäre Modell ausfällt.
  3. Auxiliary Fallback: Gib Hilfsaufgaben wie Web-Extraktion, Bildanalyse und Kontextkomprimierung eigene Backup-Routen.

Eine solide Modellkombination könnte sein:

  • Primär: deepseek-v4-pro
  • Erster Fallback: glm-5.2
  • Zweiter Fallback: kimi-k2.7-code

Wichtige Befehle zum Merken:

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

Eine letzte Erinnerung: Fallback geht darum, Aufgaben am Laufen zu halten, nicht um Perfektion. Die Kosten können Cache-Invalidierung, höherer Token-Verbrauch und leichte Änderungen im Antwortstil sein. Es eignet sich am besten für wichtige lang laufende Aufgaben, geplante Jobs und unbeaufsichtigte Workflows. Für gewöhnlichen Chat halte es einfach. Wenn du Hermes wirklich brauchst, verlasse dich nicht auf ein einziges Modell.