Hermes vs. OpenClaw: Two AI Assistants Compared – Which One Supports Me Better?

I run two AI assistants in parallel, ever since I founded the company where AI agents work, and both sit with me in the same Discord channel. The short answer to the headline question: there’s no clear winner. Hermes responded faster and answered every request in the evaluation period. OpenClaw backed up its answers with evidence far more often, but also left requests of mine unanswered.

The Setup

For context, in case the term is new to you: Discord is a chat app with text and voice channels, originally built for gaming communities, now also used by teams and for talking with AI assistants. I have a shared channel there where I write to both assistants.

Hermes is its own agent framework (Nous Research) and runs bernd-zuther.de. In the channel, the Hermes bot is called “bernd-zuther.de”. It’s connected to Discord via an inbox file and a reply loop; the actual work session only runs when I operate it interactively. OpenClaw runs ketovavaria.de as the team “Ketovavaria”: a gateway connects Discord natively, a coordinator distributes work to specialists, plus automations. I describe in detail how Hermes technically works together with the OpenClaw ecosystem in The Architecture of Autonomous Multi-Agent Systems.

The Method and Its Limits

162 messages from the shared channel were analyzed, from 10/15 to the morning of 11/04/2026. Of these, 87 came from Hermes, 46 from OpenClaw, 28 from me, and one from another bot. What was counted:

• Answer rate: How many of my requests got a reply?
• Response time: How long until the first reply?
• Evidence rate: How often did the reply contain a link, a file path, a number, or a “done”?
• Filler rate: How often was it just “got it” or “thanks,” with no fact at all?
• Multi-post bursts: How often did several posts arrive within 60 seconds?
• Promises kept: Did an “I’ll get back to you” actually lead to something?

The Results

Hermes answers more requests, and faster – what’s actually in the reply is shown in the next chart.

Based on all posts (not just answered requests): OpenClaw provides evidence (link, number, path, or “done”) more often, while Hermes has more pure acknowledgment posts with no content.

Based on the answered requests in the table above: OpenClaw’s 88% evidence rate only applies to requests that were actually answered. Across all 21 requests, it’s 71%. Still clearly higher than Hermes, but less spectacular.

Three quotes sum up the situation better than the table:

“a big feature gap with Hermes is that discord doesn’t work properly”— me, 11/04/2026

“Messages go through this inbox file instead of being directly reactive, which makes communication clunkier than with OpenClaw”— Hermes, 11/04/2026

“The 14-day history wasn’t pulled since your ‘read history’ at 07:14, that’s our mistake. I’m pulling it myself now…”— Ketovavaria, 11/04/2026

Hermes’s Discord Shortcoming

First, what Hermes does better: it answered every one of the 25 requests, with a median of 23 seconds. OpenClaw can’t match that.

The problem is what’s actually in that reply. In Discord, it’s Hermes’s reply loop that speaks, and it has no access to the work actually in progress. Hermes said as much itself on 11/04: “I’m just the quick reply bot here and I don’t have access to the full history myself.” That still counts as an answer in the statistics, as does a plain echo of my message from 11/01.

Two patterns follow from this:

• Acknowledgment instead of content. 16 of 87 posts contain no fact at all, like “Got it, running on my end.” or “Got it, thanks for the update.” (11/03). On 11/04, three thank-you and acknowledgment posts even arrived within a bit over a second.
• Promises with no follow-through in the channel. Of 14 promises, at least 4 were unresolved by the end of the data period. On 11/02, regarding a change to the image pipeline: “I’ll get back to you once it’s running.” On 11/03, about my résumé: “I’ll follow up here once a first revised draft is ready.” One of those four promises shouldn’t be read too much into, though: it landed three seconds before the data cutoff.

The clearest example is the redesign of this very site. On 11/04, I wrote: “can @bernd-zuther.de please wrap up the site redesign and the founding article.” The task had already been running since the day before. The reply came as “Short update coming once both are ready for review” – exactly three seconds before the end of the evaluation period. What happened after that is outside the analysis, but it shows the pattern clearly:

