Sie sehen „Hermes Agent v0.21.5 released“ in einem Feed, klicken sich durch, und der Text besteht aus einem kurzen Absatz: Dies ist ein Patch-Tag, der das Fenster in ein stabiles Release für Docker-Images und gehostete Deployments überführt, und die vollständige kuratierte Beschreibung ist auf v0.22.0 verschoben. Sie führen hermes update aus, das Terminal meldet einen erfolgreichen Upgrade. Und dann — was haben Sie eigentlich bekommen? Aus allem, was Sie bisher gelesen haben, lässt sich das nicht ablesen, und Sie sind nicht sicher, ob das Upgrade heute überhaupt die richtige Entscheidung war. Das ist keine Paranoia; genau das machen Patch-Tags mit Menschen. Dieser Beitrag dreht sich deshalb um eine einzige, sehr praktische Frage: wie Sie diese Frage beantworten, ohne auf Release Notes zu warten.

Warum Patch-Tags oft ohne Notes erscheinen

Klammern Sie diesen Teil einmal ab, und Sie hören auf, sich alle paar Wochen neu darüber zu wundern.

Hermes liefert zwei Arten von Tags. Ein semantisches Release — v0.20.0, v0.21.0 — kommt mit einer langen Beschreibung: Highlights, Funktionsbereiche, Contributor-Credits. Ein datumsbasierter Tag wie dieser hier, v2026.9.24, existiert für eine andere Aufgabe: alles zwischen dem vorherigen Tag und jetzt in eine einzige stabile, pullbare Version zu versiegeln.

Warum muss das existieren? Weil Docker-Images, Hermes Cloud und gehostete Deployments alle aus dem neuesten Release-Tag bauen, nicht aus main. Ein Fix, der auf main landet, erreicht Cloud-Nutzer erst, wenn er in einem Tag steckt. Wenn sich also genug angesammelt hat, schließt ein Patch-Tag das Fenster.

Der Preis dafür ist, dass nichts in diesem Fenster einzeln beschrieben und benannt wird. Dieses Fenster umfasst 460 gemergte PRs, 1.610 Nicht-Merge-Commits, 4.828 geänderte Dateien (+164.132 / −149.440) und 475 geschlossene Issues seit v0.21.4, gemessen am Commit f97608f178d1ffeca59860195ab7da295f7c8e5f. Der Release-Text sagt ausdrücklich, dass nichts davon ausgelassen wird — es wird alles zusammen in v0.22.0 beschrieben, das alles ab v0.21.0 dokumentiert.

Anders gesagt: „Keine Release Notes“ heißt nicht „nichts drin“. Ihr Upgrade ist real. Die Liste ist nur noch nicht geschrieben.

Schritt eins: Finden Sie heraus, welche Version Sie nutzen

Verlassen Sie sich nicht auf Ihr Gefühl. Ein Befehl:

hermes --version

Sie erhalten etwas wie Hermes Agent v0.21.5 (2026.9.24) · upstream <commit>. Beachten Sie das Verhältnis der beiden Zahlen:

Was Sie sehen	Was es bedeutet
v2026.9.24	Der datumsbasierte Tag — der Name auf der GitHub-Release-Seite
v0.21.5	Die semantische Version — verwendet in Artefakten, Image-Namen und Ihrer config.yaml

Es ist dasselbe Release, nicht zwei. Wenn GitHub v2026.9.24 anzeigt und Ihre Maschine v0.21.5 sagt, ist das normal — versuchen Sie nicht, das zu „reparieren“.

Bei einer Git-Installation sehen Sie außerdem, auf welchem Commit Sie stehen:

cd ~/path/to/hermes-agent && git log --oneline -1

Bei Docker lesen Sie den Image-Tag: nousresearch/hermes-agent:v2026.9.24 ist dieses Release. Hier ist außerdem eine Variantenachse hinzugekommen — :latest-desktop / :main-desktop / :v*-desktop enthalten Xvnc/Xfce und Playwrights headed Chromium, und genau das liefert Bot Screen auf gehosteten Deployments. Diese Pakete lassen sich im veröffentlichten Image nicht zur Laufzeit installieren (unprivilegierter Nutzer, kein sudo, versiegeltes /opt/hermes), der Image-Layer ist also der einzige Weg.

Schritt zwei: Überspringen Sie die 460 PRs, lesen Sie den Vergleich

Der „full changelog“-Vergleichslink ist der maßgebliche Einstiegspunkt:

https://github.com/NousResearch/hermes-agent/compare/v2026.9.21...v2026.9.24

