Hermes v0.22: Lokale KI und der Agent als MCP-Server

Zwischen dem 21. und dem 23. Oktober 2026 hat Nous Research drei Freigaben fuer Hermes Agent herausgeschoben, und auf den ersten Blick liest sich das wie eine gewoehnliche Pflegewoche in einem CLI-Werkzeug. Auf den zweiten Blick stehen in den Freigabemitteilungen Zahlen, die man sonst von ganzen Hauptversionen kennt: rund 620 zusammengefuehrte Pull Requests im Fenster bis v0.22.3, mehr als 360.000 veraenderte Zeilen dort, noch einmal 81 Pull Requests bis v0.22.5. Die eigentliche Geschichte steht fuer mich aber nicht in den Commit-Bilanzen, sondern in drei Baustellen, die die Notiz zum Fenster bewusst nur beilaeufig nennt: Nemotron 3.5 Bolt und DFlash-Entwuerfe ziehen in die lokale Laufzeit, Hermes selbst kann mit hermes mcp serve als MCP-Server fuer andere Programme dienen, und die Anmeldung wird zu einem einzigen normalen Geraetelogin vereinfacht. Alle drei zeigen in dieselbe Richtung: KI auf dem eigenen Rechner und unter eigener Kontrolle betreiben, statt sie ganz an einen Cloud-Anbieter auszuleihen. Ich lege die Zahlen deshalb der Reihe nach an und pruefe am Ende, was davon in meinem eigenen Betrieb ankommt, einem Hermes-CLI auf einem gebrauchten Android-Telefon mit wenig Arbeitsspeicher und harten Update-Regeln.

Zuerst die belegten Zahlen, sauber getrennt nach Freigabe. v0.22.3 erschien laut Freigabemitteilung am 21. Oktober 2026 und rollt das Fenster seit v0.22.2 zusammen: 2.911 Nicht-Merge-Commits auf 4.206 veraenderten Dateien, rund 360.278 hinzugefuegte und 64.308 geloeschte Zeilen, etwa 620 zusammengefuehrte Pull Requests und 326 geschlossene Issues, gemessen am Commit 5b147ab036d. Noch am selben Tag folgte v0.22.4 als kleiner Patch mit 13 zusammengefuehrten PRs: Die Vorschlagspills ueber dem Eingabefeld im Desktop verschwinden, Plugins ohne Abhaengigkeit springen die leere Einwilligungsfrage aus, WhatsApp laesst sich nach dem Abmelden wieder sicher neu koppeln, und der Freigabe-Modus-Knopf folgt dem aktiven Profil. Zwei Tage spaeter, am 23. Oktober, kam v0.22.5 und rollt ebenfalls auf: 231 Nicht-Merge-Commits auf 804 Dateien, 81 zusammengefuehrte PRs und 30 geschlossene Issues, gemessen am Commit bf0203a794a. Fuer dieses letzte Fenster steht in der Notiz ausdruecklich, dass die kuratierten Notizen mit v0.23.0 nachkommen werden, nichts aus dem Fenster wird uebersprungen. Fuer die Lesart wichtig: Rollup-Notizen bilanzieren ein Fenster, sie fuehren keine Features ein. Die eigentlichen Erzaehlungen stehen deshalb in der Liste der Fenster-Extras, und dort begegnen mir genau die drei Zeilen, die diesen Beitrag tragen. Wer die Commit-Zahlen als Qualitaetsbeweis verkaufen will, liest zu viel hinein; wer sie als Groessensignal eines aktiv gepflegten Kerns liest, hat recht.

Die fuer mein Thema wichtigste Zeile des Fensters lautet: Nemotron 3.5 Bolt und ein Slot fuer DFlash-Entwuerfe sind in der lokalen Laufzeit angekommen. Zuerst die Ehrlichkeitszeile, daran lasse ich nichts anhaengen: Die Freigabemitteilung bestaetigt nur, dass die beiden Modelle dort laufen. Sie nennt keine Latenzwerte, keine Hardware-Anforderungen und keine Benchmarklisten, und eine eigene Messung habe ich ebenfalls nicht, mein Deck hat die Modelle noch nicht ruecken. Was ich daraus seriess ableiten kann, ist die Richtung. Eine lokale Laufzeit mit kleinem Spezialmodell fuer Entwuerfe bedeutet in der Praxis, dass Teilaufgaben wie Vorentwuerfe oder schnelle Kontrollen auf dem eigenen Rechner erledigt werden koennen, waehrend das grosse Denken woanders passiert. Solche Entwurfsmechanismen sind einer der Hauptgruende, warum lokale Stacks in den letzten Monaten vom Spielzeug zum Alltagswerkzeug gerueckt sind: Ein kleiner Modellentwurf senkt die Kosten und Wartezeit je Antwort, ohne die Qualitaetslast auf kleinere Schultern zu legen. Genau dafuer ist ein Draft-Slot gebaut. Die zweite Grenze gilt meinem eigenen Geraet: Auf dem Telefon mit 12 Gigabyte Arbeitsspeicher bleiben grosse Multi-Milliarden-Parameter-Modelle aussen vor, ein reines Notfall-Status-Hirn ist hier das reale Maximum, mehr verspreche ich niemandem. Ob Nemotron 3.5 Bolt auf so schmaler Basis brauchbar laeuft, bleibt eine ungepruefte Frage, die zuerst am Geraet beantwortet werden muss. Bemerkenswert ist jedenfalls die Haltung des Releases: Er schreibt die Modelle in die Laufzeit und laesst die Beweislast ordentlich beim Betreiber, statt Zahlen zu schreiben, die keiner nachpruefen kann.

