Hermes vs Claude Code: When to Use Which
Claude Code is your IDE agent. Hermes is your server-side agent. Here is how to decide which tool fits which job, and why most teams end up using both.
The question gets asked wrong most of the time. People frame it as Hermes versus Claude Code, as if picking one means abandoning the other. That framing misses the point. Claude Code is an IDE-centric coding assistant that lives inside your terminal or editor session. Hermes is a server-side agent runtime that keeps running when you close your laptop. They are not substitutes — they are layers.
If you already use Claude Code day to day, adding Hermes does not replace it. Hermes can literally spawn Claude Code as a subagent and delegate heavy coding work to it. The real decision is which tool handles which class of task, and where the boundary sits.
Key Takeaways
- Claude Code is interactive, project-scoped, and runs in your terminal or IDE. It excels at tight-loop coding work.
- Hermes is persistent, always-on, and runs on a server. It excels at scheduled jobs, messaging integrations, and cross-session memory.
- Both use the agentskills.io open standard, so skills are largely portable between them.
- Hermes can orchestrate Claude Code via
delegate_task(), using either print mode or a tmux-backed PTY. - For most developers the correct answer is "use both" — Claude Code for hands-on work, Hermes for everything that needs to run without you.
- Hermes reads Claude Code's credential store directly, so your Claude Pro or Max OAuth session is reused without any token copying.
- Pick based on lifecycle (session vs persistent), location (local vs server), and trigger (human-driven vs event-driven).
Two Different Lifecycles
Claude Code is a session tool. You open a terminal, start a conversation, the agent has access to your project directory, and when you close the session the context mostly goes away. Each project has its own CLAUDE.md file that gets loaded at the start of a new session. That is the unit of state.
Hermes is the opposite. It runs as a long-lived Python process. It has a markdown memory directory at ~/.hermes/ that is FTS5-indexed and grows across sessions. It writes its own SKILL.md files from experience. It can be triggered by a cron schedule, a Telegram message, a webhook, or a voice command. The agent is always there.
This single difference — session versus persistent — drives almost every other distinction.
The Decision Matrix
| Use case | Better fit | Why |
|---|---|---|
| Refactor a module in your editor | Claude Code | IDE integration, tight feedback loop |
| Write a skill test suite interactively | Claude Code | File-system native, sees your project context |
| Daily 8am market summary to Telegram | Hermes | Cron + messaging gateway built in |
| Triage inbound GitHub issues overnight | Hermes | Persistent, event-driven, no human in loop |
| Pair-programming session | Claude Code | Interactive, real-time, scoped to the repo |
| Answer questions about your codebase via Slack | Hermes | Messaging integration, accumulated memory |
| One-off script in a new repo | Claude Code | Zero setup, project-scoped |
| Multi-hour research task | Hermes | Survives disconnects, can delegate to Claude Code |
| Run the same workflow across 10 projects | Hermes | Global memory and skills, not per-project |
| Quick prototype with voice | Hermes | Built-in voice mode, 20 languages |
The pattern: if the task has a human sitting in front of it right now, Claude Code wins. If the task needs to run on a schedule or react to an external event, Hermes wins.
Local vs Server
Claude Code runs where you run your code — laptop, dev box, wherever your project lives. It has no server component. When your laptop goes to sleep, Claude Code stops.
Hermes is designed for a server. The canonical install target is a $4-8/month VPS, and the install script handles systemd wiring so the runtime survives reboots:
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash
You can run Hermes locally for development, but the whole point of the runtime is that it stays up when you do not. See Installing Hermes Agent on a $5 VPS for the full walkthrough.
Project-Scoped vs Always-On
Claude Code's unit of context is the project. Its CLAUDE.md file sits in the repo root. The skills it loads come from .claude/skills/ in the project or ~/.claude/skills/ globally. The agent assumes it is working on one thing at a time.
Hermes does not have a concept of "current project." It has skills, memory, and active workflows. A single Hermes instance can be juggling a daily report skill, a Discord bot integration, and three long-running research tasks at the same time. Its config is global:
model:
provider: "anthropic"
default: "claude-sonnet-4-6"
If your work is consistently in one codebase at a time, Claude Code's model fits. If you are coordinating across multiple projects or running cross-cutting workflows, Hermes fits better.
IDE-Centric vs Messaging-Centric
Claude Code's primary interfaces are the terminal and, via ACP, editors like VS Code, Zed, and JetBrains. The interaction is you typing at a shell.
Hermes has eight messaging gateways out of the box: Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Feishu, and DingTalk. Plus voice mode in 20 languages, a cron scheduler, and ACP for editor integration. The design assumption is that you interact with the agent from wherever you happen to be — your phone, a group chat, a voice command at your desk.
This is why "which tool" becomes "where do you want to talk to the agent from." Editor-only? Claude Code. Phone, chat, voice, browser, cron? Hermes.
They Work Better Together
The bundled skill at skills/autonomous-ai-agents/claude-code/SKILL.md inside the Hermes repo teaches Hermes how to delegate to Claude Code. Two mechanisms exist: print mode via claude -p "prompt" for stateless single-shot work, and tmux-backed PTY sessions for keeping Claude Code interactive across a longer task. See Print Mode vs Tmux: Hermes Orchestrates Claude Code for the mechanics.
A typical pattern looks like this. You send Hermes a Telegram message at 9pm: "refactor the auth module in the billing-api repo, write tests, open a PR." Hermes plans the work, writes a task list to memory, then spawns Claude Code in print mode against that repo with specific sub-tasks. Claude Code does the editing. Hermes reviews the diff, runs the tests, and pings you back on Telegram when the PR is up. You handle the review in the morning from your actual editor — where Claude Code would help you again if you asked.
The same skills can work in both runtimes because both follow the agentskills.io standard. A well-formed SKILL.md is format-compatible; porting from Claude Code to Hermes usually takes only minor tag tweaks. See Are Claude Code Skills Portable to Hermes? for the compatibility audit.
A Simple Rule of Thumb
When someone asks me which to use, I give them this:
- You are sitting at your keyboard and want to move code right now. Use Claude Code.
- You want something to run while you sleep, react to an event, or remember across sessions. Use Hermes.
- Both of those are true for your workflow (they usually are). Use both, and let Hermes drive Claude Code as a subagent for the heavy coding lifts.
The interesting design choice by the Nous Research team was to make Hermes model-agnostic and Claude-Code-aware at the same time. anthropic>=0.39.0 is a core Python dependency. Hermes reads Claude Code's credential store directly so the same OAuth works. The two tools are built to cohabitate.
What This Means for Skill Authors
If you write skills, this overlap is a feature. Write to the agentskills.io standard and your SKILL.md works in both environments. Claude Code users get it in their editor. Hermes users get it on a server, on a schedule, in a messaging gateway, in voice. One file, two runtimes, twice the surface area.
If you are already publishing skills on the aiskill.market marketplace, they are Hermes-compatible out of the box (barring the occasional tag tweak). That portability is why this comparison ends up not being a comparison at all.