Er ist riesig, aber Sie brauchen nur drei Ausschnitte daraus: neue Dateien (besonders neue Seiten unter website/docs/, die bedeuten, dass ein Feature gelandet ist), das Diff von config_defaults.py (das bedeutet neue Config-Keys) und das Diff von hermes_cli/ (das bedeutet neue Befehle oder Flags). Diese drei zu überfliegen schlägt PR-Titel von oben nach unten zu lesen.

Schritt drei: Acht Dinge, die in diesem Fenster bereits nutzbar sind

Alles Folgende ist Bestandteil dieses Tags. Zu jedem Punkt gehört der Befehl, den Sie tatsächlich eintippen.

1. Desktop erhält vollständige französische, deutsche und spanische Kataloge

Desktop liefert jetzt für alle drei vollständige Oberflächenkataloge, auswählbar unter Settings → Appearance → Language. display.language: fr|de|es sowie regionale Aliase wie fr-CA, de-AT und es-419 lösen auf den passenden Katalog auf, statt auf Englisch zurückzufallen. Produktnamen und Bezeichner (Hermes, MCP, API, OAuth, Model-IDs) bleiben unübersetzt.

2. Eine Einstellung für die Textrichtung: Auto / RTL / LTR

Weiter unten auf derselben Seite steht Chat display → Text direction. Jeder Prosa-Block im Chat leitete seine Richtung früher aus seinem ersten starken Zeichen ab, was bei einem arabischen Absatz, der mit einem lateinischen Namen beginnt, garantiert daneben liegt. Jetzt sagen Sie es einfach selbst: Auto behält das alte Verhalten, RTL/LTR wendet ein dir auf die Prosa und beide Composer an. Code bleibt LTR, die App-Chrome kippt nicht, und es werden keine Bidi-Steuerzeichen in Ihren Text eingefügt. Es ist eine Leseeinstellung der Oberfläche, kein Key in config.yaml.

3. Webhook-Zustellungen können in die Session des Ziel-Chats gespiegelt werden

Eine Zustellung war bisher fire-and-forget, eine Antwort wie „welcher Build?“ in diesem Chat brachte Ihnen also nur „who are you referring to?“. Eine Route kann sich jetzt dafür entscheiden:

hermes webhook subscribe ci-alerts \
  --prompt "build {route} failed: {payload}" \
  --deliver telegram \
  --mirror-to-session

Ein erfolgreiches Subscribe gibt eine zusätzliche Zeile aus, die Ihnen mitteilt, dass jede Zustellung in die Session des Ziel-Chats gespiegelt wird. Standardmäßig aus; nur ein echtes boolesches true schaltet ein. Die Grenzen sind im unten verlinkten eigenen Leitfaden beschrieben.

4. Ein Modell per Slug aus jedem Model-Picker hinzufügen

Eine neue Fußzeile Add custom model… verwandelt das Suchfeld des Modell-Menüs in eine Slug-Eingabe, bietet während der Eingabe eine Zeile pro konfiguriertem Provider an, und der gemerkte Slug bleibt als normale Zeile mit einem Entfernen-× in der Liste. Funktioniert im Composer-Menü, im Dialog zum Modellwechsel, in Settings → Model und in der Liste zum Bearbeiten von Modellen.

5. Lokale Stimmen laden nicht mehr bei jedem Aufwachen neu

Ein neuer Config-Key, tts.keep_warm_seconds, Standard 60:

hermes config get tts.keep_warm_seconds    # 60
hermes config set tts.keep_warm_seconds 0  # unload immediately

Nachdem das letzte Lease freigegeben wurde, wartet das Entladen so lange; die Sprache innerhalb des Fensters wieder einzuschalten bricht es ab und nutzt das geladene Modell weiter. Am wichtigsten ist das für reine Wake-Word-Sprachunterhaltungen, die direkt nach ihrem etwa 2 s langen Warm-up enden und die geladene Stimme früher Millisekunden später verloren.

6. Die Desktop-Voiceschleife beginnt, Ihre Konfiguration zu lesen

Read Aloud spricht keine englischen Platzhalter wie code block omitted oder link mehr vor und lässt Tabellen nicht mehr stillschweigend wegfallen — Codeblöcke und URLs bleiben stumm, und Tabellen sprechen stattdessen ihre Kopfzeile. Spoken stop liest jetzt voice.stop_phrases (Standard ["stop"]); zuvor wurde eine hartcodierte englische Liste abgeglichen, sodass ein russischer Nutzer, der wie im Hinweis „отбой“ sagte, dies als Prompt an den Agenten geschickt bekam. Der Barge-in-Trigger der Wiedergabe nutzt jetzt voice.barge_in_threshold_multiplier (Standard 3.0) statt eines hartcodierten 0.14, das über dem Sprachpegel eines Bluetooth-HFP-Headsets lag — deshalb unterbrach Dazwischenreden eine Antwort nie.