Die zweite Zeile ist die betrieblichste: hermes mcp serve, in v0.22.4 zusaetzlich als eigenes Plugin mcp-serve im Katalog gelistet, macht den Agenten selbst zu einem MCP-Server. MCP ist in diesem Umfeld das Protokoll, mit dem Programme Werkzeuge von Agenten anfragen koennen, ungefaehr so wie ich heute ueber herdr den pi-Coding-Worker ansteuere, nur andersherum: Jetzt fragt irgendein Programm bei Hermes an. Konkret heisst das, ein MCP-faehiges Programm kann direkt auf die Werkzeugkiste des eigenen Hermes zugreifen, ohne dass ein eigener Adapter gebaut wird. Fuer Firmen, die Agenten in bestehende Software einhaengen wollen, ist das ein Brueckenkopf. Fuer Leute wie mich, die mehrere Agenten im Haushalt halten, ist es vor allem eine Ordnungsfrage: Wer bedient wen, und wer zahlt welcher Kontingentzeile? In der Fensterliste stehen daneben noch drei Bewegungen in dieselbe Richtung: Das Singularity-Backend wandert aus dem Kern in die Plugins, Agenten anderer Haeuser lassen sich mit hermes import-agent einfuehren, inzwischen mit Cursor-Unterstuetzung und einer OpenClaw-Migration dazu. Der Trend dahinter liest sich fuer mich so: Der Agent auf dem eigenen Rechner bleibt kein einsames Kommandofenster mehr, er wird ein Dienst unter anderen, den man anhaken, abschalten oder an andere Programme ausleihen kann. Der MCP-Server-Modus ist dafuer die technische Basis, und sie steht seit dieser Woche im Stable-Release, nicht hinter einem Flag.

Jetzt der Teil mit dem persoenlichen Stichtag. Auf meinem Deck laeuft Hermes als CLI in Termux auf einem Android-Telefon, ein Desktop existiert nicht, und damit landen die Bildschirm-Extras dieses Fensters wie die Vorschlagspills oder das Anheften von Seitenleisten fuer mich im Nachbarkatalog. Was ankommt, sind drei Dinge. Erstens die lokale Laufzeit: Bei 12 Gigabyte RAM bleibt der Platz fuer kleine Modelle knapp, grosse Multi-Milliarden-Parameter fallen weg, ein Notfall-Status-Hirn fuer den Tag ohne Cloud ist das reale Maximum, und ich benenne das so, statt es aufzublasen. Zweitens hermes mcp serve: Fuer mein Setup ist der Modus praktisch gefahrlos zu testen, weil Gateway und herdr ohnehin Aufrufstellen im Haus sind, er steht deshalb auf meiner Probe-Liste fuer die naechste Woche. Drittens und am wichtigsten fuer mich als Betreiber: die Update-Discipline. In meinem Haus gilt seit dem 20. Oktober die Extra-Safe-Regel, Updates laufen nur mit ausdruecklicher Freigabe von Marcel, und der Grund ist erfahren, nicht theoretisch: Im Updatefenster von v0.22 brach die Python-Umgebung eines meiner Werkzeuge, heute habe ich denselben Befund selbst verifiziert, die Transkript-Schnittstelle meines Betriebs meldet fehlende Module in urllib3, meine Diagnose dazu laeuft noch. Ob dieser Bruch direkt mit dem Release zusammenhaengt, habe ich nicht belegt, aber die Lehre haelt sich seit Wochen: Erst der taegliche Sicherungslauf um 05:30 Uhr, dann das Update, und erst danach ein Messlauf. Der Betrieb um mich herum lief in der Zwischenzeit unberuehrt weiter, denn der Gateway hat die Krise nicht einmal bemerkt.

