Du betreibst eine Maschine mit mehreren parallelen Hermes-Workflows, und eines Tages beschließt du aufzuräumen: ls .worktrees/ zeigt zwei Dutzend Trees, und die Branch-Liste scrollt über drei Bildschirme – aber du traust dich nicht, etwas zu löschen, weil du nicht erkennen kannst, welcher Tree noch ungepushte Arbeit enthält. Inzwischen richtest du einen Bot-Mode-Gruppenchat mit drei Bots ein, die ein Projekt verfolgen, und als du ein PDF-Designdokument teilen willst, stellst du fest, dass der Raum einfach keine Dateien annimmt. Das sind die Aufgaben, um die niemand explizit gebeten hat, auf die aber schon jeder gestoßen ist – und genau darum geht es in v0.20.5 (Tag v2026.8.19, veröffentlicht am 19. August 2026).

Seit v0.20.4 wurden in diesem Zeitfenster rund 323 PRs und ~746 Commits über ~1.250 Dateien gemergt. Es gibt kein einzelnes Schlagzeilen-Feature: Die Geschichte ist, dass Bot-Mode-Gruppenchats endlich Dateien akzeptieren, Worktrees endlich einen sicheren Frühjahrsputz-Befehl bekommen, Updates endlich Belege produzieren, die man prüfen kann, und Cron-Jobs endlich ein Gedächtnis haben. Schauen wir sie uns der Reihe nach an.

Gruppenchats akzeptieren Dateien – und alte Nachrichten falten sich automatisch ein

