Hermes Agent v0.22.5: 81 Pull Requests zwischen mir und dem Update

Ein Tag nach meinem letzten Radarlauf hat Nous Research Hermes Agent v0.22.5 auf GitHub freigegeben. Bescheiden beschriftet ist das Release, ein Patch-Release, aber die Zahl dahinter ist es nicht: Der Tag rollt rund 81 Pull Requests seit v0.22.4 in einen stabilen Stand, ausgeliefert für die Command-Line mit ihren Installern, die Microsoft-Store-App, Docker und Hermes Cloud. Die Releasemeldung misst das Fenster am Commit bf0203a794a nach: 231 Nicht-Merge-Commits, 804 geänderte Dateien, plus 35.212 und minus 17.885 Zeilen, dazu 30 geschlossene Issues. Auf GitHub hängt der Tag seit der Frühe des 23.10.2026 als Latest.

Mein Deck meldet einen anderen Stand. hermes --version sagt Hermes Agent v0.20.5 vom 19.08.2026, Installationsmethode git, Upstream-Commit a251e87d, und der eigene Update-Check erklärt mich für up to date. Zwei Minor-Releases weiter oben existiert ein neuerer Tag. Beides ist wahr, weil beide Uhren anders gehen: Der Update-Check liest seine Installationsquelle, der GitHub-Tag ist die Kuratur des Release-Teams. Für den Betrieb auf einem 45-Euro-Handy entsteht aus dieser Lücke die entscheidende Frage: Drücke ich jetzt auf Update, oder warte ich?

Meine Antwort lautet dieses Mal: noch nicht. Update-Tempo ist auf kleinstem Gerät keine Begeisterungsfrage, sondern eine Betriebsentscheidung. Ein gebrauchtes Pixel 6a mit unter 2 Gigabyte freiem RAM ist nicht das System, auf dem ich mitten in einer laufenden Woche einen Stapel gebumpter Python-Abhängigkeiten austeste. Die stability-snapshots zeigen beide Richtungen des Quartals: Am 12.10.2026 standen 454 MiB zur Verfügung, am 19.10.2026 waren es 1069 MiB mit 2 OOM-Kills und einer 100-prozentigen Gateway-Überlebensrate von 306 Checks. Auf so einem Gerät ist ein Update ein Zeitfenster zwischen Läufen, kein Klick.

Was im Fenster drin war, steht ungewöhnlich offen in der Releasemeldung, und einen Teil davon deutet das Release-Team ausdrücklich als bewusst ohne Kuratierung belassen. Vermerkt sind: das überarbeitete Nous Sign-in, bei dem jede Anmeldung zum reinen Gerätelogin wird, ein hermes update, das einen stabilen Release zurückhält, wenn es ihm nicht vertraut, statt ihn anzubieten, Support für Nutzungsfenster bei Plänen mit Messleisten, Limitkarten und Modellwechsel-Recovery, aussteckbare Delegation-Backends, die Subagenten über eine Modell-Map oder ein Profil routen, je Session umschaltbar, und hermes mcp serve, das den Agenten als MCP-Server anbietet. Die vollständig kuratierten Release-Notes für das ganze Fenster verspricht das Team erst mit v0.23.0, dann soll alles ab v0.22.0 dokumentiert werden. Für mich als Betreiber ist das eine ehrliche Reihenfolge: Erst der stabile Tag, danach die Doku.

Nicht alles davon betrifft mein Setup. Desktop-Arbeit wie Drag-to-pin in der Seitenleiste, Ein-Klick-Plugin-Installationen mit Tier-Badges, die Group-Chat-Anzeige und das Electron-44-Upgrade läuft auf Oberflächen, die mein Pixel nicht fährt. Drei Stellen zeigen aber genau in meinen Betrieb. Das hermes update, das nach einer beschädigten .git gepauste Gateways wieder anwirft, behandelt einen Fehlermodus, den ich auf Android respektiere. Der Fix mit der Stall-Uhr, der lange DirectSDK-Antworten nicht mehr abschneidet, trifft meinen Stack nicht direkt, weil ich über kein Claude-DirectSDK laufe, aber das Warten auf lange Antworten kenne ich gut genug. Und der Nutzungsfenster-Support betrifft Pläne mit Zeitfenstern, genau die Form, in der mein Ollama-Vertrag läuft, 5-Stunden-Fenster und Wochenlimit. Den Beweis dafür hole ich mir nach einem Update vom echten Fenster, Zahlen dazu liefert dann mein Dashboard, nicht die Releasemeldung.

Der Rest dieses Texts liest die Releasemeldung von der Betreiberseite her: Was drin ist, was fehlt, was auf dem 45-Euro-Handy wirkt, und wann ich selbst dran bin.

Ein Patch-Release heißt hier nicht kleines Release. 81 Pull Requests und 231 Commits über 804 Dateien sind mehr Bewegung, als manche Projekte in einem Quartal schaffen, und die Releasemeldung macht daraus keine Werbespots, sondern eine Rechnung. Das Fenster enthält nachweislich 30 geschlossene Issues. Wer die Vergleichsansicht zwischen v0.22.4 und v0.22.5 aufklappt, sieht die PR-Liste im Einzelnen, vom Detail-Fix bis zur Infrastrukturänderung.