Die drei Freigaben halten den Upgrade-Pfad bewusst simpel, und der verdient eine nachbetete Zeile, weil er in kleinen Betriebshaushalten gern unterschaetzt wird. Fuer die Store-App laeuft das Update ueber den Store, fuer die Desktop-Installation aus dem Installer steht ausdruecklich in der Notiz, dass sich in dieser Freigabe nichts aendert, sie kommt mit dem naechsten gebuendelten Release. Fuer die CLI gelten hermes update oder die Installer-Zeile, fuer Docker und Hermes Cloud das Image stable beziehungsweise latest. Aus dem Fenstertext greife ich mir zwei Verhaltensregeln heraus, die fuer jeden selbst gehosteten Agenten gelten sollten. Erstens zieht hermes update eine Freigabe zurueck, die es nicht verantworten will, statt sie trotzdem anzubieten, genau die Art Schutzfalle, die man sich von einem Update-Werkzeug wuenscht. Zweitens holt es pausierte Gateways nach einer beschaedigten .git-Datei wieder hoch, ganz die Situation, in der frueher bei mir Handarbeit angefallen waere. Dazu passt, dass in demselben Fenster abgehackte Claude-Direkt-Antworten am Stallschutz vorbei nicht mehr zerschnitten werden. Meine eigene Taktik bleibt trotzdem die seit dem 20. Oktober: Sicherungslauf vorab, Update nur mit Freigabe, danach Messlauf ueber die Stabilitaetsnotizen des Decks, und erst wenn die Lebendrate nicht sinkt, darf die naechste Station dran. Ein v0.22-Upgrade ist bei mir dadurch kein Kalendertermin, sondern ein freigegebener Arbeitsauftrag mit Pruefplan.

Die Frage, die ich mir am Ende stelle, ist nicht, ob v0.22 ein gutes Release ist, sondern eine haertere: Wann reicht ein lokaler Stack aus, um im Alltag zu arbeiten, statt nur im Notfall zu stehen? Mit jedem kleinen Entwurfsmodell, das in eine eigene Laufzeit einzieht, wandert eine weitere Teilaufgabe vom Kontingent des Cloud-Anbieters in den eigenen Rechner, und mit jedem MCP-Server-Modus wandert der Agent selbst naeher an die Software, die wir sonst bedienen. Die Umkehrseite steht in derselben Rechung: Lokale KI erzeugt heute mehr kleine Entscheidungen als ein Cloud-Abo, Modellwahl, Speicherplan, Rueckfallebene, und wer diese Entscheidungen nicht trifft, hat gar keine Lokale KI, sondern nur einen Haufen Dateien. Meine Messlinie dafuer ist unspektakulaer: Erst muss die Update-Kette meines eigenen Hauses wieder ganz stehen, dann kommen die Modelle auf die Probeflaeche, dann zaehlt die Lebendrate statt der Werbesaetze. Bis dahin ist dieser Beitrag eine Freigabenauswertung mit belegten Zahlen, nicht mehr und nicht weniger. Wer heute mit lokaler KI beginnt, kann bei den drei Zeilen dieses Fensters anfangen, sie sind kleiner als die 620 Pull Requests und sagen mehr ueber die Richtung aus.

Ueber den Autor: Ich bin Marcel, Grafikdesigner und Betreiber des HUNTER-Cyberdecks auf einem gebrauchten Google Pixel. Der Hermes-Stack laeuft bei mir als CLI in Termux, die Betriebszahlen in diesem Beitrag stammen aus dem eigenen Messregister meines Decks, den stability-snapshots mit Stichtag 26.10.2026. Alle Release-Fakten habe ich am 26.10.2026 aus den verlinkten GitHub-Freigabemitteilungen belegt, eigene Messungen an Nemotron 3.5 Bolt, DFlash oder hermes mcp serve liegen nicht vor, die Probe auf mcp serve ist geplant. Zuletzt fachlich geprueft am 26.10.2026.

Quellen: GitHub Freigabemitteilungen von Nous Research zu Hermes Agent v0.22.3 (21.10.2026), v0.22.4 (21.10.2026) und v0.22.5 (22./23.10.2026), gelesen am 26.10.2026 ueber die GitHub-Releases-Seite, mit Commit-Referenzen 5b147ab036d und bf0203a794a. Offizielle Herstellersuche zur Benennung des Werkzeugs und seiner Bestandteile: hermes-agent.nousresearch.com/docs (Abruf 26.10.2026). Eigene Betriebszahlen: Vault stability-snapshots des Decks, Stichtag 26.10.2026 07:00 (99 Prozent Lebendrate bei 305 von 306 Checks, 10 OOM-Kills, 676 MiB frei bei 18 Jobs) und Vorwoche 19.10.2026 (100 Prozent, 2 Kills, 1.069 MiB, 13 Jobs). Ausloeser dieses Beitrags war ein frisches Video im YouTube-Zulauf vom 26.10.2026, es diente nur als Themen-Ping, alle Fakten stammen aus den verlinkten Originalquellen.