Hermes Agent Setup Guide: Why I Switched from OpenClaw

Have you ever built your whole workflow around one tool, told everyone about it, and then quietly realized you had already moved on to something better? That is exactly where I found myself a few weeks ago. If you are an AI-curious professional, a builder, a consultant, a business owner, a creator, or a current OpenClaw user, this Hermes Agent setup guide is written for you, and by the end of it you will have Hermes installed, a provider and model configured, a verified first chat working, and a clear map of the Dashboard, profiles, and the advanced /goal, cron, and multi-profile workflows that make Hermes worth your time. No fluff, no product war, just the exact setup I now recommend.

Here is the honest truth up front: I have switched all of my personal AI agents to the Hermes platform, and I no longer personally use OpenClaw. That is a big statement coming from someone who wrote my original OpenClaw Mac Mini setup guide and genuinely loved that machine. But things change, and when the evidence in front of me changed, my setup changed with it. Let me show you what I run now, why I moved, and how you can get a working Hermes agent going today.

Why I Moved My Agents to Hermes

I want to be careful here, because this is my experience and my opinion, not a universal verdict. For my workflow, Hermes has simply been more reliable. Its updates have been less disruptive when I pull them in. Its roadmap and product direction feel clearer to me, so I can plan around where the tool is going. It makes new models available quickly, which matters a lot to someone who likes to test the latest brain the day it lands. And its core operation has just been more consistent for the way I work day to day.

Those are the reasons for me. Your mileage may differ, and if OpenClaw is serving you well, there is nothing wrong with staying. I am not here to tell you that everyone must switch. I am here to teach you the setup I actually use.

Here is what most people miss: a model and an agent platform are not the same thing. If that distinction is fuzzy for you, my piece on why the brain and the agent environment are different layers is worth a read. Hermes is the environment. The model is the brain you plug into it. Getting both right is what this guide is about.

My Model Recommendation Has a Timeline

If you have followed my blog, you know I do not pretend my recommendations are permanent. Back when I ran the GPT-5.4 experiment that sent me straight back to Claude, I regretted the swap and returned to Opus. Then I wrote about upgrading my AI employee to Opus 4.6 in about thirty minutes and recommended it warmly.

Both of those posts were true at the time. They reflected the models and the results I had in front of me then. I am not dismissing that older experience, and I would not rewrite it. Technology moves, and honest recommendations should move with it.

What changed is that GPT-5.6 Sol is a genuinely different model from GPT-5.4, and my current hands-on judgment has evolved. Those older posts were accurate when I wrote them. This one is accurate now. So let me tell you exactly why my main brain changed, and why I am no longer hedging about it.

Why GPT-5.6 Sol Replaced Opus as My Main Brain

Here is where I stop softening the point. GPT-5.6 Sol is the main brain I now use and recommend for Hermes Agent, plainly and without an asterisk on the decision itself. If you still run OpenClaw, Sol is also my main-brain recommendation there. And for every criterion that actually matters to how I operate my agents today, Opus is no longer my pick.

I want to be precise about what “matters to how I operate” means, because I am not making a universal claim and I am not quoting a benchmark. This is my current hands-on judgment for my own workflow. It is a practitioner recommendation, not official Hermes documentation, and not a leaderboard result. Hermes lets you select and configure models, but it does not tell everyone that Sol is best for them, and I am not going to pretend it does. With that boundary stated honestly, I am also not going to retreat into vague neutrality. I made a call, and here is the reasoning behind it.

Look at that table honestly. Five of the six criteria that drive my daily agent work land on Sol, and the one that lands on Opus is the one that matters least for the jobs I actually hand to my agents.

The economics row is the one people ask about most. When I run Sol through a ChatGPT and Codex subscription, that access covers my model usage instead of accruing a separate usage-based Opus API bill on the side. For the way I operate my agents, that is materially more economical, and it is a real part of why the switch stuck. I am not going to quote you a dollar figure or a usage number, because your plan, your access, and your workload are not mine. What I can say plainly is that trading a metered API bill for subscription-covered access moved the value math firmly into Sol’s favor for me.