7. Funktionstasten-Voice-Shortcuts sind neu belegbar

Die einmalige Diktion ist jetzt eine nicht belegte Tastaturaktion composer.dictate, getrennt von der Sprachunterhaltung, die den kanonischen Capture-Pfad von Desktop für F-Tasten, Caps Lock, Delete, Space und Modifier-Kombinationen weiterverwendet; ein zugewiesenes F12 erreicht den Renderer, während ein nicht zugewiesenes F12 das DevTools-Verhalten behält. Im selben Fenster wurden auch die macOS-Funktionstasten repariert — der TUI-Parser hält F1–F12-Terminalsequenzen intakt, und das Live-Work-Dock bekam Ctrl+R als portablen F7-Fallback.

8. Ein Bündel von Fehlern, die nur lokalisiertes Windows treffen

• Auf französischem, spanischem oder deutschem Windows warf %Z einen UnicodeEncodeError innerhalb von strftime, weil Zonennamen als ANSI-Codepage-Bytes ankommen, die zu einsamen Surrogaten dekodieren. hermes_time.safe_strftime() fängt das jetzt ab, und auf gesunden Locales ist seine Ausgabe byte-identisch zu vorher, sodass die Prompt-Cache-Invariante hält.
• Das durchlaufende [gateway-crash] ... UnicodeDecodeError: 'gbk' codec can't decode auf chinesischem Windows ist behoben: Die Ausgabe von Kindprozessen ist jetzt auf UTF-8 festgelegt.
• C:\...\report.html und UNC-Pfade \\server\share\... werden als Pfade erkannt und korrekt in der Vorschau angezeigt, statt an das Arbeitsverzeichnis zu /repo/C:\... angehängt zu werden.
• Bei einem Windows-Kaltstart stockt die Event-Loop des lokalen Backends 12–28 s lang, während Gateway-Module importiert werden, und eine feste 10-s-Boot-Probe verriegelte das als Boot-Fehler. Ein Backend, das diese App selbst gestartet hat, wartet jetzt weiter, solange der Kindprozess lebt, bis zu einer Obergrenze von 90 s.

Ein Selbstcheck in fünf Minuten

Nach dem Upgrade bestätigen diese Befehle, dass Sie die neue Oberfläche wirklich haben (auf v0.21.5 oder neuer):

hermes --version                                        # expect v0.21.5 (2026.9.24)
hermes config get tts.keep_warm_seconds                 # 60
hermes config get voice.stop_phrases                    # - stop
hermes config get voice.barge_in_threshold_multiplier   # 3.0
hermes webhook list                                     # shows which routes mirror

Wann Sie wirklich auf v0.22.0 warten sollten

Eigentlich nie. Alles in einem Patch-Tag ist bereits der Code, der auf Ihrer Maschine läuft — kein Dokument hält Ihr Upgrade auf. Zwei Gruppen haben dennoch einen Grund zu warten: nachgelagerte Distributoren (wer Images baut oder interne Builds für ein Team schneidet) und alle, die ein Tutorial über dieses Fenster schreiben, weil deren Liste besser lesbar sein wird.

Wenn Hermes für Sie einfach ein Werkzeug ist, gilt nur ein Test: Ist ein konkretes Problem, das Sie gerade treffen, hier gefixt? Dieses Fenster hat reichlich Kandidaten — nehmen Sie eine der acht Gruppen oben und probieren Sie sie aus.

Die Kurzfassung

• Ein Patch-Tag ohne Notes ist ein Mechanismus, kein Schulterzucken: Er existiert, damit Docker-Images und gehostete Deployments Fixes mitnehmen können, die auf main liegen.
• Die Version hat zwei Gestalten; v2026.9.24 und v0.21.5 sind ein Release.
• Für die Liste überfliegen Sie drei Ausschnitte des Vergleichs — neue Docs, das Diff von config_defaults.py, das Diff von hermes_cli/.
• Acht Änderungsgruppen in diesem Fenster sind sofort nutzbar, von den neuen Katalogen in Desktop bis zu vier Crash-Fixes für lokalisierte Windows-Installationen.

Für eine vollständigere Aufzeichnung dieses Fensters gruppiert unsere Release-Seite zu v0.21.5 es nach Funktionsbereichen; das vorherige Patch-Fenster behandelt der Durchgang durch das v0.21.4-Fenster. Der Webhook-Mirror hat seinen eigenen Leitfaden, und die Voice-Änderungen sind in Keep-warm und Sentence-Streaming beschrieben. Starten Sie von einer frischen Maschine? Der Installationsleitfaden hat den vollständigen Weg.