Hermes vs OpenClaw: an honest comparison.

If you've spent any time around the open-source agent crowd in the last six months, two projects keep coming up. Hermes Agent by Nous Research, and OpenClaw by Peter Steinberger and a foundation. Both are MIT-licensed. Both are real software people actually run.

We've used both. We have customers running both. Neither is paying us to write this. The point of the post is to help you pick, especially if you keep hearing about these two and not the others.

This is less about who has more features and more about what each one feels like to live with.

The shape of each one

Before we talk about features, talk about feel. The two projects pick up very different vibes the moment you install them.

OpenClaw is laptop-first. You install it on your Mac (or Windows, or Linux), and it lives there. You talk to it in WhatsApp, iMessage, Telegram, or Slack. It opens your browser, reads your files, runs shell commands. It's the closest thing we've used to an actual personal assistant. Most users land on it through a chat interface from their phone while the laptop is somewhere else, doing the work.

Hermes Agent is server-first. You install it on a box you own (typically a server, sometimes a workstation), and it's designed to live there. The chat surface is the same set of platforms (Telegram, Discord, Slack, WhatsApp, Signal, Email, CLI), but the project assumes the agent is doing real work in a place that's not your laptop. You can run it on your laptop too, but the design isn't centered there.

This is the single biggest difference, and it shapes everything downstream. If you want an agent that lives on your laptop and feels like a personal OS, you'll like OpenClaw. If you want an agent that lives on a server and runs as part of your infrastructure, you'll like Hermes.

What it feels like to set up

OpenClaw is famously easy to onboard. There's an openclaw onboard command that walks you through provider keys (Claude or OpenAI), connects your chat platform of choice, and you're talking to it within a few minutes. The first time we tried it the longest step was scanning the WhatsApp QR code. The default experience is polished in a way that almost no agent project we've used can match.

Hermes is also a one-line install (a single curl command), but the experience after install is more "configuration document" than "wizard." There's a hermes setup command, plus more knobs to turn: which model provider, which sandbox backend, which chat surfaces, which profile. None of it is hard, but it's a project that expects you to know what you want. It rewards an opinionated user.

The split is fair: OpenClaw is built for the developer who wants to use an agent; Hermes is built for the developer who wants to deploy one.

What it feels like to use

Both have persistent memory. Both build skills as you use them. Both can browse the web, read and write files, and run shell commands. The day-to-day differences are smaller than the install experience, but they're real.

OpenClaw has the more polished user-facing surface. Replies in chat feel responsive. The skill-discovery path (you can ask the agent to write a new skill mid-conversation) is a genuinely good UX. The community is enormous: by spring 2026 the GitHub repo had 247K stars and almost 50K forks. There are weekly community skills shipping for things like Spotify, Obsidian, Gmail, GitHub, plus a long tail of weirder ones.

Hermes feels more like a research-backed agent runtime. It has a self-improvement piece (a companion repo that automatically tunes prompts and skills based on past runs) that you don't see in OpenClaw. It supports a wider set of model providers, including a long list of open-weight ones (Nous Portal, OpenRouter, NVIDIA NIM, several Chinese open models). For a user who cares about running on open weights, this is a real differentiator. For a user who's happy on Claude or OpenAI, it's invisible.

In day-to-day chat? They feel similar. Both are good at the agentic loop. Both let you scope tasks across long-running conversations. The biggest experiential difference is that OpenClaw feels personal and Hermes feels operational.

What it feels like to build for

If you're a developer extending one of these (writing a skill, adding an integration, plugging in an internal tool), the projects diverge again.

OpenClaw's extensibility story is community-grassroots. There's a community skills directory. You can fork a skill, modify it, ship it. The agent can write its own skills inside chat, which is genuinely useful. Most of the integrations you'd want already exist as community plugins, so building from scratch is rare.

Hermes's extensibility story is more architecturally formal. First-class MCP support means anything that speaks the Model Context Protocol drops in cleanly. Subagent delegation is built in: you can have the main agent spin up isolated child agents with their own conversations and shells, useful for splitting up complex tasks. There are five execution backends (local, Docker, SSH, Singularity, Modal), so you can run skills in whichever environment fits the work. This is the part that feels obviously built by an org.