I also will not pretend Opus has no edge. In pure conversation, Opus can feel warmer, and it often lands on a decision with more confidence and personality. If what you mostly want is a model that talks like a thoughtful colleague, that is a genuine point in its favor. But my agents are not there to make conversation. They are there to carry out multi-step work at medium reasoning, use the computer, follow instructions carefully, and finish the job. On exactly those tasks, Sol’s practical advantages win for me, and the warmth gap does not come close to outweighing them. That is why Opus moved off my main-brain slot and Sol took it.

One more time, so there is no confusion: this is my current choice for my workload, not a claim that Sol beats Opus for everyone, wins any official benchmark, saves a specific amount, or is officially recommended by Hermes. Test it against your own work. My recommendation is strong, but it is still a recommendation you should verify in your own setup.

The Registered GPT-5.6 Family: Sol, Terra, and Luna

Here is what actually matters about the GPT-5.6 family on the platform. The current Hermes source registers all six IDs, including their high-effort -pro variants, and the OpenAI Codex catalog carries them. The public provider prose does not yet enumerate these GPT-5.6 variants, so I am attributing their registration to the verified current Hermes source in my research bundle, not to the published provider page.

I want to be straight about what I can and cannot claim. The supplied public provider prose does not publish comparative positioning for these three, so I am not going to invent speed, quality, price, tier, or workload rankings for Terra or Luna. I simply do not have documented evidence for those comparisons, and I will not fabricate them. Sol is the one I have made my case for above. Terra and Luna are there if you want to try them; I just cannot rank them for you from published facts.

The Hermes Agent setup guide: Fastest Path to a Working Agent

Let me give you the shortest route first. This is the fastest path, and it is no more than eight actions. Every command below is copyable, and I define each placeholder right after it.

1. Install Hermes with the official one-line installer.
2. Run hermes setup --portal for the Portal-backed setup.
3. Run hermes model if you want to add OpenAI Codex and pick a Sol variant.
4. Start a chat by typing hermes.
5. Send a first message to confirm the agent responds.
6. Run hermes doctor to verify your install.
7. Install the Dashboard extras and run hermes dashboard.
8. Open http://127.0.0.1:9119 and explore.

That is it. The rest of this Hermes Agent setup guide unpacks each step so you understand what you are doing, not just what to type.

Choose Your Path

Different readers want different things. Pick the row that fits you.

Installing Hermes

Hermes installs with a single command that works on Linux, macOS, WSL2, and Android or Termux. The documentation home page lists it directly (Hermes docs home).

curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash

Once the CLI is on your machine, the fastest way to a working agent is the Portal-backed setup. The docs call this the fastest path to a working agent, because one sign-in covers a model plus the four Tool Gateway tools (Hermes docs home).

hermes setup --portal

The --portal flag runs the Portal onboarding flow. If you only ever run this one command, you will already have a usable agent. That is genuinely most of the work.

Setting Up OpenAI Codex and Choosing Sol

If you want to run Sol through OpenAI Codex, the setup runs outside an active chat. The AI Providers page documents the OpenAI Codex provider as ChatGPT sign-in that uses Codex models (Hermes providers docs).

hermes model

Choose OpenAI Codex from the wizard and complete the device-code login, where you open a URL and enter a short code. Per the providers page, no Codex CLI installation is required, and Hermes can import existing Codex sign-in details if you already have them (Hermes providers docs). If you ever need to re-authenticate, the providers page documents an explicit command.

hermes auth add codex-oauth

hermes model Versus /model

This trips people up, so pay attention. These two are not the same thing.

• hermes model is the full terminal setup wizard. It adds providers, runs sign-in flows, accepts keys, configures endpoints, and sets your default. Run it in a shell (CLI reference).
• /model is an in-session switcher. It only swaps among providers and models you have already configured. It cannot add a new provider or run a sign-in flow (slash commands reference).