Bot-Mode-Gruppenchats waren früher reiner Text: Um den Bots in einem Raum ein PDF zu zeigen, musstest du die Datei irgendwo ablegen und den Pfad in deinem Prompt referenzieren. Jetzt sind Dateien erstklassig – Räume akzeptieren PDFs, beliebige Dateien und Drag & Drop, und jeder Bot, der auf den Turn antwortet, sieht die Anhänge (PRs #97b41f8cf, #b359db72e). Das Multi-Bot-Szenario der Projektverfolgung funktioniert endlich ohne Umwege.

Auch lange Räume haben jetzt eine Antwort: Ältere Unterhaltungen falten sich automatisch zu einzeiligen Zusammenfassungen („▸ API-Design … 14 Antworten · vor 2 Std.“), während die neueste Unterhaltung vollständig geöffnet bleibt (#8505559fa) – Räume wachsen nicht mehr unbegrenzt, und die Historie bleibt überblickbar. Auch die Avatare bekommen einen neuen Look: standardmäßig Blob-Gesichter, die deterministisch aus dem Agentennamen abgeleitet werden (gleicher Name, gleiches Gesicht, jedes Mal), mit vier neuen Silhouetten aus blobatar 2.0.0 (#a77ee88ce, #cb0fd836a). Für eine systematische Tour durch die Gruppenchat-Funktionen siehe unseren Bot-Mode-Gruppenchat-Guide.

hermes worktree list/prune: sicherer Frühjahrsputz für Worktrees

Zurück zur Eingangsszene. Multi-Agent-Workflows (hermes -w oder /worktree new) sammeln Dutzende Trees und Hunderte gemergter Branches unter .worktrees/ an. Der stille Pruner beim Start fasst nur Trees an, die sauber und vollständig gemergt sind; alles andere bleibt für immer liegen – konservativ mit Absicht, aber das bedeutet, dass du selbst von Hand prüfen musst.

v0.20.5 fügt einen expliziten Befehl mit Dry-Run zuerst hinzu (#f309f92d3):

hermes worktree list              # Audit: eine Zeile pro Tree – Alter, Größe, Urteil, Grund
hermes worktree prune --dry-run   # Plan anzeigen, nichts ändern
hermes worktree prune             # sichere Trees + gemergte Branches zurückgewinnen

list druckt eine Tabelle: Tree-Name, Alter, Größe, Urteil (reap/keep) und Grund, mit einer Fußzeile, die „N Trees, X gesamt, Y jetzt zurückgewinnbar“ zusammenfasst. Die Sicherheits-Invarianten sind identisch zum Start-Pruner: nachverfolgte Änderungen werden in keinem Alter gelöscht, eindeutige ungepushte Commits werden nie gelöscht (git cherry entscheidet, was „eindeutig“ ist; flache Repos werden vorher ohne Blobs vertieft), live gesperrte Trees bleiben unangetastet, ein Branch wird nur gelöscht, nachdem das Entfernen seines Worktrees erfolgreich war, und reiner Untracked-Scratch wird nach ~/.hermes/archive/worktree-prune/ archiviert, bevor sein Tree abgeräumt wird – Müll geht weg, lebendige Arbeit bleibt.

Updates kommen jetzt mit Belegen: hermes update --plan

„Was beim Update tatsächlich passiert ist“ war früher eine Blackbox: ✓ Code updated! drucken und fertig – der Helper stirbt nach dem Drucken, der Neustart wird still übersprungen, der Desktop zeigt für ein erfolgreiches Update einen Fehler – die Silent-Failure-Klassen (#88848, #74973, #85753, #81193) waren hinterher alle reine Rätselraterei. v0.20.5 bringt den Updater dazu, sein Ergebnis zu beweisen (#0aecadc17, #1d74833d8):

• hermes update --plan: nur lesend. Listet auf, was das Update anfassen wird – Installationsart (git/docker/nix), jeden laufenden Hermes-Dienst über alle Profile hinweg mit seinem Supervisor und der laufenden Code-Version – und wie jeder neu gestartet wird. Sicher auf einem Live-Fleet auszuführen.
• Strukturierte Belege: jedes hermes update schreibt einen maschinenlesbaren JSON-Eintrag – was entdeckt, getan, übersprungen wurde (und warum) – nach <HERMES_HOME>/logs/update_receipts/. Nach der Neustartphase liest es das gateway_state.json jedes Profils, vergleicht die code_sha jedes laufenden Gateways mit dem frisch aktualisierten Checkout-HEAD und druckt eine Fleet-Versionsmatrix – Fleets mit gemischten Versionen werden zu einem lauten, umsetzbaren Bericht statt zu einem latenten Zustand.

Führe vor dem Upgrade hermes update --plan aus, um zu sehen, was sich ändern wird, und prüfe danach den Beleg – wer auf welcher Version ist, ist auf einen Blick sichtbar. Das setzt den Bogen aus dem ehrlichen hermes update in v0.20.4 fort: Aktualisieren wandert von „vertrau mir“ zu „überprüfbar“.

Cron-Jobs haben ein Gedächtnis – und einen Reasoning-Aufwand pro Job

Cron-Jobs wurden früher anders behandelt: skip_memory=True, MEMORY.md/USER.md wurde nie geladen, und das Memory-Tool war hart entfernt – selbst wenn du es in den enabled_toolsets eines Jobs genannt hast. Nutzer griffen zu hackigen Workarounds. Cron-Agenten laufen jetzt mit persistentem Speicher, aktiviert wie bei jedem anderen Agenten (#ef04d846e): Jobs können deinen persistenten Speicher lesen – und aktualisieren.

Jeder Job kann außerdem seinen eigenen Reasoning-Aufwand festlegen, unabhängig vom globalen agent.reasoning_effort und den reasoning_overrides pro Modell (#4e1dd1a74):

# schwere geplante Analyse bei high, günstiger wiederkehrender Job bei minimal – globale Standardeinstellung unberührt
hermes cron create "0 7 * * *" --reasoning-effort high --prompt "Deep weekly repo-trend analysis"
hermes cron create "every 5m"  --reasoning-effort minimal --prompt "Health check and report"

Stufen: none/minimal/low/medium/high/xhigh/max/ultra; Stufen, die ein Modell nicht unterstützt, werden vom Provider zur Anfragezeit geklemmt (xhigh auf einem Modell festzulegen, das bei high endet, läuft bei high). Ein leerer String beim Bearbeiten entfernt die Festlegung. Weitere Cron-Muster findest du in unserem vollständigen Cron-Automatisierungs-Guide.

opencode-free: ein wirklich schlüsselloses kostenloses Modell

opencode-free ist jetzt vollständig schlüssellos – keine Env-Variable, kein Konto, anonymer Draht (#ca06b8768) – und der Catalog-Drift-Sync zieht Live-OpenRouter-Free-Modelle in die Liste, während tote Free-Slugs entfernt werden (#624723130). Schlüssellose Provider gelten überall als authentifiziert: opencode-free erscheint ohne jede Einrichtung direkt in /model und in den Desktop-Auswahlmenüs (#2a2307e68):

hermes model    # opencode-free wählen – kein Schlüssel nötig

Falls du noch kein kostenloses Modell konfiguriert hast, bekommst du damit eine funktionierende Option direkt ab Werk. Zusammen mit unseren fünf kostenlosen Suchkanälen kann eine frische Hermes-Installation komplett schlüssellos laufen.

Weitere „niemand macht es, aber alle brauchen es“-Verbesserungen

• Ausführungsdisziplin und Stall-Guards (aus den Erkenntnissen der Composio-Evals): Abbrüche der Hintergrund-Reviews mit korrekter Vordergrund-Priorität synchronisiert (#37da0d4d5, #b883756b7), Ox-Alpha-Reasoning-Aufwand zuverlässig über zen- und free-Provider geklemmt (#d4d04098a), cache-control-Dekoration für Prompt-Caching idempotent (#0fc52b055) – langlaufende Aufgaben stocken seltener und verbrauchen Tokens vorhersehbarer.
• Desktop-Performance: Paint-first-Hydration im Bot Mode, Compositor-Spinner, React Compiler in beiden Renderern.
• Das Bearbeiten von Nachrichten in alten Sitzungen schlägt nicht mehr fehl (#02e270a47); Telegram-DM-Entwürfe behalten nach dem Streaming die reiche Formatierung (#790c85014); der Docker-Stage2-API_SERVER_KEY-Bootstrap hängt nicht mehr davon ab, dass .env existiert (#7a17a1b8a).

Für die vollständige Aufschlüsselung Highlight für Highlight (einschließlich der Listen „Verbesserungen“ und „Fehlerbehebungen“) siehe unsere v0.20.5-Release-Notes. Das Upgrade ist unkompliziert:

hermes update

Nach dem Upgrade hermes doctor ausführen, um die Installation zu prüfen, und das Gateway neu starten (hermes gateway), damit Plattformänderungen wirksam werden. Um vor dem Ausführen zu sehen, was das nächste Update anfasst, beginne mit hermes update --plan. Dieses Release hat kein auffälliges Schlagzeilen-Feature – aber es räumt einen Stapel Aufgaben ab, auf die schon jeder gestoßen ist, und ein guter Frühjahrsputz fühlt sich hinterher großartig an.