Sie tippen hermes update, das Terminal scrollt, und die letzte Zeile meldet einen erfolgreichen Upgrade. Aber was haben Sie da eigentlich installiert — einen Commit, der gestern gelandet ist, oder ein Release, das vor drei Tagen geschnitten wurde? Auf einer Maschine, die rund um die Uhr läuft, ist diese Frage wichtig: Sie wollen keinen Fix verpassen, und Sie wollen nicht aufwachen und main auf einem Stand folgen, den noch niemand betreten hat.

Bei v0.21.7 geht es genau darum. Es ist keine Sammlung neuer Features, sondern eine Richtlinienänderung. Eine Source-Installation aktualisiert sich jetzt auf das neueste veröffentlichte Release statt auf jeden Commit auf main. Dieser Beitrag behandelt die beiden praktischen Teile: auf welchem Kanal Ihre Installation läuft und wie Sie belegen, was Sie tatsächlich ausführen.

Was sich wirklich geändert hat: woher Ihre Updates kommen

Eine Git-Installation von Hermes bedeutete früher, dass hermes update den Working Tree auf die Spitze von main zieht. Fixes kamen schnell, aber Sie standen auf beweglichem Boden: main ändert sich täglich, halb zusammengeführte Zustände können stundenlang bestehen, und Ihre Maschine konnte sich mitten in einem davon aktualisieren.

Seit v0.21.7 gilt standardmäßig: nur auf das neueste vX.Y.Z-Release wechseln. Die Regeln sollte man einzeln lesen, denn sie prägen Ihr Gespür dafür, ob Sie im Rückstand sind:

• Älter als das neueste Tag → Sie rücken auf dieses Tag vor.
• Bereits vor dem neuesten Tag (etwa weil Sie früher main gefolgt sind) → es bewegt sich nichts. Ihre Installation bleibt, wo sie ist, und wartet auf das nächste Release. Nichts wird jemals rückwärts bewegt.
• Forks und Mirrors → sie folgen weiterhin main, unberührt.
• Microsoft Store, MSIX und die gebündelte Desktop-App → das Packaging bleibt unverändert; sie bewegen sich mit ihren eigenen Builds.

Genau die zweite Regel wird gern als „Updates sind kaputt“ fehlgelesen. Sie ist Absicht: eine main-folgende Installation auf ein Tag zurückzuziehen würde ein Routine-Update in ein Downgrade verwandeln, und das macht Hermes nicht.

Kanal A: Stabile Releases (der neue Standard)

Hier gibt es nichts zu konfigurieren — eine Source-Installation startet auf diesem Kanal. Sie bekommen das neueste veröffentlichte Tag, aktuell v0.21.7.

Für wen es passt: für alle, die lieber jemand anderen zuerst auf den Boden treten lassen. Ein Release ist ein stabiler Punkt, der aus einem Zeitfenster destilliert wurde, und er wird nicht über Nacht zu etwas anderem.

Kanal B: Jeder Commit (bewusst aktivieren)

Um weiter jedem Commit auf main zu folgen, reicht ein Befehl:

hermes update --set-channel main

Danach ist das alte Verhalten zurück. Das Zurückschalten ist dieselbe Art von Befehl:

hermes update --set-channel stable

Wenn Ihr Build älter ist als diese Flags, führen Sie zuerst ein einfaches hermes update aus, um eine Version zu bekommen, die Kanäle kennt, und schalten Sie dann um.

Der Kanal ist ein persistenter Zustand, kein einmaliges Flag für ein einzelnes Update. Einmal gesetzt, gehorcht ihm jedes spätere Update — stopfen Sie es also nicht in ein Skript, das Sie später vergessen.

Wo der Desktop-Schalter liegt

In der Desktop-App unter Settings ▸ About ▸ Updates; dort gibt es einen Schalter Update channel (Stable releases / Every commit). Er hat nur für eine Source-Installation Bedeutung: Store-, MSIX- und gebündelte Installationen sind von Ihrer Wahl nicht betroffen.

Der Update-Dialog sagt Ihnen außerdem, auf welchem Kanal Sie gerade sind — Sie müssen sich also nicht mehr auf „ich habe das mal eingestellt“ verlassen.

Zwei alltägliche Unterbrechungen im selben Release behoben