Think of it this way: hermes model is how you set up the garage. /model is how you pick which car to drive once the cars are already parked inside.

Reasoning Effort: Start at Medium

Hermes lets you tune how hard the model thinks. The official configuration docs say that when reasoning effort is unset, it defaults to medium, a balanced level that works well for most tasks (reasoning effort docs).

I recommend you start exactly there. Medium is my recommended starting point precisely because it is the documented balanced default, and it is also the level where Sol follows my instructions closely without me reaching for higher effort.

/reasoning medium

If you want faster, lighter runs, low is a reasonable speed and usage option in my experience. I am not going to attach numbers, costs, or benchmark claims to that, because I do not have documented figures to give you. It is simply a sensible lever when you want the agent to move quickly.

One thing to keep separate in your head: reasoning effort and the -pro model suffix are two different controls. Reasoning effort is a setting you change with /reasoning. The -pro suffix is a different model ID. Do not conflate the two.

The related runtime commands are handy to know.

/reasoning          # show current effort
/reasoning show     # display model thinking
/reasoning hide     # hide model thinking
/reasoning none     # disable reasoning

Your First Verified Chat

Installing something is not the same as knowing it works, so let me treat verification as part of setup, not an afterthought.

Start a chat.

hermes

Then send a simple message such as asking it to introduce itself and confirm which model it is running. When you get a coherent reply, your provider and model are wired correctly. That is your verified first chat.

Now run the built-in health check to confirm the rest of your install.

hermes doctor

If hermes doctor reports a clean bill of health and your chat replied, you have a working agent. Everything after this point is about doing more with that foundation, not fixing it.

The Hermes Dashboard, Start to Finish

The command line is great, but sometimes you want to see everything in a browser. The Web Dashboard is a browser-based interface for managing your Hermes installation, so instead of editing configuration files or running commands, you configure settings, manage keys, and monitor sessions from a clean interface (Web Dashboard docs).

Install the Dashboard Extras

The default install may not include the optional HTTP and PTY pieces the Dashboard needs. Install them with the web extras (Web Dashboard docs).

cd ~/.hermes/hermes-agent && uv pip install -e ".[web,pty]"

If you would rather grab everything at once, the all-extras option is simpler.

cd ~/.hermes/hermes-agent && uv pip install -e ".[all]"

Launch It

hermes dashboard

This starts the local server and opens your browser to the Dashboard address (Web Dashboard docs).

http://127.0.0.1:9119

There are a few launch controls worth memorizing, all confirmed in the Dashboard docs (Web Dashboard docs).

hermes dashboard --port 8080   # run on a different port
hermes dashboard --no-open     # start without opening a browser
hermes dashboard --status      # check whether it is running
hermes dashboard --stop        # stop the server

What You Will Actually See

When the Dashboard opens, the current landing route is Sessions. There is no standalone Status page in the current build, so do not go looking for one. Sessions is where you land.

Here are the pages that earn their keep:

• Sessions: browse and search past conversations, inspect message and tool history, rename, export, prune, and resume in Chat.
• Files: browse directories, upload and download, create folders, and navigate a managed path.
• Analytics: usage, cache hit rates, cost, and session breakdowns over 7, 30, or 90 days.
• Models: model selection plus the auxiliary-task assignments Hermes uses behind the scenes.
• Logs: agent, gateway, and error logs with filters and auto-refresh.
• Cron: create, edit, pause, resume, trigger, and delete scheduled jobs.
• Skills: search, toggle, and install skills and toolsets.
• Plugins: plugin management and memory-provider setup.
• MCP: add, test, enable, disable, and remove MCP servers.
• Channels: configure and test supported messaging adapters.
• Webhooks and Pairing: manage subscriptions and approve messaging users.
• Profiles: create and manage profiles and their models, descriptions, and skills.
• Config and Keys: edit configuration fields and manage entries by category.
• System: host and runtime information, gateway controls, and maintenance operations.
• Documentation: the official docs embedded right inside the Dashboard.
• Kanban: a bundled plugin tab for the durable task board, when installed.

