Wer schon mal jemandem einen Self-hosted-Agent eingerichtet hat, kennt die folgende Zeitlupenszene mindestens einmal aus eigener Erfahrung.
Ein Freund fragt, wie er Hermes zur Websuche bringt. Du erklärst es: Bei Firecrawl anmelden, im Dashboard den API-Key rausfischen, ihn in .env einsetzen, hermes tools laufen lassen, das Häkchen setzen. Macht er. Funktioniert. Zwei Tage später möchte er Bildgenerierung. Du erklärst es: Bei FAL anmelden, API-Key aus dem Dashboard fischen, in .env einsetzen, hermes tools laufen lassen, Häkchen setzen. Er sieht langsam müde aus. Beim nächsten Mal, wenn er TTS will, fragt er nicht mehr.
Die Reibungssteuer eines Self-hosted-Agents hat nichts mit dem Agent zu tun. Sie besteht aus Key-Tänzen pro Tool, Dashboards pro Tool und Erneuerungskalendern pro Tool. Am 16. April 2026 — drei Tage nach v0.9.0 — hat v0.10.0 für alle mit einem Nous-Portal-Abonnement einen Brocken davon weggenommen.
Nach Codezeilen ist das Release klein — gut 180 Commits in drei Tagen. Aber das eine Feature, das in diesen drei Tagen landet, ist das, womit v0.10 in Erinnerung bleiben wird: das Nous Tool Gateway.
Was „managed tool" eigentlich heißt
Das Nous Tool Gateway ist ein serverseitiger Multiplexer. Der Agent auf deiner Maschine ruft weiterhin web_search oder generate_image genauso wie früher. Was sich ändert: Der Aufruf landet jetzt auf dem Gateway von Nous, das den vorgelagerten API-Key hält und gegen dein Portal-Abo abrechnet — nicht gegen dich.
Die erste Welle sind vier Tools, direkt aus den Release Notes:
- •Websuche über Firecrawl
- •Bildgenerierung über FAL mit dem Modell FLUX 2 Pro
- •Text-to-Speech über OpenAI TTS
- •Browserautomatisierung über Browser Use
Das sind keine neuen Tools. Das sind die Tools, die du schon immer selbst hättest zusammenstecken können — mit vier separaten Accounts und vier separaten .env-Zeilen. Was sich in v0.10.0 ändert, ist nur dies: Du musst es nicht mehr.
Du aktivierst pro Tool ein Opt-in über die neuen use_gateway-Einstellungen, die hermes model freilegt. Wenn für ein Tool ein direkter API-Key konfiguriert ist, bevorzugt die Runtime den weiterhin — das Gateway ist Fallback, keine Übernahme. Die Wahl ist auf der Ebene des einzelnen Tools, nicht der Installation.
Die Umgebungsvariable, die auf dem Weg zur Tür gestorben ist
Wer aus der v0.8/v0.9-Linie kommt, erinnert sich vermutlich an HERMES_ENABLE_NOUS_MANAGED_TOOLS. v0.10.0 löscht sie. Das Abonnement selbst ist jetzt das Signal: Du loggst dich am Portal ein, das Gateway leuchtet auf, die Tools laufen. Kein Toggle zum Merken, keine .env-Zeile, die zwischen Maschinen synchronisiert werden müsste.
hermes tools und hermes status sind beide gateway-bewusst geworden. Das erste zeigt dir auf einen Blick, welche Tools direkt, welche managed und welche aus sind; das zweite bestätigt die Gateway-Verbindung selbst. Zwei kleine Commands, die die Frage „Welcher Key macht gerade was?" auf eine einzige Output-Zeile zusammenstauchen.
Warum das größer ist, als es klingt
Die Reibungssteuer, von der ich oben rede, taucht in keinem Benchmark auf. Niemand hat einen Graphen über „Minuten verbrannt, weil ein Freund Firecrawl einrichten musste" gezeichnet. Aber alle, die einen Self-hosted-Agent betreiben, zahlen sie — und die meisten geben irgendwo beim fünften oder sechsten Tool auf, weil der Grenznutzen unter den Grenzaufwand fällt.
Für Hobbyisten ist die Steuer einfach nervig. Für ein kleines Team, das Hermes auf einer geteilten VPS fährt, wird die Steuer zur Eigentumsfrage: Wer ist der konkrete Mensch, dem die Firecrawl-Rechnung gehört, und was passiert mit der Websuche, wenn der die Firma verlässt?
Das Gateway frisst die ganze Oberfläche auf einen Schlag. Ein Abo, vier Tools, ein Ort, an dem die Rechnung gepflegt wird. Es ist derselbe Deal, den du machst, wenn du eine Datenbank hinter einen Managed Service steckst — du gibst etwas Kontrolle ab und bekommst dafür einen Sonntagnachmittag zurück.
Es gibt einen Preis, und die Release Notes papieren ihn nicht zu. Wer übers Gateway routet, routet über Nous — und Nous sieht damit Query-Metadaten, die es vorher nicht gesehen hat. Genau deshalb ist das Gateway pro Tool opt-in: Der Deal ist nicht unbedingt. Wenn du es bei einem bestimmten Tool nicht willst, ist dein direkter API-Key noch da und wird weiter benutzt. Der Punkt ist: Das ist jetzt eine Entscheidung, die du triffst, nicht ein Ring, durch den du springen musst, um überhaupt entscheiden zu dürfen.
Der Rest, in Kürze
v0.10.0 ist ein Tool-Gateway-fokussiertes Release. Eine TUI-Neuschreibung steckt hier nicht drin — die kommt in v0.11.0. Eine neue Chat-Plattform auch nicht — die Welle startet ab v0.12.0 neu. Trotzdem landen über 180 Commits quer durch Agent-Core, Gateway, CLI und Tool-Infrastruktur. Das vollständige Diff zwischen v2026.4.13 und v2026.4.16 steht auf GitHub, falls du jede Zeile sehen willst.
Die Schlagzahl macht weiter. Drei Tage nach v0.9.0, ein großes neues Feature, eine still beerdigte Deprecation, ohne dass jemand hingeschaut hätte.
---
Was ich an v0.10.0 spannend finde, ist, wie klein es nach Codezeilen ist — verglichen damit, wie groß das ist, was es daran ändert, wer Hermes überhaupt fahren kann. v0.9.0 hat drei Plattformen gesetzt. v0.10.0 hat null gesetzt — aber die Kosten dafür, die Tools, die du eh schon hattest, zu betreiben, soweit gesenkt, dass eine ganze Klasse Nutzer im Stil von „aufgegeben, weil die Keys zu viel Theater waren" wiederkommt.
Wenn man den Release-Kalender aus diesem Zeitfenster aufklappt, sieht man ein Muster: Die Hälfte der Versionen häuft Fähigkeiten an, die andere Hälfte trägt Reibung ab. v0.10.0 fällt klar in die zweite Kategorie. v0.12.0, in zwei Wochen, wird vom gleichen Typ sein — dann taucht der Autonomous Curator auf und beschneidet im Schlaf deine Skill-Bibliothek. Die Schlagzahl lässt das Projekt schnell aussehen. Die Form — Capability-Woche, Friction-Woche, Capability-Woche — lässt es sich tragbar anfühlen.