Hermes Agent v0.21.3: 338 Pull Requests im Patch-Release und die Lektion hinter den zwei sichtbaren Fixes

Ein Patch-Release mit 338 Pull Requests klingt wie ein Widerspruch, und genau deshalb ist Hermes Agent v0.21.3 (v2026.9.14) vom 14. September 2026 die lesenswerteste Release-Notiz der Woche. Der kuratierte Teil auf GitHub nennt zwei Fixes: Entfernte Dashboard-Sitzungen sterben nicht mehr an Refresh-Bursts, und langlebige Prozesse hinterlassen keine doppelten Schreib-Handles mehr auf der state.db. Der Rest dessen, was zwischen v0.21.2 und diesem Tag gelandet ist, steht nicht in den Notizen, sondern in der Messzeile: 1.036 non-merge commits, 2.642 geänderte Dateien, 131.690 Zeilen hinzugefügt und 37.096 entfernt. Ich betreibe meinen Agentenbetrieb auf einem gebrauchten Google Pixel 6a und habe die Release-Notiz am 20. September 2026 gelesen. In diesem Beitrag sortiere ich, was die zwei sichtbaren Fixes wirklich beheben, welche Lektion die state.db-Geschichte für jeden Agentenbetrieb enthält und wo die Grenzen dieser Einordnung liegen, denn live getestet habe ich die Fixes bis zum Abrufdatum nicht.

Der erste Fix trägt die Nummer #110061 und ist ein Lehrstück darüber, wie verteilte Systeme scheitern, ohne kaputt zu sein. Das Desktop-Backend dreht den Refresh-Token bei jeder Verlängerung. Ein Wecken des Geräts feuert laut Release-Notiz gleich mehrere Refresh-Requests auf denselben bereits rotierten Token. Die Portalseite liest dieses Muster als Wiederverwendungsversuch und zieht die Konsequenz, die ihre Reuse-Detection vorsieht: die ganze Sitzung wird widerrufen. Für den Nutzer sieht das absurd aus, weil eine ganz normale Aktion, das Aufwecken nach einer Pause, die Sitzung killt. Der Fix koalesziert gleichzeitige Refresh-Requests mit demselben Token, und zwar auf beiden Pfaden, dem Cookie-Gate am Gateway und der nativen Bearer-Route des Desktops, die in denselben koaleszierten Aufruf laufen. Zusätzlich verlässt der Refresh den Event-Loop, damit ein langsamer Identitätsanbieter nicht mehr die Status-Route einfriert. Die Portalseite ergänzt in Pull Request #1209 einen gleitenden Leerlaufhorizont von 30 Tagen plus fünf Minuten Gnadenfrist für den rotierten Token. Drei Verteidigungslinien für ein Problem, das aus Sicht eines einzelnen Servers aussah wie ein Angriff.

Der zweite Fix trägt die Nummer #110934 und räumt mit einem Muster auf, das lange nur als Störgeräusch sichtbar war. Gateway, Dashboard, Desktop-Backend, ACP und die CLI-Reader öffneten im Betrieb jeweils eigene state.db-Handles, und in langlebigen Prozessen sammelten sich doppelte Schreib-Handles, die der Precursor mit Meldungen wie N live SessionDB handles anzeigte, obwohl die Topologie gesund war. Die Release-Notiz verknüpft das Muster mit zwei offenen Issues, #100896 und #103339. Die Lösung liest sich unspektakulär und ist genau deshalb lehrreich: Leser verbinden sich read-only, und Schreiber innerhalb eines Prozesses teilen sich ihr Handle über eine Registry, statt es mehrfach zu öffnen. Das ist keine neue Funktion, das ist Hygiene für Langläufer. Und Agentenbetrieb besteht zu einem großen Teil aus Langläufern, aus Gateways, Watchdogs und Cron-Jobs, die Tage und Wochen durchlaufen und dabei kleine Unsauberkeiten nicht vergessen, sondern aufrechnen.

Die eigentliche Story des Fensters steht in dem Abschnitt, den die Notizen bewusst unspektakulär halten. Aufgelistet, aber nicht kuratiert: Server-zu-Client-JSON-RPC und eine Pydantic-Wire-Contract-Registry mit generierten TS- und OpenRPC-Artefakten für den Gateway zwischen TUI und Desktop, Reasoning-Effort-Auswahl in jedem Model-Picker, OpenRouter-Login per OAuth-PKCE, Dekodierung für HEIF, HEIC und AVIF, Wan 3.0, Kling 3.0, Kling Image v3, MiniMax H3 Max Turbo, Gemini Omni Flash 1.1 und Meta Muse in den FAL-Katalogen, eingefügte Tabellen in Slack und eine Agent-Sessions-API, dazu Multiplex-Isolation für Profile und die WAL-Ablehnung auf Cross-VM-Dateisystemen. Wer nur die zwei kuratierten Fixes liest, verpasst die halbe Veröffentlichung. Ein Patch-Release hier ist kein Patch im Sinne kleiner Reparaturen, sondern ein Zeitstempel, an dem 338 zusammengeführte Pull Requests eine stabile Nummer bekommen, damit Cloud-Instanzen und Docker-Images sie als ein Paket übernehmen können.