One more thing worth knowing: the Dashboard is a machine-level management surface, meaning one server can manage every profile on your machine, with a sidebar switcher that scopes Config, Keys, Skills, MCP, Models, and Chat to the profile you select (Web Dashboard docs).

The /goal Deep Dive

If you learn only one advanced feature from this guide, make it /goal. This is the piece that turns Hermes from a chat tool into something that keeps working when you look away.

What a Standing Goal Actually Is

A one-off prompt runs as a normal turn and ends when the assistant returns its final answer. A standing goal is different. It gives Hermes an objective that survives across turns. After every turn, a lightweight judge model checks whether the goal is satisfied by the assistant’s last response. If it is not, Hermes feeds a continuation prompt back into the same session and keeps working (Goals docs).

The loop ends when the judge marks the goal achieved, you pause or clear it, the turn budget runs out, or the work is judged blocked. That is the whole idea: you stop having to type “keep going” over and over.

The Core Commands

/goal <text>       # set or replace the standing goal, first turn starts now
/goal              # show the current goal and status
/goal status       # show status plus turns used
/goal pause        # stop auto-continuation without deleting the goal
/goal resume       # resume and reset the continuation counter to zero
/goal clear        # delete the goal
/goal show         # show the completion contract

The dedicated page also documents a few more that are easy to overlook (Goals docs).

/goal draft <text>          # draft a structured completion contract
/goal wait <pid> [reason]   # park until a background process exits
/goal unwait                # clear the wait barrier
/subgoal <text>             # add an acceptance criterion mid-loop
/subgoal remove <N>         # remove one subgoal by number
/subgoal clear              # remove all subgoals

The 20-Turn Budget and Persistence

Here is the part that keeps you in control. The default continuation budget is 20 turns. When that budget is exhausted, the goal auto-pauses rather than running forever (Goals docs).

Goal state is persisted in the session, so it survives /resume. That means you can close your session, come back later, resume, and the goal is still there waiting. And /goal resume resets the continuation counter to zero, giving the objective a fresh budget. That reset is deliberate, so remember it: resume does not simply pick up the old count, it starts the budget over.

Any real message you type preempts the generated continuation, and then the judge evaluates again after your turn. So you are never locked out; you can jump in anytime.

Completion Contracts in Plain English

A completion contract is just you telling the agent, in structured terms, what “done” actually means. Instead of hoping the judge guesses correctly, you spell out the outcome, how to verify it, what constraints to respect, what boundaries not to cross, and when to stop. The judge should mark the goal done only when the verification criterion is backed by concrete evidence (Goals docs).

You can build one with /goal draft <text>, review it anytime with /goal show, and tighten it during the loop by adding subgoals as acceptance criteria. Here is a realistic example.

/goal Migrate the auth module to JWT
verify: pytest tests/auth passes with zero failures
constraints: keep the /login response shape unchanged
boundaries: only touch services/auth and its tests
stop when: a database schema migration would be required

And here is a second one for a content task.

/goal Draft and refine a 1500-word article on our new pricing
verify: the draft covers all three tiers and reads cleanly end to end
constraints: use our existing brand voice, no invented statistics
boundaries: write only to drafts/pricing-article.md
stop when: the outline lacks approved source material to continue

Notice the shape of both: outcome, verification, constraints, boundaries, and a stop condition. That structure is what keeps a standing goal productive instead of wandering. If mid-run you realize you forgot a criterion, add it with /subgoal Confirm the FAQ section answers the top objection and remove it later with /subgoal remove 1 if it no longer applies.

Choosing the Right Tool for the Job