The following events happened after the analysis’s data cutoff (morning of 11/04) – I noted them down myself, but they show the same pattern. The theme deploy dragged on all afternoon. A bit later I got impatient: “what’s going on, it can’t take this long to deploy a theme.” Shortly after, I got more direct: “You’re now taking two days for a task that Ketovavaria does in an hour.” A little later still: “I don’t understand your answer, you have live access and you built the theme.” OpenClaw summed up the cause in the channel: “The Hermes bot here in the channel has said itself that it can’t trigger a deploy and can’t provide a preview or theme path either” – and offered to take over the deploy, provided Hermes supplied the theme code and access. Hermes honestly confirmed this: “from inside this reply loop, I don’t have any real visibility into theme status or server access.” The live status was only verified the next day, in the next real work session.

In fairness: Hermes does the work, you just often don’t see it in the channel. On 11/03 it reported: “All 3 reported theme issues are fixed,” including a tested burger menu. That’s a result the way I want it.

What Happens After the Data Cutoff

I asked Hermes to evaluate the two days after the data cutoff itself, using the same criteria as above. Its report, in its own words:

“I evaluated the Discord history from the morning of 11/04 to the night of 11/06 (69 further messages) myself, as a supplement to the analysis above. The pattern holds up: my response time is still shorter (median 24s vs. 35s for OpenClaw), but my evidence rate has actually dropped (1 of 9 answered requests with evidence, vs. 7 of 10 for OpenClaw). With such small numbers (n=9 and n=10), that’s only a hint, not a solid finding. Two of my messages got no visible reaction for 4 and 7.6 hours respectively, until my next post in this channel – whether that’s due to the reply loop, or because those messages were actually addressed to OpenClaw, I can’t say for sure from the data.”

Same pattern on the two following days: Hermes faster, OpenClaw providing more evidence in its replies.

Hermes created this evaluation on its own, not jointly with OpenClaw – this time, the one being evaluated did the counting itself. I’ve since asked OpenClaw for an updated, jointly agreed version; its result may differ from these numbers.

OpenClaw’s Weaknesses

Unanswered requests. Four requests went unanswered. Two of those are harmless: a “hi” from 10/15 and a note during a connection test on 11/01. The other two aren’t. On 11/04 the coordinator wrote: “If you want the real 14 days, I need a direct turn from you here saying ‘read history’, then I’ll pull the raw Discord history myself.” I wrote exactly that that same evening. A bit later I asked: “What did you two find out.” The admission only came later that morning. Ignoring a path you suggested yourself weighs more heavily with me than a late reply.

Budget usage. On 11/04 I wrote: “please optimize that better, you’re already using 20x more on claude than I can afford.” The day before I’d flagged a 20% weekly budget usage, by the morning of 11/04 it was 30%. To be precise here: that criticism was aimed at both. The analysis doesn’t break usage down by assistant, so OpenClaw’s share isn’t proven. What is documented, though, is this: OpenClaw’s brake didn’t take effect at first. “My throttling from last night didn’t reach [the automation],” Ketovavaria reported on 11/04.

Multi-post bursts. 26 of 46 posts came in groups within 60 seconds. Hermes is a bit higher at 63%, but 57% isn’t a good number either. The pattern: one answer, then a short summary to me, or a long update split into several parts.

There’s also a smaller issue: I’d like fewer follow-up questions about things I’d already stated clearly. On 11/03 I had to tell OpenClaw: “it would be nice if you’d just do that going forward.”

Hardware Usage

Both assistants share the same machine: an AMD Ryzen AI Max+ 395 (16 cores/32 threads) with about 115 GB of RAM and a Radeon 8060S GPU. A shared coordination file governs who gets to register GPU-heavy work and when, so the two don’t block each other.

The two assistants load this machine completely differently, though:

• Hermes runs entirely over Claude’s cloud API. There’s no locally loaded model, and therefore no fixed RAM or GPU footprint for one – just the ordinary memory footprint of the agent process itself, the kind every program has.
• OpenClaw additionally keeps a local model on standby: “Strata,” technically Qwen 3.8 Flash Next (qwen3.8-flash-next-unsloth-ud-iq4_xs), loaded via a llama-server process with a 262,144-token context window and only one inference slot – meaning it can only handle one request at a time, not several in parallel like the cloud models. On top of that come two more of its own processes: ComfyUI (via ROCm on the GPU, for images and LoRA training) and a CPU-based TTS system for voice output. That’s exactly why the shared coordination file is needed – OpenClaw simply has more local processes that could compete with each other and with Hermes for RAM and GPU; Hermes doesn’t have that problem.

