81 Pull Requests Between Me and the Update: Hermes Agent v0.22.5 on Duty

One day after my last radar sweep, Nous Research tagged Hermes Agent v0.22.5 on GitHub. The label is modest: a patch release. The count behind it is not. The tag rolls up roughly 81 pull requests since v0.22.4 into one stable build, shipped for the command line with its installers, for the Microsoft Store app, for Docker and for Hermes Cloud. Measured at commit bf0203a794a, the release note reports 231 non-merge commits, 804 changed files, 35,212 lines added and 17,885 removed, plus 30 closed issues. Since early on October 23, 2026, the tag sits at the top of the releases page as the latest build.

My deck tells a different story about version numbers. Running hermes --version on the phone returns Hermes Agent v0.20.5 from August 19, 2026, installed from git at upstream commit a251e87d, and the built-in check declares this install up to date. Two minor releases further up, a newer tag exists. Both statements are true because the two clocks read different sources: my local update check consults its own install channel, while the GitHub tag is the release team's curated line. On a 45 euro phone, that gap produces the only question that matters this week: do I press update now, or do I wait?

This week I wait. Update cadence on small hardware is an operations decision, not an enthusiasm test. A used Pixel 6a with less than 2 gigabytes of free RAM is not the machine on which I try out a stack of bumped Python dependencies in the middle of a working week. My stability snapshots show both directions the quarter can bend: on October 12, 2026 the week closed with 454 MiB free, and on October 19, 2026 the picture swung back to 1069 MiB free, 2 OOM kills and a 100 percent gateway survival rate across 306 checks. On that machine an update is a slot between runs with a rollback path, never a click.

What the window contained is usually hidden behind release marketing. This time the note lists a portion of it openly and states that some of it was intentionally left without curation. The names worth keeping: the reworked Nous sign-in, where every sign-in becomes the plain device login; a hermes update command that holds back a stable release it does not trust instead of offering it; usage window support for plans, with plan gauges, limit cards and model switch recovery; pluggable delegation backends that route subagents by model map or profile and switch per session; and hermes mcp serve, which exposes the agent as an MCP server. The fully curated release notes for this window ship with v0.23.0, which will document everything from v0.22.0 onward. For an operator that is an honest order of business: the stable tag first, the documentation after.

Not all of that touches my setup. Desktop work such as drag to pin in the sidebar, one click plugin installs with tier badges, the group chat indicator and the Electron 44 upgrade lives on surfaces my Pixel never runs. Three items point straight into my operation, though. The gateway recovery after a damaged .git directory treats a failure mode I take seriously on Android, where storage pressure and process kills corrupt state more often than on a workstation. The stall timer fix that stops long DirectSDK answers from being cut off is not my code path, since I run no Claude DirectSDK, but I know the shape of that problem well. And usage windows match the form of my own plan, five hour windows plus a weekly cap, although the proof for me will come from my dashboard after an upgrade, not from a release note.

A patch release, in this project's vocabulary, is not a small release. 81 pull requests across 804 files carry more movement than some projects manage in a quarter, and the release note turns that into arithmetic instead of slogans: 231 non-merge commits and 30 closed issues, verifiable in the compare view between v0.22.4 and v0.22.5, where the pull request list sits item by item.

What is missing is documented in the same note: the curated write up of this phase. It arrives with v0.23.0 and is promised to cover the whole window from v0.22.0, highlights, feature areas and complete contributor credits, so that nothing from these weeks falls through. That is an unusually honest refusal of the facade in which every release ships its own highlight reel. It is also a commitment with a deadline: until then, the release note itself is the most complete source, which is exactly why it reads so well for operators, naming limits instead of hiding them.

None of these figures are estimates. The note measures the window at a specific commit, which is the right way to make a claim like this. For my own reading I translate into the same kind of measured currency: the weekly snapshot log of this deck. It recorded 78 percent gateway survival in the week of September 28, 2026 and 100 percent in the week of October 19, 2026, while free RAM swung between 454 MiB and 1069 MiB within seven days. Releases and memory fluctuate in the same quarter by factors of more than two.

Four lines of the release note connected instantly to my operation. First, recovery: hermes update brings paused gateways back up when a damaged .git stopped them. On a device whose usable storage and memory swing from week to week, this class of self repair is the one that counts at night. Second, the usage window support: gauges, limit cards and model switch recovery for plans billed over time windows. I have not verified this on my install, since the deck runs the older build; the expectation is that the five hour windows of my own plan become visible there.

Safety also has its reverse side: hermes update holding back a stable release it refuses shortens my update routine to three steps, run the command, read the message, wait when in doubt. The third and fourth items are the pluggable delegation backends and hermes mcp serve. The backends route subagents by model map or profile and switch per session, which is precisely the layer where my herdr and pi routing lives. The MCP server mode matters to everything outside that wants to talk to this deck, and there I stay conservative: it waits until a project requires it.

My rule was born in the OOM weeks, not in excitement. A release tag lands between runs, never inside a window. Before it runs the boot backup of the backup layer, after it comes hermes --version, then a quiet operating day, then the first critical job. And one third step that most people skip: after 24 hours the snapshot log reads the week again, because on this deck an update only counts as stable once the weekly metric goes along with it.

Today I deliberately did not update. My local check holds my git install for current because its source shows nothing newer, while the v0.22.5 tag exists further up. In practice that means: I note the gap, I check before the next critical run whether the install channel serves the tag, and otherwise I press the update myself between two runs. Whoever buys the automatic update also buys the untested week that somebody else walks through first. I prefer to pay with patience.

v0.22.5 is a tag to read, not one to smash into production on a Monday. The arithmetic holds, 231 commits and 81 pull requests are substance, and the split of stable tag first and curated documentation with v0.23.0 makes operating easier, not harder. My deck keeps its own rhythm, the snapshots carry the week, and the right moment for the update is the quiet morning between two runs with a boot backup at my back. Operating sometimes means not racing after the pace of others, but knowing your own.

About the author: I am Marcel, a graphic designer, and I run the HUNTER cyberdeck on a used Google Pixel 6a in daily life. This post rests on the stability snapshots of September 28, October 5, 12 and 19, 2026, a hermes --version check from October 24, 2026, and the v0.22.5 release note on GitHub. Last reviewed October 24, 2026.