Letzten Sommer habe ich in einem Monat fünf LLM-Provider-Accounts eröffnet. OpenAI, Anthropic, OpenRouter, Fireworks, Together. Im Oktober hatte ich keine Ahnung mehr, welche Kreditkarte wo belastet wurde. Im Dezember hat einer von ihnen still und leise die Preise geändert — gemerkt habe ich es drei Wochen später, als die Rechnung kam.
Das ist die unspektakuläre Wahrheit über alles, was 2026 auf LLMs aufsetzt: Der Provider-Zoo ist ein Dauerzustand. Jede Woche erscheinen neue Modelle. Preise bewegen sich. Gratis-Tiers werden umgeschichtet. Ein Modell, das im März State of the Art war, ist im Mai eine Fußnote. Wenn dein Agent-Framework den Provider bei der Installation für dich festlegt, hast du dich darauf eingelassen, dein Setup alle paar Monate neu zu bauen.
Hermes Agent setzt seit Tag eins auf das Gegenteil: Der Provider ist ein Konfigurationswert, keine Entscheidung, die die Architektur für dich trifft. Drei Features stapeln sich übereinander, damit das wirklich funktioniert.
Der zentrale Router (v0.2.0)
Das Fundament ist ein einziger Aufrufpunkt. Beim Launch von v0.2.0 führte das Projekt einen zentralisierten Provider-Router ein — eine call_llm() / async_call_llm()-Funktion, durch die jeder LLM-Aufruf im Agenten läuft. Vision, Zusammenfassung, Komprimierung, Trajectory-Speicherung, die Chat-Hauptschleife — alles geht denselben Codepfad.
Das klingt nach einem Refactoring-Detail, bis du versuchst, in einem Agenten ohne so etwas den Provider zu wechseln. In den meisten Frameworks gibt es elf Stellen, die das LLM anrufen, und jede liest Credentials etwas anders aus. Du änderst eine, vergisst eine andere, und Dinge gehen auf Arten kaputt, die schwer zu bemerken sind. Hermes hat das unmöglich gemacht, indem es nur eine einzige Stelle gibt.
Die Fallback-Kette (v0.6.0)
Zwei Wochen später legte v0.6.0 die nächste Schicht drauf: geordnete Fallback-Provider-Ketten. Du listest Provider in config.yaml auf, und wenn dein primärer auf einen Fehler läuft — ein 429 Rate Limit, ein vorübergehender 500er, ein nicht erreichbarer Endpoint — probiert Hermes automatisch den nächsten in der Kette.
Entscheidend: Die Reihenfolge ist fest, kein Round-Robin. Du legst eine Präferenz und ein Backup fest. Ein typisches Setup: OpenRouter als günstiger Standard, Anthropic direkt als zuverlässiges Backup und Nous Portals Gratis-Tier als allerletzter Notanker. Wenn der erste in der Kette einen schlechten Tag hat, merkst du nichts davon. Das v0.6.0-Release hat gleichzeitig einen subtilen Bug behoben: Provider-Wechsel über hermes model löschen jetzt den veralteten api_mode, statt ihn auf chat_completions festzuschreiben — Anthropic-kompatible Endpoints liefern nach einem Wechsel also keine kryptischen 404er mehr.
Credential-Pools (v0.7.0)
Das Resilience-Release brachte die dritte Schicht: Credential-Pools innerhalb desselben Providers. Die Erkenntnis dahinter: „Mein primärer Provider" und „der konkrete API-Key, den ich bei diesem Provider habe" sind zwei verschiedene Dinge. Vielleicht hast du drei Anthropic-Keys — privat, Team und einen Backup auf einem zweiten Account — und willst, dass Hermes immer den am wenigsten beanspruchten nimmt.
Du konfigurierst sie über den Setup-Wizard oder einen credential_pool-Block, und Hermes wählt standardmäßig den least_used-Key. Gibt ein Key 401 zurück, rotiert der Pool automatisch zum nächsten und markiert den toten für ein Reset-Fenster. Die thread-sichere Implementierung erlaubt es dir, CLI, Telegram-Gateway und einen Cronjob gleichzeitig gegen denselben Pool laufen zu lassen, ohne dass sie sich in die Quere kommen. v0.7.0 stellt außerdem sicher, dass der Pool-Zustand Fallback-Provider-Wechsel überlebt — ein 429 auf deinem primären Provider löscht nicht das Wissen des Pools darüber, welche Keys gerade erschöpft sind.
Warum die Schichtung zählt
Jedes dieser Features löst ein konkretes Problem, aber der Grund, warum sie sich mächtig anfühlen, ist, dass sie sich ohne Überlappung zusammenfügen:
- •Der Router lässt dich an einer Stelle ändern, welchen Provider du nutzt.
- •Die Fallback-Kette lässt dich Provider-Ausfälle behandeln, ohne neu zu starten.
- •Der Credential-Pool lässt dich Key-Ausfälle und Last innerhalb eines Providers abfangen.
Und über die CLI lässt hermes model dich jede dieser Schichten umkonfigurieren, ohne Dateien von Hand zu editieren. Unterm Strich: Wenn ein neues Modell auftaucht — egal welches, egal von wem, egal was es kostet — belaufen sich die Migrationskosten auf „eine Konfigurationszeile ändern". Nicht „meinen Assistenten umbauen". Für ein Projekt, das viele Modellgenerationen überleben will, ist das wahrscheinlich die einzige Architekturentscheidung, die wirklich zählt.