Afgelopen zomer opende ik in één maand vijf accounts bij LLM-providers. OpenAI, Anthropic, OpenRouter, Fireworks, Together. In oktober wist ik niet meer welke creditcard waarvoor werd afgeschreven. In december veranderde er eentje stilletjes de prijzen, en ik merkte het pas drie weken later toen de rekening binnenkwam.
Dit is de onglamoureuze waarheid over het draaien van wat dan ook bovenop LLM's in 2026: de providerdierentuin is een permanente toestand. Elke week verschijnen er nieuwe modellen. Prijzen verschuiven. Gratis tiers worden herschikt. Een model dat in maart state-of-the-art was, is in mei een voetnoot. Als je agentframework bij de installatie een provider voor je kiest, teken je ervoor om je setup elke paar maanden opnieuw op te bouwen.
Hermes Agent gokt vanaf dag één op het tegenovergestelde: de provider is een config-waarde, geen keuze die de architectuur voor je maakt. Drie features stapelen op elkaar om dit echt te laten werken.
De centrale router (v0.2.0)
De basis is één enkele aanroepplek. Bij de v0.2.0-lancering introduceerde het project een gecentraliseerde providerrouter — één call_llm() / async_call_llm()-functie waar elk onderdeel van de agent doorheen loopt. Vision, samenvatting, compressie, trajectopslag, de hoofdchatlus. Ze gaan allemaal door hetzelfde codepad.
Dat klinkt als een refactoringdetail totdat je probeert van provider te wisselen in een agent die dit niet heeft. In de meeste frameworks zijn er elf plekken die de LLM aanroepen, en elk leest credentials net iets anders. Je wijzigt de ene, vergeet de andere, en dingen gaan stuk op manieren die lastig op te merken zijn. Hermes maakte dat onmogelijk door er maar één plek van te maken.
De fallback-keten (v0.6.0)
Twee weken later voegde v0.6.0 de volgende laag toe: geordende fallback-providerketens. Je zet providers op volgorde in config.yaml, en wanneer je primaire een fout geeft — een 429 rate limit, een tijdelijke 500, een onbereikbaar endpoint — probeert Hermes automatisch de volgende in de keten.
Cruciaal: het is geordend, niet round-robin. Je kiest zelf een voorkeur en een backup. Een typische setup is OpenRouter als goedkope standaard, Anthropic direct als betrouwbare backup, en de gratis tier van Nous Portal als noodoplossing van laatste toevlucht. Als de bovenste in de keten een slechte dag heeft, merk je er niks van. De v0.6.0-release fixte tegelijk een subtiele bug: wisselen van provider via hermes model ruimt nu de oude api_mode op in plaats van chat_completions hard te coderen, waardoor Anthropic-compatibele endpoints na een wissel geen cryptische 404's meer teruggeven.
Credential pools (v0.7.0)
De veerkracht-release voegde de derde laag toe: credential pools binnen dezelfde provider. Het inzicht hier is dat "mijn primaire provider" en "de specifieke API-key die ik bij die provider heb" twee verschillende dingen zijn. Je hebt misschien drie Anthropic-keys — persoonlijk, team, en een backup op een tweede account — en je wilt dat Hermes altijd de minst belaste gebruikt.
Je configureert ze via de setupwizard of een credential_pool-blok, en Hermes kiest standaard de least_used key. Als een key 401 teruggeeft, roteert de pool automatisch naar de volgende en markeert de dode voor een resetvenster. De thread-safe implementatie betekent dat je de CLI, een Telegram-gateway en een cronjob tegen dezelfde pool kunt draaien zonder dat ze op elkaars tenen trappen. v0.7.0 zorgde er ook voor dat de poolstatus fallback-providerswitches overleeft, zodat een 429 op je primaire de kennis van de pool over welke keys moe zijn niet wegblaast.
Waarom de gelaagdheid ertoe doet
Elk van deze features lost een smal probleem op, maar de reden dat ze krachtig aanvoelen is dat ze samengaan zonder overlap:
- •De router laat je welke provider op één plek veranderen.
- •De fallback-keten laat je providerniveau-storingen afhandelen zonder te herstarten.
- •De credential pool laat je key-niveau-storingen en belasting binnen één provider afhandelen.
En vanuit de CLI laat hermes model je elk van deze lagen herconfigureren zonder bestanden met de hand te bewerken. Het netto-effect is dat wanneer een nieuw model verschijnt — wat het ook is, wie het ook uitbrengt, hoe het ook geprijsd is — de kosten van overstappen "één regel config aanpassen" zijn. Niet "mijn assistent opnieuw opbouwen." Voor een project dat vele generaties modellen gaat meemaken, is dat waarschijnlijk de enige architectuurbeslissing die er echt toe doet.