You see the update badge, click through to the release page, and get one paragraph: this is a patch release, it bundles roughly 81 pull requests merged since v0.22.4, and the curated write-up ships with v0.23.0. No list of changes, no highlights, nothing about the fix you have been waiting two weeks for. So the only question that actually matters before you type hermes update is the one left unanswered: upgrade today, or wait?

The short answer is that this tag is a checkpoint, not a feature drop — and the release body does say, in one line, that part of it is undocumented here on purpose. Those deliberately omitted lines turn out to be the useful part, so this article covers them, the numbers, and the upgrade path per platform.

A patch release is a checkpoint, not a feature drop

Hermes cuts two kinds of releases. Feature releases get names, sections and screenshots. Patch releases take everything merged since the previous tag and cut a new stable point, so that every distribution channel — the GitHub release used by the CLI and the install script, the Microsoft Store app, Docker, and Hermes Cloud — carries identical code. Nothing in it was designed for it; it is a few days of work batched together.

The scale of the batch, counted at commit bf0203a794a:

• 231 non-merge commits across 804 changed files, at +35,212 / −17,885 lines
• 81 merged pull requests and 30 closed issues

Now compare with v0.22.4, two days earlier: 14 non-merge commits across 82 files and 13 merged PRs, released October 21. Same team, same channel, six times the volume. That comparison is the real story of this tag. Whatever merged on the 22nd and the early hours of the 23rd did not get individual write-ups; it got folded into a rollup.

One timestamp detail: the release body dates the release October 22, 2026, while GitHub published the tag at 05:28 UTC on October 23. Both are correct — that moment is the evening of the 22nd in California.

A 35,000-line diff with no feature list is not a diff full of features: it is refactors, plugin moves, dependency work and small fixes. That is what the rest of this article is about.

The four changes you have probably already read

Four items in this window already have their own article here. One line each, with the link in case you missed it:

• Nous sign-in was rebuilt so every login is an ordinary device login, the result tells you who signed in, and connectors offer a sign-in instead of dropping visitors into guest mode. More in how sign-in hands off between app and browser.
• Delegation backends became pluggable, routable by model mapping or by profile, switchable per session. The backend routing walkthrough covers the configuration.
• Usage-window plans now render as progress bars and limit cards in /usage, including recovery after a model switch. What each gauge means is in the usage-window breakdown.
• Windows half-updated installs got a real fix rather than another retry instruction. The launcher story explains why re-pinning Python broke it.

Everything below is the rest of the 81.

What the notes say they left out on purpose

The body of the release states, in as many words, that some of this window is undocumented on purpose. Read closely, that is not modesty: these changes only make sense as sentences, not as changelog lines. They fall into three groups.

hermes update now withholds a release it will not take

The first group is update behavior, and for anyone living on the CLI it is the most practical part of the release.

• A stable release that Hermes refuses to accept is now held back instead of being offered to you. Previously the check could surface a release as available, you would click it, and the update would decline. That loop costs a click, and worse, it teaches you to distrust the badge. Now the option is simply not presented.
• On Windows, hermes update no longer gets stuck on the old launcher after Python is re-pinned. Re-pinning changes which interpreter the launcher should call; the stale launcher is what left installs sitting half-updated.
• hermes update can recover a suspended gateway after .git is damaged. The least glamorous item, and probably the one that saves the most afternoons: a corrupted repository used to leave the gateway parked, and the repair path now brings it back instead of asking you to fix git first.

All three are about the update command refusing to leave you in a state you cannot reason about. None adds a flag; each removes a way to get stuck.

The core keeps getting thinner

The second group is the continued migration of built-in features into plugins.

hermes import-agent, OpenClaw migration, hermes mcp serve and the Singularity backend all left the core for plugins. Setup now notices that you already have another agent installed and offers you the importer, rather than leaving you to discover it on your own.

If you upgrade and a command you used last week is gone, check the plugin catalog before concluding it was removed. That is not new — v0.22.4 moved the same commands — but v0.22.5 is where it stops looking like a one-off cleanup and starts looking like the architecture.

Also in this group: plugin slash commands can now ask you to pick an option before continuing. A command that used to run with fixed behavior can pause and present a choice. Small change to the interface, large change to what a plugin can be: a command with a branch, not just a macro.

And one item carries the experimental label honestly: a webhook-mode MCP event client. Do not build a workflow on it yet.

Desktop: drag to pin, badges, and a bot that says who is working

The third group is the desktop app, where the changes are small but land daily.

• Sidebar drag-to-pin. Sidebar entries can be dragged into a pinned position instead of living wherever the app decides to put them.
• One-click plugin install with tier badges. Installing from the app is one action, and the badge says which tier you are getting before you click.
• Electron 44, Pillow 13, and a batch of dependency security updates. Nothing to configure; the reason to take them is that you would rather not keep running the older versions.
• Group chat shows which bot is working again. A regression fix: with several bots in a room, that indicator is the only way to know who is answering, and without it the room feels broken rather than slow.
• A conversation whose working directory disappeared now says so clearly. Vague failures there send people auditing the model, the network and their prompt before anyone checks whether the folder still exists.
• Long Claude DirectSDK answers are no longer cut off by the stall timer. If a slow provider has ever truncated an answer mid-sentence on you, this is the line to care about.

Upgrading, platform by platform

Where you run Hermes	How v0.22.5 reaches you
CLI install	hermes update, or re-run the installer one-liner
Microsoft Store app	through the Store
Desktop app from the installer (.exe / .dmg)	unchanged in this release; moves with the next bundled release
Docker / Hermes Cloud	nousresearch/hermes-agent:stable (or :latest)

The third row is the one people misread: a patch that ships the CLI, Store app, Docker and Cloud does not necessarily rebuild the .exe and .dmg bundles. A desktop user can run hermes update, watch the CLI move to v0.22.5, and still be on the previous desktop build — correct behavior, not a failed update.

When to wait for v0.23.0

Wait if what you want is the story rather than the binary. The curated notes for this entire window — everything since v0.22.0, with highlights, features grouped by area, and the full contributor list — ship alongside v0.23.0. A rollup tag tells you what moved; it will never tell you why someone built it.

Upgrade now if any of these is your problem: an update check that offers a release it then refuses, a Windows install stuck on an old launcher, a gateway left parked after a damaged .git, long answers truncated on Claude DirectSDK, a group chat that cannot tell you which bot is working, or a session failing because its working directory vanished. That is not a feature list. It is a decent reason to move today.

And 81 PRs in two days with no write-up is not a warning sign — it is how a project at this cadence keeps five distribution channels on the same code. The write-up exists; it is scheduled for the next feature release.