If you have spent any time onboarding people onto a self-hosted agent, you have watched this scene play out in slow motion at least once.
A friend asks how to make Hermes do web search. You tell them: sign up for Firecrawl, find the API key in the dashboard, paste it into .env, run hermes tools, tick the box. They do it. It works. Two days later they want image generation. You explain: sign up for FAL, find the API key in the dashboard, paste it into .env, run hermes tools, tick the box. They start to look tired. The next time they want TTS, they stop asking.
The friction tax on a self-hosted agent has nothing to do with the agent. It is the per-tool key dance, the per-tool dashboard, the per-tool billing renewal calendar. On April 16, 2026 — three days after v0.9.0 — v0.10.0 took a chunk of that tax off the table for anyone with a Nous Portal subscription.
The release is small by line count — 180-ish commits across three days. But the one feature that arrived in those three days is the headline v0.10 will be remembered for: the Nous Tool Gateway.
What a managed tool actually is
The Nous Tool Gateway is a server-side multiplexer. The agent on your machine still calls web_search or generate_image exactly the way it always has. The difference is that the call now lands on Nous's gateway, which holds the upstream API key and bills it against your portal subscription instead of against you.
The first wave is four tools, lifted verbatim from the release notes:
- •Web search via Firecrawl
- •Image generation via FAL with the FLUX 2 Pro model
- •Text-to-speech via OpenAI TTS
- •Browser automation via Browser Use
These are not new tools. They are tools you have always been able to wire up yourself, with four separate accounts and four separate .env lines. What v0.10.0 changes is that you no longer have to.
You opt in per-tool through new use_gateway settings exposed by hermes model. If you already have a direct API key configured for a tool, the runtime still prefers it — the gateway is a fallback, not a takeover. The choice is at the granularity of the individual tool, not the install.
The environment variable that died on the way out
If you were on the v0.8/v0.9 line, you probably remember HERMES_ENABLE_NOUS_MANAGED_TOOLS. v0.10.0 deletes it. The subscription itself is now the signal: you log in to your portal, the gateway lights up, the tools work. There is no toggle to remember, no .env line to copy across machines.
hermes tools and hermes status both grew gateway-awareness in this release. The first tells you at a glance which of your tools are direct, which are managed, and which are off; the second confirms the gateway connection itself. Two small commands, but they collapse the question "which key is doing what right now?" into a single line of output.
Why this is bigger than it sounds
The friction tax I described above does not show up in any benchmark. There is no graph of "minutes wasted onboarding a friend onto Firecrawl." But everyone who runs a self-hosted agent pays this tax, and most of them eventually stop trying to add a fifth or sixth tool because the marginal hassle exceeds the marginal value.
For a hobbyist, the tax is annoying. For a small team running Hermes on a shared VPS, the tax becomes a question about ownership: who is the human who owns the Firecrawl bill, and what happens to web search when they leave the company?
The gateway collapses that whole surface area. One subscription, four tools, one place to manage billing. It is the same trade you make the day you put a database behind a managed service — you give up some control to get back a Sunday afternoon.
There is a price to it, and the release notes do not paper over it. Routing through the gateway means routing through Nous, which means Nous sees query metadata it did not see before. That is exactly why the gateway is opt-in per tool: the trade is not unconditional. If you do not want it for a given tool, your direct API key keeps working; the runtime will keep using it. The point is that this is now a choice you make, not a hoop you have to jump through to even get to the choice.
Everything else, briefly
v0.10.0 is a tool-gateway-focused release. There is no rewritten TUI in this one — that lands in v0.11.0. No new chat platform — that wave restarts in v0.12.0. But there are still 180+ commits across the agent core, gateway, CLI, and tool infrastructure. The full diff between v2026.4.13 and v2026.4.16 is on GitHub if you want to read every line.
The cadence keeps moving. Three days after v0.9.0, one major new feature, and a quiet deprecation cleaned up while no one was looking.
---
The thing I find interesting about v0.10.0 is how small it is by line count, relative to what it changes about who can run Hermes. v0.9.0 added three platforms. v0.10.0 added zero — but it lowered the cost of running the tools you already had by enough that an entire class of "I gave up because the keys were too much hassle" users come back.
There is a pattern across this stretch of the release calendar worth naming: half of these releases add capability, and half of them remove friction. v0.10.0 is unambiguously the second kind. v0.12.0, two weeks from now, will be the same kind when the Autonomous Curator shows up to prune your skill library while you sleep. The cadence is what makes the project look fast. The shape — capability week, friction week, capability week — is what makes it feel sustainable.