How xHermes works

Overview

xHermes runs Hermes, an autonomous agent from Nous Research, as a managed service. When you sign in, we provision one Hermes for you, in its own container, and you talk to it through a branded dashboard and console.

You don't set up a server. You don't mind a queue. You don't patch a runtime. You arrive, your agent is there, and it stays there.

Getting started

Two onboarding paths, the same outcome. Pick whichever you already have.

@xHermesBot I need an agent

A third path exists for users who hold xHERMESbut prefer to lock instead of hold: see "Staking & tiers" below.

Either way, you land on the same dashboard with the same agent underneath. Switching paths later is fine — the agent stays yours.

Your agent

Hermes is not a chat box. It's a full autonomous agent with real tools and a deep skill library. From the dashboard you open its console and put it to work on multi-step tasks.

Hermes is a project of Nous Research. xHermes is the managed provisioning layer; the agent itself is open and documented.

Personality (SOUL.md)

Your agent's personality lives in one editable file called SOUL.md. It's plain Markdown: a voice, a few rules, things it cares about. You can edit it any time from the dashboard, and the agent reflects the change immediately.

We also offer a one-click suggestion that drafts a SOUL.mdfrom your X profile, so a new agent doesn't start blank. You always edit the result before saving.

Models & credit

Your agent talks to a language model through a per-agent key that we mint for you. The key carries a credit cap — a hard ceiling on what it can ever spend. If the agent runs up against it, it stops. There is no surprise bill, because there is no bill that can grow past the cap.

Inside that cap, you pick the model from the dashboard. The credit readout in your account is the live number, not a monthly estimate.

Staking & tiers

Locking xHERMES unlocks additional agent infrastructure on top of the base provisioning. The mechanism is the standard Solana lock primitive: Jupiter Lock. You commit a chosen amount for a chosen duration, the lock account lives on-chain, and xHermes reads it to gate premium features.

From the dashboard, the Stake-to-Access panel opens a modal: pick an amount and a duration (1 month, 3 months, 6 months, 1 year), confirm in your wallet, the lock is created, and the dashboard refreshes within seconds.

Exact amounts per tier are surfaced live in the dashboard. Operators can tune them, so the docs avoid hard-coding numbers.

How locks behave

• Irrevocable. Tokens unlock automatically on the chosen date. xHermes never holds custody; the lock account is yours, verifiable on Solana Explorer (the dashboard links to it).
• Warn window.The dashboard flags "expiring soon" starting 14 days before unlock.
• Grace period. After the on-chain unlock fires, the tier stays live for 7 more days. Use that window to re-lock if you want continuity.
• Tier downgrade is soft. Data is preserved when a tier flips back to locked. Snapshots stay in storage until retention prunes them; you regain access to them when you re-lock.

Snapshots & backups

Tier 1 unlocks snapshots. A snapshot is a point-in-time backup of your agent's workdir (the contents of ~/.hermes in the container). The container compresses the workdir to tar.zst, encrypts it with a per-snapshot key, and uploads the ciphertext to Cloudflare R2. The encryption key is wrapped by the xHermes key vault before being stored in the database, so reading R2 alone yields ciphertext and reading the database alone yields wrapped keys with no way to decrypt them. Both are needed for a restore.

From the dashboard:

• Create. Optional label. If left blank, the snapshot is auto-named {handle}-{YYYYMMDD-HHmm} for easy reference.
• Restore. Stops the agent, replaces the workdir from the snapshot, restarts. One restore at a time per agent; the dashboard shows progress.
• Delete. Removes the snapshot from R2 and the index.

Retention is operator-configured. A daily sweep prunes anything over the per-user cap (oldest snapshots evicted first) and anything past the retention horizon. The dashboard surfaces both values inline next to the panel header.

Region migration

Tier 2 unlocks region migration: move your agent between xHERMES regions (currently EU, USA West, Asia Pacific). Under the hood, the migration uses the snapshot pipeline: snapshot the workdir, provision a fresh container in the destination, restore the encrypted archive, deprovision the source.

The agent is unreachable for the duration (typically under a minute on a default-sized workdir). Existing snapshots are region-agnostic and remain available throughout.

Pro workdir

Free agents get a 2 GB workdir. The Pro workdir tier raises the cap to 10 GB. The cap is enforced at the filesystem layer via XFS project quotas, so writes past the limit fail with ENOSPC rather than eating into the host. Existing files survive a downgrade; new writes above the free cap are blocked until you delete or re-lock.

Current usage shows on the agent panel as used / cap with a thin progress indicator. The measurement runs every 30 minutes; the dashboard reads the cached value, so the number lags slightly behind on-disk reality.

SuperGrok + xurl

If you already pay xAI for SuperGrok, you can drop your own key onto your agent and run it on Grok 4 with no LLM cap from us — billing goes direct to your xAI account. The connection happens once on the dashboard.

With a SuperGrok key connected, your agent can also talk to X through the bundled xurlskill — post, reply, search, DM — using the official X developer CLI under the hood. Authorization lives on your agent; we don't mediate the calls.

Walkthrough: @XDevelopers + Nous Research.

CLI (npm)

The browser dashboard is one way in. If you live in a terminal, install @xhermes/cliand your agent's pty becomes a window in iTerm/Ghostty/wezterm — same Hermes, same session history, just no browser tab.

npm i -g @xhermes/cli
xhermes

First run prints a short code and opens your browser to /cli/authorize. Confirm it matches the terminal, click Authorize, and the CLI drops you into your agent. The token it stores at ~/.config/xhermes/credentials.json is long-lived but revocable — see the CLI panel on the dashboard for the list of authorized machines.

Subcommands:

• xhermes — auth-if-needed, then drop into the terminal session. The default.
• xhermes whoami — show signed-in user + agent status.
• xhermes logout— revoke this machine's token server-side and forget it locally.

Open source at github.com/xHermescloud/cli — npm publishes are Sigstore-signed; verify with npm audit signatures.

Security & isolation

Isolation is the pitch and the implementation. Here are the guarantees in plain language:

• One container per user. Your agent runs in its own container, with its own filesystem and its own memory. No shared process, no shared state, no neighbor.
• Reachable only through xHermes. The container has no public port. Every request to it passes our authenticated front door, which checks that the caller is you.
• Hibernated when idle.If you aren't using it, it stops. It comes back the moment you do. Nothing runs in the background it wasn't asked to.
• Capped LLM spend.The model key tied to your agent has a hard credit ceiling. A runaway loop can't cost more than the cap.
• Sealed secrets.Anything sensitive your agent uses (model key, integrations) is encrypted before it's stored, with the encryption key held outside the agent box. The agent box itself holds no application secrets at rest.
• No wallet custody. Wallet onboarding is a signature on a one-time message. We never see, hold, or move your tokens.

What we store

The short list. Nothing more than the service needs:

Conversation content lives inside your agent's own memory, under your account. Deleting the agent removes it with the container.

FAQ