.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
If you've spent any time in the self-hosted-agent corners of Reddit or Discord this past month, you've probably seen the "is OpenClaw cooked" thread spin up about every six hours. The answer most people are looking for isn't "is OpenClaw broken" (it isn't) or "is Hermes better" (it depends). It's the more practical one: should I move my actual setup right now. Or is this another community panic that'll feel silly in three months?
Personally, I don't think OpenClaw is "cooked". But I do think we should "let Hermes cook".
Here's how I'd think about it if you came to me with a real running OpenClaw install and asked, point blank, if you should switch.
The case for staying on OpenClaw, at least for now
OpenClaw works. It still runs your Telegram bot, still answers your morning briefing query, still books calendar entries. The CVE wave that lit up the news in March 2026 mostly affected exposed instances running with default registry trust. The malicious-skill problem was concentrated on ClawHub uploads from a small number of bad actors. If your install isn't reachable from the public internet, doesn't auto-install community skills and you're not running an unattended skill-update cron, you're in better shape than the 12 percent of installs that the various security writeups warned about.
OpenClaw also has the deeper integrations matrix. The custom API skill set, the file-management automations, the SMS and iMessage paths, all of that has years of community polish on it. Hermes is catching up fast, but "catching up fast" still means specific gaps right now. If you rely on iMessage via BlueBubbles or you have a customised Gmail integration with a hand-tuned skill that took you a weekend to dial in, that work doesn't carry across cleanly. The migration tool brings the skill files. It can't bring the muscle memory of having debugged each one through three subtly broken iterations.
And there's the operational cost of switching. If your OpenClaw install has been quietly running on a small VPS for eight months, never crashing, the upside of moving is incremental at best. Self-improving learning loops are interesting. They're not interesting enough to compensate for a week of "wait, why doesn't this work the same way" friction during the cutover.
The case for moving to Hermes Agent
The pull factors are real, though. They're not all about CVE counts.
The first is architectural. Hermes treats memory as three separate layers (frozen system-prompt files, episodic skills and a searchable session DB) and exposes each layer to the user as something you can read, edit and prune. OpenClaw's memory model is more opaque, which is fine until you want to know exactly what the agent thinks it knows about you. If you've ever wished you could grep your agent's memory and read it back as a flat file, Hermes is the one that makes that easy, because the entire memory layer is just MEMORY.md plus USER.md plus a SQLite database you can query with the standard sqlite3 CLI.
The second is the learning loop. After a handful of successful runs of a similar task, Hermes generates a SKILL.md capturing what worked. That skill is then reused on later tasks. You can read it, you can edit it, you can delete it if it learned the wrong lesson. OpenClaw has skills too, but they're things you write or install. Hermes writes them for you. For some workflows that distinction is cosmetic. For agentic work where you want the agent to get faster at recurring tasks without you babysitting it, it's the kind of capability that quietly changes how you use the tool.
The third is the licensing and telemetry posture. Hermes Agent is MIT-licensed end to end with no telemetry. OpenClaw is also open source, but the foundation transition created some genuine uncertainty about how governance will look in 12 months. If the foundation question matters to your stack (think enterprise procurement, sectoral compliance, anything where governance documents get reviewed), the cleaner story Hermes tells right now is worth something concrete.
The fourth (the one nobody likes to admit publicly) is momentum. Hermes is shipping a major release every week or two. Every release adds providers, adds messaging platforms, fixes long-standing bugs. The pace is faster than OpenClaw's right now. The bug-fix-to-feature ratio in recent Hermes releases has been good too. If you want your agent to keep getting better without you having to fork the project, you go where the velocity is.
The middle path almost nobody talks about
You don't have to choose. Both agents can coexist on the same machine. Both will happily run in parallel, on different bot tokens, with different memories. I've been running both side by side on my main work box for a month and the only time they collide is when I send a message to the same Telegram bot from both directions, which is a self-inflicted problem.
The pattern that works for most people who can't decide: install Hermes alongside OpenClaw, point Hermes at a separate bot token (a fresh @MyName_HermesBot is two minutes of BotFather), let it learn over the course of a few weeks of real use. Compare them against each other on tasks you run regularly. After a month, you'll know in your bones which one fits your work. The other one stops getting messaged. The side-by-side guide covers the port and resource isolation details. There's nothing exotic about running both, just a couple of bits of housekeeping to keep them from stepping on each other.
The migration is reversible, mostly
One reason people freeze on this decision is they think it's irreversible. It isn't. hermes claw migrate doesn't touch your OpenClaw install. It reads from ~/.openclaw/, writes to ~/.hermes/ and creates a snapshot of any Hermes files it overwrites in ~/.hermes/migration/openclaw/<timestamp>/. So after a migration you have three things: your original OpenClaw setup (untouched), your new Hermes setup (populated from OpenClaw) and a snapshot of what Hermes looked like before the migration.
If you migrate and decide you preferred OpenClaw, you stop the Hermes gateway, optionally rsync the snapshot back over ~/.hermes/ and you're back where you started. Your OpenClaw install never went anywhere. The only thing you can't easily undo is "I wish I'd kept my old gateway running on the same bot token", because Telegram only routes webhooks to one place at a time. That's solved by either keeping a second bot token reserved during the trial period or by switching DM targets back via BotFather, which takes about thirty seconds.
A short decision tree that fits on a napkin
Strip out everything I just said. The question reduces to four conditions, in roughly this order.
Are you running OpenClaw on a publicly reachable address with the default ClawHub trust enabled? Migrate now or, at minimum, lock down the trust settings using the OpenClaw security best practices guide. The CVE wave wasn't a media artefact. People did get popped.
Do you have a custom skill that took you a long time to write and that you'd hate to lose? Migrate cautiously, do a dry-run first, plan a couple of hours to fix up frontmatter and tool-name renames after the import. The migration tool gets you most of the way; the last 10 percent is hand work.
Are you happy with your current setup and not seeing any specific limitation? Stay on OpenClaw, set a calendar reminder to revisit in three months. The pace of Hermes development means the comparison will look meaningfully different by then anyway.
Are you starting a new project or new agent setup from scratch? Just start with Hermes. The architectural defaults are better and there's nothing to migrate.
Cost, briefly
People assume the cost picture is identical because the agent is a thin client and the LLM provider is what bills. Mostly true. There's a per-call overhead difference, though, that adds up with heavy use. Hermes carries roughly 13K tokens of system prompt and tool definitions per call by default (the token cost article walks through the breakdown). OpenClaw's overhead is comparable but a few hundred tokens lower, in part because its tool surface is leaner.
For someone making a few dozen requests a day, this is a few cents a month difference. For someone running an agent that handles real work and turns over thousands of calls a week, it's noticeable. Neither is the cheap option. If cost is the primary driver and you're using a paid provider, the better optimisation is provider choice (free Nous Portal MiMo tier, OpenRouter cheap models, self-hosted Ollama) rather than which agent runtime you pick.
If you're going to do it, do it cleanly
There's a temptation to migrate during a frantic half-hour because someone in the Discord just posted another CVE. Don't. Schedule it for a Saturday afternoon, take a snapshot of ~/.openclaw/ first, run the dry-run, read the output, run the real migration, verify the persona and a couple of skills, then leave the new setup running for a few days before you make any other changes. The full step-by-step is in the migration walkthrough.
If you're doing the migration on fresh infrastructure rather than upgrading in place, the LumaDock Hermes Agent VPS template gives you an Ubuntu 24.04 box with the install already done. You scp your OpenClaw tarball across, run the migration once and decide if you like it before changing anything on the original server. The first-login flow is documented in our VPS setup guide if you want a quick orientation before you start.