For a developer extending either project, OpenClaw is faster to ship a new skill in. Hermes gives you more knobs once you need them.

Origin stories, since they matter

The shape of each project comes directly from who built it.

Hermes Agent comes out of Nous Research, the team behind a long line of open-weight LLMs. Hermes Agent is the natural extension: if you ship open models, eventually you ship the runtime that uses them. The wide model-provider support reflects that. It's a coherent multi-product roadmap.

OpenClaw comes from one developer, Peter Steinberger, who shipped it in late 2025 (originally as Clawdbot, then renamed twice after Anthropic flagged the trademark resemblance to Claude). The project went massive in three months. In February 2026 Steinberger joined OpenAI and stewardship transitioned to a non-profit foundation. Worth knowing if you're betting your stack on it: large open-source projects outlive their founders all the time, but the transition is recent enough that the community is still finding its rhythm.

The takeaway: Hermes is what an AI-research org builds. OpenClaw is what a frontier-shipping solo dev built and then handed to a foundation. Both make sense in their own ways.

Models

Worth a short note since it's a real differentiator.

OpenClaw supports Claude, OpenAI, and local models. Most users run Claude. The project was originally built around Claude and the agentic loop is genuinely tighter on it.

Hermes supports the same plus a longer list of open-weight providers. There's also a fallback-providers feature, so you can chain "use Nemotron, fall back to Claude, fall back to a local model." If running on open weights is a real preference for you, Hermes is the answer.

Honest read: for the agentic loops most teams care about today, Claude Opus and Sonnet are still meaningfully ahead at multi-step tool use. OpenClaw is built to capitalize on that. Hermes is built to be ready when the open ecosystem catches up.

Which one should you pick?

The boring answer that's the right answer:

• You + your laptop + WhatsApp/iMessage: OpenClaw. Polished, big community, "personal AI" UX.
• You + a server you own + headless work: Hermes.
• You + a hard preference for open-weight models: Hermes.
• You + Claude as your main model: either, but OpenClaw will feel slightly tighter.
• You + you're new to agents: start with OpenClaw, the onboarding is genuinely easier. Come back to Hermes if your shape becomes server-fleet.

Both are excellent. They are excellent at different things. The temptation is to pick the more popular one (OpenClaw, by a wide margin) and assume it's the better choice. It's the better choice for some shapes. It's not for others. Pick based on where the agent should live and how you want it to feel.

What neither project solves

Both are extremely capable runtimes. Both let agents browse the web, run shell commands, manage files, and call external services. Both can speak to paid APIs.

What neither one tracks (and this isn't a knock, it's just a different layer of the stack): what the agent has spent today, whether the next payment should go through, who approved any specific transfer, and what the audit trail looks like at the end of the month.

The moment your agent stops just fetching and starts paying, you need a layer the runtime doesn't provide. That's where Canopy fits.

A short word on Canopy

Canopy is the spend layer for AI agents. A treasury at the org level, a per-agent wallet that signs on its behalf, and a policy that decides which payments get through and which don't. Spend cap per rolling 24h. Allowlist of services your agent is allowed to pay. Approval threshold for anything that crosses a dollar amount you set.

Canopy works with both:

• OpenClaw: wire Canopy in as a plugin or via the SDK. The agent calls canopy.pay() or canopy.fetch() instead of spending raw. Every payment passes through the policy first.
• Hermes: Hermes has first-class MCP support. Point it at Canopy's hosted MCP, authorize once, and the full Canopy tool surface is in the agent's context. Same policy enforcement, no SDK install.

Either way, your agent gets a wallet it can't drain, a recipient list it can't escape, and an audit trail finance can defend. The runtime decides what the agent does. Canopy decides what the agent is allowed to spend doing it.

Same control plane, two different runtimes. Pick the runtime that fits your shape; the spend layer is the same either way.

Read the docs, or npx create-canopy-agent to wire one of these up.