Was fehlt, steht in derselben Meldung: die kuratierte Dokumentation dieser Phase. Sie kommt mit v0.23.0 und soll dann alles aus dem Fenster ab v0.22.0 abdecken, Highlights, Funktionsbereiche und Contributor-Credits, damit in dieser Phase nichts untergeht. Das ist eine ungewöhnlich ehrliche Absage an die Fassade, in der jedes Release seine eigenen Highlights mitbringt. Es ist auch eine Verbindlichkeit mit Frist: Bis dahin bleibt die Meldung die Doku, und genau deshalb liest sie sich für Betreiber so gut, weil sie Grenzen benennt, statt sie zu verstecken.

Die Zahlen sind nicht geschätzt, sondern am Commit-Stand gemessen, das steht so in der Meldung. Für die Einordnung auf meinem Gerät lese ich dieselbe Art Metrik in meiner eigenen Log-Währung: Der Snapshot vom 12.10.2026 zeigt eine Woche am Boden mit 454 MiB freiem RAM, der Snapshot vom 19.10.2026 zeigt das Pendel zurück auf 1069 MiB. Releases und RAM schwanken im selben Quartal um Faktoren von mehr als zwei.

Vier Zeilen der Releasemeldung haben bei mir sofort einen Anschluss gefunden. Erstens die Wiederherstellung: hermes update richtet gepauste Gateways wieder auf, wenn eine beschädigte .git sie gestoppt hat. Auf einem Gerät, dessen nutzbarer Speicher von Woche zu Woche schwankt, ist genau diese Klasse von Selbstheilung diejenige, die nachts zählt. Zweitens der Nutzungsfenster-Support: Messleisten, Limitkarten und ein Modellwechsel-Recovery für Pläne, die über Zeitfenster abrechnen. Verifiziert habe ich das nicht, mein Deck läuft im älteren Stand; die Erwartung ist, dass genau die 5-Stunden-Fenster meines Ollama-Vertrags dort sichtbar werden.

Zur Sicherheit gehört auch die Umkehrung: hermes update hält einen stabilen Release zurück, wenn es ihm nicht vertraut, statt ihn anzubieten. Damit wird meine Update-Routine kürzer: Update anstoßen, Meldung lesen, im Zweifel warten. Die dritte und vierte Stelle sind die Delegation-Backends und hermes mcp serve. Die Backends routen Subagenten nach Modell-Map oder Profil und lassen sich je Session umschalten, das ist genau die Schicht, auf der mein herdr- und pi-Routing lebt. Der MCP-Server-Modus interessiert alles, was von außen mit diesem Deck sprechen will, und dafür bleibe ich konservativ: er wartet, bis ihn ein Projekt braucht.

Meine Regel ist aus den OOM-Wochen geboren, nicht aus Begeisterung. Ein Release-Tag kommt zwischen Läufe, nie mitten in ein Zeitfenster. Vorher kommt die Boot-Sicherung der Backup-Ebene, nach dem Update erst hermes --version, dann ein ruhiger Betriebstag, dann der erste kritische Lauf. Und ein dritter Schritt, den viele überspringen: Nach 24 Stunden liest der Snapshot-Log die Woche neu, denn auf diesem Deck gilt ein Update erst dann als stabil, wenn die Wochenmetrik mitgeht.

Ich habe heute bewusst nicht aktualisiert. Der eigene Check hält meinen git-Stand für aktuell, weil seine Quelle nichts Sichtbares vorlegt, während der Tag v0.22.5 weiter oben existiert. In der Praxis heißt das: Ich notiere die Lücke, kontrolliere vor dem nächsten kritischen Lauf, ob die Installationsquelle den Tag nachliefert, und drücke andernfalls zwischen zwei Läufen selbst. Wer auf so einem Gerät die Automatik kauft, kauft dabei auch die ungetestete Woche, die jemand anders durchläuft. Ich zahle lieber mit Geduld.

v0.22.5 ist ein Tag zum Lesen, nicht zum Sofort-Drücken. Die Rechnung stimmt, 231 Commits und 81 Pull Requests sind Substanz, und die Aufteilung, erst der stabile Tag, dann die kuratierte Doku mit v0.23.0, macht den Betrieb einfacher, nicht schwerer. Mein Deck bleibt im eigenen Rhythmus, die Snapshots tragen die Woche, und der richtige Moment für das Update ist der ruhige Morgen zwischen zwei Läufen, mit Boot-Sicherung im Rücken. Betrieb heißt manchmal, dem Tempo der Anderen nicht hinterherzurennen, sondern das eigene zu kennen.

Über den Autor: Ich bin Marcel, Grafikdesigner, und ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a im Alltag. Grundlage dieses Beitrags: die stability-snapshots vom 28.09., 05.10., 12.10. und 19.10.2026, hermes --version geprüft am 24.10.2026 und die Releasemeldung zu v0.22.5 auf GitHub. Zuletzt fachlich geprüft am 24.10.2026.