Hermes gives you several ways to run work, and picking the wrong one wastes time. This table lays out the differences so you can choose intentionally.

A few specifics worth stating plainly. /background <prompt> spawns a completely separate agent session, and that session has no knowledge of your current conversation. It receives only the prompt you give it, so you must include every piece of context it needs right in that prompt (slash commands reference).

/background Analyze today's server logs and summarize the errors
/queue After this finishes, write a short summary of what changed
/steer Focus on the auth module, not the UI

/queue creates the next normal user turn without interrupting the current response. /steer injects a note after the next tool call, without creating a new turn at all. They are not interchangeable, and now you know exactly why.

Cron is its own animal. It is time-triggered, runs a fresh session through the gateway for each job, and therefore needs self-contained prompts because it carries no chat context (Cron docs). Kanban, by contrast, is a durable work queue and state machine shared across your profiles, where tasks are claimed by named workers (Kanban docs). /goal sits in the middle: a persisted objective inside one resumable session.

Profiles and Multi-Profile Operation

This is where Hermes really started to click for me. A profile is a separate Hermes home directory, with its own configuration, model choices, sessions, memories, skills, cron jobs, and gateway state (Profiles docs). Think of each profile as a distinct employee with its own desk, its own brain, and its own memory.

Create, Describe, and Use

hermes profile create researcher --description "Reads sources and writes evidence-grounded findings"

Creating a profile automatically makes a command alias, so researcher becomes shorthand for hermes -p researcher. Give every role a meaningful description, because that description is what routing uses to pick the right worker later (Profiles docs).

researcher setup
researcher chat

You can describe a profile after the fact, too.

hermes profile describe researcher --text "Research and source verification specialist"
hermes profile describe researcher --auto

Target a profile explicitly when you want to be precise, or set a sticky default.

hermes -p researcher chat        # explicit targeting
hermes profile use researcher    # sticky default
hermes chat                      # now runs as researcher
hermes profile use default       # switch back

Gateways and Channels

Each profile can run its own gateway process, which you will want when a profile needs to handle scheduled jobs or messaging on its own (multi-profile gateways docs).

researcher gateway install
researcher gateway start

Route each messaging channel intentionally to the right profile gateway so your research bot and your writing bot do not step on each other (Web Dashboard docs). And in the Dashboard, the sidebar profile switcher lets you jump between profiles without touching the command line at all.

Cron Hygiene Across Profiles

A little discipline here saves you real headaches. Keep every cron prompt self-contained, because each job runs in a fresh session with no chat memory (Cron docs). Attach the right skill or working directory when a job needs specific context. And review or pause stale jobs before they pile up and run work you no longer want.

hermes cron list
hermes cron pause <job_id_or_name>

A Practical First Weekend

If you want a concrete sequence, here is roughly how I would spend the first couple of sessions. On day one, install Hermes, run the Portal setup, add Sol through hermes model, and get one clean verified chat working. Do not add anything else until that base is solid.

On day two, install the Dashboard extras, launch it, and click through Sessions, Models, and Analytics so you know where things live. Then create your first specialized profile for one real job you actually have, describe it well, and give it a single /goal with a clear completion contract. Watch it run, pause it, resume it, and get a feel for how the judge behaves.

Once that feels natural, extend Hermes with skills. I built a video-watching skill for my agent because reading transcripts was not enough for some of my work, and adding skills is how you shape an agent around your real tasks. If you want inspiration for what to automate, the seven business workflows I set up to run while I sleep are transferable patterns you can rebuild inside Hermes profiles and cron jobs, not something tied to any one platform.

That progression, one clean chat, then the Dashboard, then a profile with a goal, then skills and automation, is the whole map. Build one layer at a time and each layer stays reliable.

Your Turn To Share

I have told you what I run, why I moved, and exactly how to set it up, so now I want to hear from you: what does your current agent setup look like today, and if you spun up Hermes this week, what is the first workflow or /goal you would hand it to prove it earns a place in your stack?