Zwei weitere Punkte im Release-Text fallen in die Kategorie „das interessiert Sie erst, wenn es Sie trifft“:

Reasoning übersteht das Resume. Bei Reasoning-Modellen über Anthropic oder Bedrock Converse wird signiertes Thinking nach hermes chat --resume und im nächsten Gateway-Turn korrekt erneut übertragen, und Bedrock-Converse-Reasoning-Modelle werden bei fortgesetzten Sessions nicht mehr abgelehnt. Der Mechanismus verdient eine eigene Betrachtung — welche Routen welche Felder lesen und was passiert, wenn eine Route ein Feld ablehnt — und wir haben das separat aufgeschrieben: siehe den Reasoning-Replay-Leitfaden.

Updates scheitern nicht mehr hinter bestimmten Firewalls. Installationen auf main holten früher einen Release-Datensatz, den regionale Firewalls mit einem 403 beantworten konnten, was das Update vollständig scheitern ließ. Die Prüfung nutzt jetzt Ihren GitHub-Token, wenn einer gesetzt ist (GITHUB_TOKEN oder gh auth login), und meldet ein GitHub-Rate-Limit als Rate-Limit statt als undurchsichtigen Fehler.

Wie viel in diesem Zeitfenster gelandet ist

Die Größenordnungen stammen aus dem offiziellen Release-Text, gemessen am Commit 1fd18277267152893a8a24792b79213e7ca3f899:

Metrik	Wert
Nicht-Merge-Commits	740
Geänderte Dateien	4.156 (+86.775 / −26.980)
Gemergte PRs	204
Geschlossene Issues	69

Wie bei v0.21.6 erscheinen die vollständigen kuratierten Notes mit v0.22.0, die alles ab v0.21.0 dokumentieren werden — Highlights, Feature-Bereiche und vollständige Contributor-Credits. Der Text zu v0.21.7 führt außerdem eine Reihe von Dingen auf, die hier bewusst nicht katalogisiert werden: Plugins, die eingebaute App-Aktionen ausführen, die Plugin-SDK-Pet-Bubble, Skills, die mitten in einer Session installiert werden und das Modell ohne Prompt-Neuaufbau erreichen, Krea 2 Medium Turbo als Bild-Lane für zahlende Abonnenten mit FAL-Fallback, schnellere Desktop-Updates, gepinnte Installationen, die nur den Pin auschecken, an Relay ausgegebene Compaction-Marken und neue Community-Plugins. Wir behandeln sie eine nach der anderen — der Beitrag zu den Plugin-Aktionen ist bereits online: Desktop-Plugin-Aktionen und die Pet-Bubble.

Belegen, welche Version Sie haben

Drei Befehle — nehmen Sie den, der zu Ihrer Installation passt:

# Version (eine Git-Installation zeigt zusätzlich die Distanz hinter dem Tag und den kurzen Commit)
hermes version

# aktueller Kanal und Update-Quelle (Source-Installationen)
hermes update --help

# Desktop- / Installer-Installationen
hermes doctor

Wenn Sie vermuten, dass ein Update Erfolg gemeldet hat, aber nichts geändert wurde, prüfen Sie in hermes version, ob sich das Tag bewegt hat, und lesen Sie dann hermes update --verbose. Für den Hintergrund zu den Kanälen siehe unseren früheren Leitfaden zum stabilen Kanal; für die Release-Pipeline, aus der dieses Tag geschnitten wurde, siehe den Beitrag zum v0.21.6-Release.

Upgrade

# CLI
hermes update

# Desktop: aktualisiert sich selbst. Microsoft Store: aktualisiert über den Store.

# Docker / Hermes Cloud
docker pull nousresearch/hermes-agent:stable

Ein kurzer Selbsttest nach dem Upgrade, damit Kanal und Version dem entsprechen, was Sie erwarten:

hermes version
hermes config get agent.max_turns      # bestätigt außerdem, dass das Update Ihre Konfiguration unangetastet gelassen hat

In einem Satz: v0.21.7 macht das Aktualisieren von etwas, das Sie auf main beobachten, zu etwas, das Sie in Ruhe lassen können — zum Preis zu wissen, auf welchem Kanal Sie sind. Einmal setzen, und das nächste Tag macht den Rest.