Der Text sagt es selbst: Der Tag existiert, damit die Fixes der Remote-Gateway-Anmeldung die Cloud-Instanzen erreichen, die automatisch auf den neuesten Release-Tag springen. Downstream-Konsumenten wie Docker-Images, Hermes Cloud und gehostete Deployment-Umgebungen brauchen einen stabilen Anker, und genau diesen Anker liefert der Tag. Das ist ein Modell, das man beim Betrieb eigener Systeme direkt kopieren kann: kuratierte Notizen für Nutzer, vollständige Messzeile für Betreiber, stabiler Tag für die Automatik. Die Kuratierung ist dabei keine Verzierung, sondern eine Entscheidung darüber, woran sich die Welt beim Upgrade festhalten soll. Die zwei sichtbaren Fixes sind die zwei Stellen, an denen sich Nutzer beschwert hatten, der Rest des Fensters reist im Beiwagen. Für mein Verständnis von Release-Arbeit ist das die eigentliche Botschaft dieses Tags: Die sichtbare Story und die reale Masse einer Veröffentlichung dürfen auseinanderfallen, solange beide sauber dokumentiert sind.

Mein Agenten-Stapel läuft auf einem 45-Euro-Handy, dem Google Pixel 6a, mit Gateway, Cron und einem Postkasten aus agent_events. Datenbank- und Prozesshygiene sind dort kein Randthema, sondern Alltag. Ich habe auf diesem Deck den OOM-Sturm vom 28. August 2026 erlebt, 46 OOM-Kills in sieben Tagen laut Snapshot vom 31. August, und danach die Härtung, die am 07. September 306 von 306 stündlichen Checks bei null OOM-Kills erreichte, einen 88-Stunden-Rekord von Ende August bis Anfang September eingeschlossen. Die Woche bis zum 14. September zeigte fünf OOM-Kills bei weiter 100 Prozent Lebendrate, die Zahlen stehen in den stability-snapshots meines Messregisters. Genau deshalb lese ich ein Release wie v0.21.3 nicht als News, sondern als Werkzeugliste: Handles, die Leser nicht schreiben lassen, Refresh-Pfade, die Burst-Wiederholungen koaleszieren, und ein Update-Pfad über hermes update, während Cloud-Instanzen automatisch auf den neuesten Tag springen. Ehrlichkeit gehört dazu: Bis zum Abrufdatum kann ich nicht belegen, welche Patch-Nummer auf dem Deck läuft, und die beiden Fixes habe ich nicht live getestet. Die Messwerte oben sind meine eigene Messung, der Rest ist sorgfältiges Lesen.

Die Grenzen liegen offen und bleiben trotzdem wichtig. Erstens sind alle Zahlen aus dem Release-Text Selbstmessung des Projekts, gemessen am Commit 9b419a2d, und die Notizen sind kuratorisch, das Dokument sagt es selbst. Zweitens sind die zwei sichtbaren Fixes aus der Sicht der Nutzer geschrieben, die sie beantragt haben, wie oft das Refresh-Burst-Muster außerhalb der gemeldeten Fälle auftritt, bleibt unbekannt. Drittens fehlen unabhängige Tests und Benchmarks zum Abrufdatum 20.09.2026, es gibt keine dritte Stelle, die das Verhalten der Fixes misst. Viertens gilt: Ein neuer Tag für Cloud-Instanzen ist kein Beweis, dass jedes eigene Setup die Fixes bereits enthält, wer selbst betreibt, fährt beim nächsten regulären Update. Agenten auf eigener Hardware zu betreiben heißt deshalb, Release-Fenster genau so zu lesen, wie ich es hier vorspiele: als Liste von Werkzeugen, die Probleme benennen, die man vorher nicht auf dem Schirm hatte.

Über den Autor: Ich bin Marcel, ich betreibe das HUNTER-Cyberdeck auf einem gebrauchten Google Pixel 6a und den Agentenbetrieb dahinter im Alltag. Dieser Beitrag stützt sich auf die Lektüre der Hermes-Agent-Release-Notizen vom 14. September 2026 (abgerufen am 20. September 2026) und auf die stability-snapshots meines Messregisters vom 31. August bis 14. September 2026. Ich habe die beiden Fixes nicht live getestet, das ist in der Grenzsektion des Beitrags vermerkt. Zuletzt fachlich geprüft am 20. September 2026.