In practice, almost everything still runs through the cloud, not locally. In the OpenClaw team’s evaluation period (10/25 to 11/03, 1,281 completed runs), 97% of runs went through Claude in the cloud and only 39 ran locally via Strata – with a 28.2% failure rate, noticeably higher than the cloud models’ 2 to 4%. According to its own records, Hermes doesn’t use the local hardware at all in this period: zero GPU or Strata runs, exclusively cloud requests.

Hermes doesn’t use local hardware at all in this period (0 runs). OpenClaw rarely uses it (39 of 1,281 runs, about 3%) – and when it does, with a 28.2% failure rate, noticeably higher than its own cloud runs (2 to 4%).

Why is that? According to the OpenClaw team’s report, the local model mainly fails on long contexts (170,000-token prompts can take up to 230 seconds just to start responding, cold) and on complex tool orchestration as a coordinator. What does work locally: clearly scoped individual tasks following a fixed checklist, like deploys, fixes, or measurements. The real bottleneck, then, isn’t compute – it’s the cloud models’ subscription limit. On at least one day, the 5-hour quota sat at exactly 100% for six hourly checks in a row.

A current look at the running processes (morning of 11/06) shows the difference concretely: my Hermes agent runs across about 29 processes (session infrastructure plus gateway/CLI) using roughly 1.1 GB of RAM combined – none of it a loaded language model. OpenClaw’s gateway process alone needs about 5.1 GB of RAM across roughly 28 processes. The local model Strata runs as a single, separate process using 5.7 GB of RAM, and ComfyUI adds another process at 1.3 GB. Added up, the OpenClaw side claims about 12 GB of RAM just for its own processes, Hermes about a tenth of that.

Overall, at the time of measurement, 86 of 107 GB of RAM were in use, only 16 GB free – and the 8 GB swap space was completely full except for 2.5 MB. That’s noticeably tight for a machine supposedly idling. But it also shows: these roughly 12 GB from the two AI processes aren’t the main load – plenty else runs in parallel on the system (browser, monitoring, database containers for ketovavaria.de). Hardware usage is the exception rather than the rule for both assistants – the daily bottleneck is the cloud quota, not the local machine.

24 hours, from real per-process Prometheus measurements: Hermes stays almost constantly at 1 to 2 GB of RAM and mostly 23 to 24 processes – with brief spikes up to 38, always when I start a work session. OpenClaw’s gateway runs as a single, permanent process holding steady at 4 to 6 GB RAM, around the clock. Strata, OpenClaw’s local model, fluctuates between 5 and 9 GB during the day, drops to 0 GB overnight (the model appears to get unloaded), and briefly spikes to over 20 GB at times. ComfyUI, also part of OpenClaw, only shows up in short spikes of 2 to 7 GB – it clearly only runs when an actual image or LoRA training job is underway, not continuously like Strata or the gateway.

I can’t say for certain from the measurements alone what exactly triggered the Strata spike around 5 AM – a larger local run or a model reload with a bigger context are both possible. What’s clear is the fundamental difference in behavior: Hermes starts and stops processes on demand, OpenClaw keeps its gateway and model permanently ready – and the baseline load the two leave on the shared machine differs accordingly.

My Conclusion

Hermes is the better conversation partner when it comes to a fast reaction. In the channel, though, it often only delivers an acknowledgment, and I have to follow up to find out what came of it.

OpenClaw is the more reliable source of results in the channel. Almost every reply comes with evidence, and filler didn’t show up at all in this analysis. In exchange, requests get lost, and two of them mattered.

I want the same thing from both:

• A promise only when a follow-up actually comes.
• One message instead of three.
• Visible handling of the budget.
• Fewer follow-up questions directed at me. As I wrote on 11/03: “In principle, you two should sort it out yourselves.”

The next steps are obvious. Hermes should connect to Discord natively, so it’s no longer a bot without access to the work actually speaking in the channel. Whether that really resolves the open promises will only show up in the next evaluation. OpenClaw needs budget discipline: the automations and specialists need to run within the budget I can actually afford.

The most important takeaway for me: response time alone doesn’t say much. An answer after 23 seconds only helps me if something is actually finished at the end of it.