Profiles

A profile is a separate Hermes home directory with its own config.yaml, .env, SOUL.md, memory, sessions, skills, cron jobs, and gateway state. Profiles let me run several independent agents on one machine without mixing their state: a local coding assistant, a private personal bot, a research agent, each with its own personality and even its own model.

Quick start

hermes profile create coder    # creates the profile + a "coder" command
coder setup                    # configure its model and keys
coder chat                     # start chatting

Creating a profile automatically gives you a command alias. coder is now its own command: coder chat, coder gateway start, coder skills list, and so on. Under the hood it is just hermes -p coder.

Creating profiles

hermes profile create mybot              # blank profile, bundled skills seeded
hermes profile create work --clone       # copy current config, .env, SOUL, skills (fresh memory/sessions)
hermes profile create backup --clone-all # copy everything including memory + cron
hermes profile create work --clone-from coder   # clone from a specific profile

--clone is what I reach for most: same model and capabilities, but a clean memory and session history.

Targeting a profile

coder chat                  # via the alias
hermes -p coder chat        # explicit flag (works in any position)
hermes profile use coder    # sticky default for plain `hermes` commands
hermes profile use default  # switch back

The CLI always shows which profile is active (the prompt becomes coder ❯ and the banner shows Profile: coder).

A common offline use: one model per profile

Because each profile has its own config.yaml, you can point profiles at different local models, for example a small fast model for chat and a bigger coding model for dev work:

coder config set model.default qwen3.5-coder
coder config set model.base_url http://localhost:11434/v1

Profiles are not a sandbox

Important boundary to understand: a profile isolates Hermes state, not filesystem access. On the default local backend the agent still has your full user permissions. If you want a profile to start in a specific folder, set its working directory explicitly:

# in that profile's config.yaml
terminal:
  backend: local
  cwd: /absolute/path/to/project

For real isolation, use a container backend (Docker/Daytona) or the security model.

Running multiple gateways

Each profile runs its own gateway as a separate process with its own bot token:

coder gateway start
assistant gateway start         # independent process
coder gateway install           # install as a systemd/launchd service

Configure a different Telegram/Discord token in each profile's .env. If two profiles accidentally share a bot token, the second gateway is blocked with a clear error.

Managing profiles

hermes profile list            # all profiles with status
hermes profile show coder      # detail for one
hermes profile rename coder dev-bot
hermes profile export coder    # → coder.tar.gz (full backup incl. history)
hermes profile import coder.tar.gz
hermes profile delete coder    # stops gateway, removes alias + data

You cannot delete the default profile (~/.hermes); use hermes uninstall for that.

Tab completion

Enable completion for profile names and subcommands by adding eval "$(hermes completion zsh)" (or bash) to your shell rc file.

How it works

Profiles set HERMES_HOME to ~/.hermes/profiles/<name>. Hermes resolves all of its state from that directory. On host installs, the agent keeps your real OS HOME by default so tools like git, ssh, and gh find their usual credentials. If you need fully separate CLI identities per profile, set terminal.home_mode: profile.

You can also package a profile as a git repo and install it elsewhere with hermes profile install github.com/you/research-bot (SOUL, config, skills, and cron travel; credentials and memory stay per-machine).