Hermes Agent : la référence du praticien (2026)

TL;DR : Hermes Agent est un agent IA open source auto-améliorant développé par Nous Research. Il fonctionne comme un CLI et comme passerelle de messagerie multi-plateforme, stocke une identité durable et une mémoire persistante sur disque, agrège des skills qui s’améliorent avec l’usage, et fonctionne avec n’importe quel fournisseur LLM compatible OpenAI — Nous Portal, OpenRouter, Anthropic, GitHub Copilot, z.ai, Kimi, MiniMax, DeepSeek, Alibaba, Hugging Face, Google, ou votre propre endpoint auto-hébergé.[^1][^2] Le plus difficile pour la plupart des nouveaux utilisateurs est l’authentification du fournisseur : Hermes prend en charge environ 19 fournisseurs de premier ordre ainsi que des endpoints personnalisés, et trois chemins d’authentification distincts (clé API dans .env, OAuth via hermes model, ou endpoint personnalisé dans config.yaml). Le modèle d’authentification est la première chose à apprendre — tout le reste découle du fournisseur qui est résolu.

Hermes Agent fonctionne comme un véritable runtime d’agent, pas comme un wrapper de chat. Il lit votre système de fichiers, exécute des commandes dans des backends en sandbox, scrape le web, génère des sous-agents, exécute des tâches cron planifiées, communique avec Telegram/Discord/Slack/WhatsApp/Signal/Email depuis un unique processus de passerelle, et crée ses propres skills à partir de l’expérience.[^1] Le CLI est une interface terminal construite par-dessus une boucle de conversation dans run_agent.py ; la gateway est un processus de longue durée qui route les messages depuis les plateformes de messagerie à travers la même boucle de conversation.[^3]

La différence entre un usage occasionnel et un usage expert de Hermes se résume à cinq systèmes. Maîtrisez-les et Hermes devient un multiplicateur de force :

1. Résolution du fournisseur : comment les flux d’authentification se mappent aux appels API
2. Hiérarchie de configuration : config.yaml + .env + auth.json + SOUL.md + AGENTS.md
3. Système d’outils + toolset : ce que l’agent peut faire, contrôlé par plateforme
4. Système de skills : mémoire procédurale que l’agent crée et fait évoluer
5. Gateway + cron + profiles : faire fonctionner Hermes là où vous vivez, pas seulement là où vous êtes

Points clés à retenir

• L’authentification du fournisseur passe par trois chemins, pas un seul. Clé API dans .env, OAuth via hermes model/hermes auth, ou endpoint personnalisé dans config.yaml. Choisissez le chemin qui correspond à votre fournisseur, pas celui qui vous semble familier.
• Changer de fournisseur se fait en une seule commande. hermes model vous guide de manière interactive à travers chaque fournisseur pris en charge, y compris les connexions OAuth, et /model provider:model permet de basculer en cours de session sans perdre l’historique.[^2]
• Deux fichiers constituent la surface de configuration éditable par l’utilisateur. ~/.hermes/config.yaml contient les paramètres et ~/.hermes/.env contient les secrets. auth.json, SOUL.md, MEMORY.md et skills/ sont gérés directement par Hermes — vous pouvez éditer SOUL.md à la main, mais le reste est manipulé par l’agent lui-même.[^4]
• Hermes est le successeur d’OpenClaw. Si vous migrez, hermes claw migrate importe automatiquement plus de 30 catégories d’état.[^5]
• La qualité de service dépend de votre modèle auxiliaire. Vision, résumé web, compression et flush mémoire utilisent tous un LLM auxiliaire séparé. Par défaut, il s’agit de Gemini Flash via détection automatique (OpenRouter → Nous → Codex) — si aucun de ces fournisseurs n’est configuré, ces fonctionnalités se dégradent silencieusement jusqu’à ce que vous pointiez les emplacements auxiliaires vers votre fournisseur principal.[^4]

Chaque section ci-dessous s’appuie sur la documentation upstream à hermes-agent.nousresearch.com/docs et l’arborescence source à github.com/NousResearch/hermes-agent. Chaque affirmation factuelle est accompagnée d’une note de bas de page pointant vers la page upstream spécifique dont elle provient.

Choisissez votre parcours

Comment fonctionne Hermes : le modèle mental

Hermes s’articule autour d’une boucle de conversation unique que tout point d’entrée peut invoquer. Ces points d’entrée sont le CLI (cli.py), la gateway de messagerie (gateway/run.py), l’adaptateur ACP pour l’intégration aux éditeurs, le batch runner et un serveur API.[^3] Tous finissent par appeler AIAgent.run_conversation() dans run_agent.py, qui :

1. Construit le prompt système à partir de SOUL.md, MEMORY.md, USER.md, des skills, des fichiers de contexte et des directives d’outils via prompt_builder.py[^3]
2. Résout le fournisseur d’exécution via runtime_provider.py — c’est l’étape qui détermine votre authentification, l’URL de base et le mode API[^3]
3. Appelle le fournisseur en utilisant l’un des trois modes API : chat_completions, codex_responses ou anthropic_messages[^3]
4. Distribue les appels d’outils retournés via model_tools.py et le registre central d’outils (tools/registry.py)[^3]
5. Boucle jusqu’à ce que le modèle produise une réponse finale, puis persiste la session dans SQLite avec FTS5[^3]

Comprendre cette boucle est essentiel, car chaque fonctionnalité — personnalités, mémoire, skills, compression, fallback — se rattache à l’une de ces étapes. Lorsque vous examinez une clé de configuration en vous demandant ce qu’elle fait, la réponse est généralement « c’est un réglage de l’étape 1, 2, 3 ou 4 de la boucle ci-dessus ».

Cœur indépendant de la plateforme. Une seule classe AIAgent dessert le CLI, la gateway, l’ACP, le batch et le serveur API. Les différences entre plateformes résident dans le point d’entrée, pas dans l’agent lui-même.[^3] C’est pourquoi les mêmes commandes slash fonctionnent dans le terminal et dans Telegram — elles sont distribuées depuis un COMMAND_REGISTRY partagé dans hermes_cli/commands.py.[^7]

La structure de répertoires, c’est le système. Hermes stocke tout sous ~/.hermes/ (ou $HERMES_HOME pour les profils non par défaut) :[^4]

~/.hermes/
├── config.yaml        # Settings (model, terminal, TTS, compression, etc.)
├── .env               # API keys and secrets
├── auth.json          # OAuth provider credentials (Nous Portal, Codex, Anthropic)
├── SOUL.md            # Primary agent identity (slot #1 in system prompt)
├── memories/          # Persistent memory (MEMORY.md, USER.md)
├── skills/            # Bundled + agent-created + hub-installed skills
├── cron/              # Scheduled jobs
├── sessions/          # Gateway session state
└── logs/              # agent.log, gateway.log, errors.log (secrets auto-redacted)

Chaque fichier ci-dessus a un rôle précis ; aucun ne fait double emploi. Si vous cherchez « où Hermes stocke-t-il X », c’est dans l’un de ceux-ci.

Installation

L’installateur en une ligne convient à 95 % des utilisateurs. Il gère Python, uv, Node.js, ripgrep, ffmpeg, le clonage du dépôt, l’environnement virtuel et la commande globale hermes.[^8]

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Fonctionne sous Linux, macOS, WSL2 et Android/Termux (l’installateur détecte automatiquement Termux et bascule vers un bundle Android testé).[^8] Windows natif n’est pas pris en charge — installez WSL2 et exécutez la commande ci-dessus depuis celui-ci.[^8]

Une fois l’installation terminée :

source ~/.bashrc    # or ~/.zshrc
hermes              # Start chatting

Le seul prérequis est git. L’installateur provisionne automatiquement Python 3.11 via uv (sans sudo), Node.js v22 (pour l’automatisation du navigateur et le bridge WhatsApp), ripgrep et ffmpeg.[^8]

Vérifier l’installation

hermes version      # Check version
hermes doctor       # Diagnose config/dependency issues
hermes status       # Show current configuration + auth state
hermes dump         # Copy-pasteable setup summary for debugging

hermes doctor vous indique précisément ce qui manque et comment y remédier.[^8] hermes dump est la commande de diagnostic à coller dans une issue GitHub ou un fil Discord lorsque vous demandez de l’aide — c’est un résumé en texte brut de toute votre configuration, avec les secrets masqués.[^9]

Installation manuelle

Si vous avez besoin d’un contrôle total — version Python spécifique, extras particuliers, intégration Nix/NixOS — la procédure manuelle est documentée étape par étape dans le guide d’installation upstream.[^8] Principaux extras optionnels à combiner avec uv pip install -e ".[<extras>]" :

La commande d’installation Termux est différente — elle utilise pip avec un fichier de contraintes, pas uv pip :

python -m pip install -e ".[termux]" -c constraints-termux.txt

En effet, .[all] sur Android importe faster-whisper via l’extra voice, qui dépend de wheels ctranslate2 non publiées pour Android.[^8]

Authentification et fournisseurs

Hermes prend en charge environ 19 fournisseurs de premier ordre ainsi que des points de terminaison personnalisés, et trois chemins d’authentification distincts. Voici l’ensemble de la surface d’authentification, organisée par chemin afin que vous puissiez trouver celui qui correspond à ce dont vous disposez.

Les trois chemins d’authentification

Chaque fournisseur dans Hermes correspond à l’un de ces trois schémas d’authentification :

Chemin 1 — Clé API dans .env. Placez votre clé dans ~/.hermes/.env et Hermes la lit au démarrage. Utilisé par OpenRouter, AI Gateway, z.ai/GLM, Kimi/Moonshot, MiniMax (et MiniMax China), Alibaba Cloud/DashScope, Kilo Code, OpenCode Zen, OpenCode Go, DeepSeek, Hugging Face, Google/Gemini, et la plupart des fournisseurs tiers.[^2]

Chemin 2 — OAuth via hermes model ou hermes auth. Lance un flux de code d’appareil, ouvre un navigateur, stocke les identifiants dans ~/.hermes/auth.json (et peut importer des identifiants existants depuis des outils comme Claude Code ou Codex CLI). Utilisé par Nous Portal, OpenAI Codex (compte ChatGPT), GitHub Copilot et Anthropic (Claude Pro/Max).[^2]

Chemin 3 — Point de terminaison personnalisé dans config.yaml. Pour toute API compatible OpenAI — Ollama, vLLM, SGLang, llama.cpp, LM Studio, proxy LiteLLM, Together AI, Groq, Azure OpenAI, ou votre propre serveur auto-hébergé. Configuré une seule fois via hermes model → Custom endpoint, puis persisté dans config.yaml.[^2]

La matrice complète des fournisseurs

Voici la liste complète des fournisseurs de premier ordre, avec le flux de configuration exact pour chacun.[^2]

Anthropic : trois méthodes d’authentification

Anthropic a sa propre section parce que Hermes prend en charge trois chemins distincts vers Claude, et choisir le bon est important. Selon la documentation amont :[^2]

# Method 1: API key (pay-per-token)
export ANTHROPIC_API_KEY=***
hermes chat --provider anthropic --model claude-sonnet-4-6

# Method 2: OAuth through hermes model (preferred)
# Uses Claude Code's credential store when available
hermes model

# Method 3: Manual setup-token (fallback/legacy)
export ANTHROPIC_TOKEN=***
hermes chat --provider anthropic

# Auto-detect Claude Code credentials
hermes chat --provider anthropic   # reads Claude Code files automatically

Lorsque vous choisissez Anthropic OAuth via hermes model, Hermes préfère le magasin d’identifiants propre à Claude Code plutôt que de copier le jeton dans ~/.hermes/.env. Cela garde rafraîchissables les identifiants Claude rafraîchissables.[^2] Si vous utilisez déjà Claude Code sur la même machine, c’est le chemin le plus propre.

Pour épingler Anthropic de manière permanente dans config.yaml :

model:
  provider: "anthropic"
  default: "claude-sonnet-4-6"

--provider claude et --provider claude-code fonctionnent également comme raccourcis pour --provider anthropic.[^2]

GitHub Copilot : deux modes

Copilot est pris en charge selon deux modes : API Copilot directe (recommandé) et Copilot ACP (qui lance la CLI Copilot locale en tant que sous-processus).[^2]

# Direct Copilot API
hermes chat --provider copilot --model gpt-5.4

# Copilot ACP (requires the Copilot CLI in PATH + an existing copilot login)
hermes chat --provider copilot-acp --model copilot-acp

L’authentification est vérifiée dans cet ordre, selon la documentation amont :[^2] 1. Variable d’environnement COPILOT_GITHUB_TOKEN 2. Variable d’environnement GH_TOKEN 3. Variable d’environnement GITHUB_TOKEN 4. Repli sur la CLI gh auth token 5. Connexion par code d’appareil OAuth via hermes model

Le type de jeton est important. L’API Copilot ne prend pas en charge les Personal Access Tokens classiques (ghp_*). Les types pris en charge sont les jetons OAuth (gho_*), les PAT à granularité fine (github_pat_* avec la permission Copilot Requests) et les jetons d’application GitHub (ghu_*). Si votre gh auth token retourne un jeton ghp_*, utilisez hermes model pour vous authentifier via OAuth à la place.[^2]

Fournisseurs IA chinois (prise en charge de premier ordre)

Hermes intègre une prise en charge native de z.ai/GLM, Kimi/Moonshot, MiniMax (points de terminaison globaux + Chine) et Alibaba Cloud avec des identifiants de fournisseur dédiés.[^2]

# z.ai / ZhipuAI GLM
hermes chat --provider zai --model glm-5                 # Requires: GLM_API_KEY

# Kimi / Moonshot AI
hermes chat --provider kimi-coding --model kimi-for-coding   # Requires: KIMI_API_KEY

# MiniMax (global)
hermes chat --provider minimax --model MiniMax-M2.7          # Requires: MINIMAX_API_KEY

# MiniMax (China)
hermes chat --provider minimax-cn --model MiniMax-M2.7       # Requires: MINIMAX_CN_API_KEY

# Alibaba Cloud / DashScope (Qwen)
hermes chat --provider alibaba --model qwen3.5-plus          # Requires: DASHSCOPE_API_KEY

Les URL de base peuvent être surchargées avec les variables d’environnement GLM_BASE_URL, KIMI_BASE_URL, MINIMAX_BASE_URL, MINIMAX_CN_BASE_URL ou DASHSCOPE_BASE_URL.[^2]

Z.AI détecte automatiquement le point de terminaison. Lors de l’utilisation du fournisseur z.ai/GLM, Hermes sonde plusieurs points de terminaison (global, Chine, variantes coding) pour en trouver un qui accepte votre clé API. Le point de terminaison fonctionnel est mis en cache automatiquement — aucune GLM_BASE_URL n’est nécessaire pour la plupart des utilisateurs.[^2]

xAI (Grok) active automatiquement la mise en cache des prompts. Lorsque l’URL de base contient x.ai, Hermes envoie l’en-tête x-grok-conv-id avec chaque requête pour acheminer vers le même serveur au sein d’une session de conversation, en réutilisant les prompts système et l’historique mis en cache.[^2] Automatique ; aucune configuration nécessaire.

La commande hermes auth

hermes auth est la commande de gestion des identifiants pour les pools et les identifiants OAuth.[^7]

hermes auth                              # Interactive wizard
hermes auth list                         # Show all credential pools
hermes auth list openrouter              # Show one provider's pool
hermes auth add openrouter --api-key sk-or-v1-xxx
hermes auth add anthropic --type oauth
hermes auth remove openrouter 2          # Remove by index
hermes auth reset openrouter             # Clear cooldowns

Les pools d’identifiants permettent de faire tourner plusieurs clés API ou jetons OAuth pour le même fournisseur — utile pour répartir les limites de débit sur plusieurs clés sans modifier le code.[^7] Les anciennes commandes hermes login / hermes logout ont été supprimées ; utilisez hermes auth à la place.[^7]

Points de terminaison personnalisés et auto-hébergés

Hermes fonctionne avec n’importe quel point de terminaison API compatible OpenAI. Si un serveur implémente /v1/chat/completions, vous pouvez y pointer Hermes.[^2]

Configuration interactive (recommandée) :

hermes model
# Select "Custom endpoint (self-hosted / VLLM / etc.)"
# Enter: API base URL, API key, Model name

config.yaml manuel :

model:
  default: your-model-name
  provider: custom
  base_url: http://localhost:8000/v1
  api_key: your-key-or-leave-empty-for-local

Les deux approches persistent dans config.yaml, qui est la source unique de vérité pour le modèle principal, le fournisseur et l’URL de base.[^2] Les anciennes variables d’environnement OPENAI_BASE_URL et LLM_MODEL ne sont plus lues pour la configuration du modèle principal — utilisez hermes model ou modifiez directement config.yaml.[^2] (OPENAI_BASE_URL + OPENAI_API_KEY sont toujours honorées comme repli pour le chemin de routage auxiliaire provider: "main", donc ne les supprimez pas aveuglément si vous les utilisez là.)[^4]

Changer de point de terminaison personnalisé en cours de session :

/model custom:qwen-2.5             # Custom endpoint with explicit model
/model custom                      # Auto-detect the model from the endpoint
/model custom:local:qwen-2.5       # Named custom provider "local"
/model custom:work:llama3          # Named custom provider "work"
/model openrouter:claude-sonnet-4  # Back to a cloud provider

/model custom (seul, sans nom de modèle) interroge l’API /v1/models de votre point de terminaison et sélectionne automatiquement le modèle si exactement un est chargé — utile pour les serveurs locaux exécutant un seul modèle.[^2]

Serveurs LLM locaux (modèles de configuration)

La documentation amont contient des guides de configuration complets pour Ollama, vLLM, SGLang, llama.cpp et LM Studio. Voici les commandes clés que vous exécuterez réellement. Chacune est conçue pour produire un point de terminaison fonctionnel auquel Hermes peut être pointé.[^2]

Ollama — le chemin local le plus simple, zéro configuration :

ollama pull qwen2.5-coder:32b
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # Raise from 4k default
hermes model   # Custom endpoint → http://localhost:11434/v1 → qwen2.5-coder:32b

Piège critique d’Ollama : Ollama utilise par défaut des longueurs de contexte très faibles (4 096 jetons sous 24 Go de VRAM). Vous devez l’augmenter via OLLAMA_CONTEXT_LENGTH ou un Modelfile — l’API compatible OpenAI n’accepte pas la longueur de contexte du client, donc Hermes ne peut pas la définir pour vous.[^2] Pour une utilisation par un agent, définissez au moins 16k–32k.

vLLM — service GPU haute performance :

pip install vllm
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --port 8000 \
  --max-model-len 65536 \
  --tensor-parallel-size 2 \
  --enable-auto-tool-choice \
  --tool-call-parser hermes

L’appel d’outils nécessite --enable-auto-tool-choice et --tool-call-parser <name>. Parsers pris en charge : hermes (Qwen 2.5, Hermes 2/3), llama3_json, mistral, deepseek_v3, deepseek_v31, xlam, pythonic. Sans ces drapeaux, les appels d’outils reviendront sous forme de texte brut.[^2]

SGLang — service rapide avec RadixAttention pour la réutilisation du cache KV :

pip install "sglang[all]"
python -m sglang.launch_server \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --port 30000 \
  --context-length 65536 \
  --tp 2 \
  --tool-call-parser qwen

Piège SGLang : la valeur par défaut de max_tokens est 128. Définissez --default-max-tokens sur le serveur ou configurez model.max_tokens dans config.yaml si les réponses sont tronquées.[^2]

llama.cpp / llama-server — CPU et Apple Silicon Metal :

./build/bin/llama-server \
  --jinja -fa \
  -c 32768 \
  -ngl 99 \
  -m models/qwen2.5-coder-32b-instruct-Q4_K_M.gguf \
  --port 8080 --host 0.0.0.0

--jinja est requis pour l’appel d’outils. Sans cela, llama-server ignore complètement le paramètre tools et le modèle essaie d’appeler les outils en écrivant JSON dans son texte de réponse — ce que Hermes ne peut pas analyser comme de véritables appels d’outils.[^2]

LM Studio — application de bureau avec interface graphique :

Démarrez le serveur depuis l’application LM Studio (onglet Developer → Start Server), ou via la CLI : lms server start (démarre sur le port 1234) et lms load qwen2.5-coder --context-length 32768.[^2] Pointez ensuite hermes model sur http://localhost:1234/v1.

Piège critique de LM Studio : LM Studio lit la longueur de contexte depuis les métadonnées du modèle, mais de nombreux modèles GGUF rapportent par défaut 2048 ou 4096. Définissez toujours explicitement la longueur de contexte dans les paramètres du modèle LM Studio — cliquez sur l’icône d’engrenage à côté du sélecteur de modèle, définissez « Context Length » à au moins 16384 (de préférence 32768), et rechargez le modèle.[^2]

Fournisseurs personnalisés nommés

Si vous travaillez avec plusieurs points de terminaison personnalisés (un serveur de développement local et un serveur GPU distant, par exemple), définissez-les comme fournisseurs personnalisés nommés dans config.yaml :[^2]

custom_providers:
  - name: local
    base_url: http://localhost:8080/v1
    # api_key omitted — Hermes uses "no-key-required" for keyless local servers
  - name: work
    base_url: https://gpu-server.internal.corp/v1
    api_key: corp-api-key
    api_mode: chat_completions      # optional, auto-detected from URL
  - name: anthropic-proxy
    base_url: https://proxy.example.com/anthropic
    api_key: proxy-key
    api_mode: anthropic_messages    # for Anthropic-compatible proxies

Puis basculez entre eux en cours de session avec la syntaxe triple :

/model custom:local:qwen-2.5
/model custom:work:llama3-70b
/model custom:anthropic-proxy:claude-sonnet-4

Vous pouvez également sélectionner les fournisseurs personnalisés nommés depuis le menu interactif hermes model.[^2]

Architecture de fournisseurs enfichables (v0.13.0+)

La v0.13.0 livre une ABC ProviderProfile ainsi qu’un répertoire plugins/model-providers/ afin que des fournisseurs d’inférence tiers puissent s’intégrer sans modifications du cœur.[^24] Si un fournisseur parle un mode API compatible OpenAI, Anthropic ou Codex, vous pouvez implémenter une sous-classe ProviderProfile qui déclare le chemin d’authentification, l’URL de base, le catalogue de modèles et les en-têtes de mise en cache ; Hermes la résout via le même chemin runtime_provider.py que les fournisseurs intégrés. C’est le changement architectural à l’origine de l’expansion des fournisseurs en v0.13.0 : au lieu de modifier le code du cœur pour ajouter un fournisseur, vous livrez un plugin.

Détection de la longueur de contexte

Deux paramètres sont constamment confondus, selon la documentation amont :[^2]

• context_length — la fenêtre de contexte totale (budget combiné de jetons d’entrée + de sortie, par exemple 1 000 000 pour Claude Opus 4.7 ou 200 000 pour Sonnet 4.6). Hermes l’utilise pour décider quand compresser l’historique.
• model.max_tokens — le plafond de sortie (nombre maximum de jetons que le modèle peut générer dans une seule réponse). Sans rapport avec la longueur de l’historique.

Définissez context_length lorsque la détection automatique se trompe sur la taille de la fenêtre :

model:
  default: "qwen3.5:9b"
  base_url: "http://localhost:8080/v1"
  context_length: 131072      # tokens

Hermes utilise une chaîne de résolution multi-source pour détecter les fenêtres de contexte : surcharge de configuration → fournisseur personnalisé par modèle → cache persistant → point de terminaison /models → Anthropic /v1/models → API OpenRouter → Nous Portal → models.dev (registre maintenu par la communauté pour plus de 3800 modèles) → valeurs par défaut de repli (128K).[^2] Le système est sensible au fournisseur, donc le même modèle peut avoir des limites de contexte différentes selon qui le sert (par exemple, claude-opus-4.6 est de 1M sur Anthropic direct mais de 128K sur GitHub Copilot).[^2]

Rotation et repli des fournisseurs

Pools d’identifiants. Lorsque vous avez plusieurs clés API pour le même fournisseur, configurez une stratégie de rotation via hermes auth. C’est ainsi que vous répartissez les limites de débit sur plusieurs clés.[^7]

Modèle de repli. Configurez un provider:model de secours sur lequel Hermes bascule automatiquement quand votre modèle principal échoue (limites de débit, erreurs serveur, échecs d’authentification) :[^2]

fallback_model:
  provider: openrouter            # required
  model: anthropic/claude-sonnet-4  # required
  # base_url: http://localhost:8000/v1    # optional, for custom endpoints
  # api_key_env: MY_CUSTOM_KEY           # optional, env var name

Le repli change de modèle et de fournisseur en cours de session sans perdre votre conversation. Il se déclenche au plus une fois par session.[^2] Fournisseurs pris en charge pour le repli : openrouter, nous, openai-codex, copilot, copilot-acp, anthropic, huggingface, zai, kimi-coding, minimax, minimax-cn, deepseek, ai-gateway, opencode-zen, opencode-go, kilocode, alibaba, custom.[^2]

Modèles auxiliaires

Hermes utilise des modèles « auxiliaires » légers pour des tâches annexes : analyse d’images, résumé de pages web, analyse de captures d’écran de navigateur, classification d’approbation de commandes dangereuses, compression de contexte, résumé de recherche de session, correspondance de skills, dispatch d’outils MCP et vidange de mémoire.[^4] Par défaut, ceux-ci utilisent Gemini Flash via détection automatique (OpenRouter → Nous → Codex).

Vous pouvez configurer quel modèle et quel fournisseur chaque tâche auxiliaire utilise. Chaque emplacement auxiliaire utilise les trois mêmes paramètres : provider, model, base_url.[^4]

auxiliary:
  vision:
    provider: "auto"                # "auto", "openrouter", "nous", "codex", "main", etc.
    model: ""                       # e.g. "openai/gpt-4o", "google/gemini-2.5-flash"
    base_url: ""                    # Custom OpenAI-compatible endpoint
    api_key: ""                     # Falls back to OPENAI_API_KEY
    timeout: 30
    download_timeout: 30
  web_extract:
    provider: "auto"
    model: ""
    timeout: 360
  approval:
    provider: "auto"
    model: ""
    timeout: 30
  compression:
    timeout: 120
  session_search: { provider: "auto", model: "", timeout: 30 }
  skills_hub:    { provider: "auto", model: "", timeout: 30 }
  mcp:           { provider: "auto", model: "", timeout: 30 }
  flush_memories:{ provider: "auto", model: "", timeout: 30 }

L’option de fournisseur "main" signifie « utiliser le fournisseur que mon agent principal utilise » — valide uniquement dans les configurations auxiliary:, compression: et fallback_model:. Elle n’est pas valide pour votre paramètre model.provider de niveau supérieur. Si vous utilisez un point de terminaison personnalisé compatible OpenAI comme modèle principal, définissez provider: custom dans votre section model:.[^4]

Pourquoi cela compte : si vous n’avez configuré que Anthropic OAuth (sans clé OpenRouter), votre vision, votre résumé web et votre compression se dégraderont ou échoueront parce que la chaîne de repli auxiliaire par défaut essaie d’abord OpenRouter. Ajoutez une OPENROUTER_API_KEY pour les tâches auxiliaires, ou reconfigurez chaque emplacement auxiliaire pour utiliser votre fournisseur principal :

auxiliary:
  vision:
    provider: "main"
  web_extract:
    provider: "main"

C’est le piège « mes fonctionnalités ne marchent silencieusement pas » le plus courant pour les nouveaux utilisateurs de Hermes.

Système de configuration

Hermes dispose d’un système de configuration en couches. Comprendre l’ordre de priorité est essentiel, car les couches supérieures remplacent les inférieures, et l’une des couches est un registre global de fournisseurs que vous ne pouvez pas voir dans config.yaml.

Organisation des fichiers de configuration

Selon la documentation officielle, voici les fichiers qui composent une configuration Hermes :[^4]

~/.hermes/
├── config.yaml       # All settings (model, terminal, TTS, compression, memory, toolsets, ...)
├── .env              # Secrets (API keys, bot tokens, passwords)
├── auth.json         # OAuth provider credentials (Nous Portal, Codex, Anthropic)
├── SOUL.md           # Primary agent identity (slot #1 in system prompt)
├── memories/         # Persistent memory (MEMORY.md, USER.md)
├── skills/           # Bundled + agent-created + hub-installed skills
├── cron/             # Scheduled jobs
├── sessions/         # Gateway session state
└── logs/             # agent.log, gateway.log, errors.log (secrets auto-redacted)

config.yaml contre .env — lorsque les deux sont définis, config.yaml l’emporte pour les paramètres non sensibles.[^4] La règle est la suivante : - Secrets (clés API, jetons de bots, mots de passe) → .env - Tout le reste (modèle, backend de terminal, paramètres de compression, limites de mémoire, toolsets) → config.yaml

Les secrets peuvent être référencés depuis config.yaml à l’aide d’une interpolation de style shell :[^4]

auxiliary:
  vision:
    api_key: ${GOOGLE_API_KEY}
    base_url: ${CUSTOM_VISION_URL}
  delegation:
    api_key: ${DELEGATION_KEY}

Gérer la configuration

hermes config                # View current configuration
hermes config show           # Same as above
hermes config edit           # Open config.yaml in your editor
hermes config set KEY VAL    # Set a specific value
hermes config path           # Print the config file path
hermes config env-path       # Print the .env file path
hermes config check          # Check for missing options (after updates)
hermes config migrate        # Interactively add missing options

Exemples :[^4]

hermes config set model anthropic/claude-opus-4
hermes config set terminal.backend docker
hermes config set OPENROUTER_API_KEY sk-or-...   # Saves to .env

hermes config check et hermes config migrate sont les commandes à exécuter après chaque hermes update — elles détectent les options de configuration nouvellement ajoutées que votre fichier ne contient pas encore.[^7]

Ordre de priorité de la configuration

Hermes charge la configuration depuis plusieurs sources. Lorsque plusieurs sources définissent la même valeur, c’est la source de plus haute priorité qui l’emporte :[^4]

1. Arguments CLI — hermes chat --model anthropic/claude-sonnet-4 (remplacement à l’invocation)
2. Variables d’environnement — appliquées au démarrage du processus
3. config.yaml — le fichier de paramètres principal
4. .env — secrets uniquement
5. Valeurs par défaut intégrées — appliquées lorsque aucune autre source ne définit de valeur

Les drapeaux CLI l’emportent toujours pour cette invocation unique. config.yaml est la source de vérité à long terme.

Localisation (v0.13.0+)

La v0.13.0 ajoute 7 langues pour les messages CLI et de gateway : chinois (simplifié), japonais, allemand, espagnol, français, ukrainien et turc.[^24] La documentation n’est actuellement localisée qu’en zh-Hans. La langue est déterminée à partir des variables d’environnement LC_ALL / LANG, ou via une clé locale: explicite dans config.yaml. L’anglais reste la valeur par défaut et la source de vérité pour toute chaîne qu’une traduction n’a pas encore couverte.

Profils — Plusieurs instances Hermes isolées

Les profils vous offrent plusieurs instances Hermes isolées, chacune avec sa propre configuration, ses sessions, ses skills, sa mémoire et son PID de gateway. C’est ainsi que vous pouvez faire fonctionner « Hermes professionnel » et « Hermes personnel » côte à côte sans qu’aucun des deux ne voie l’état de l’autre.[^7]

hermes profile list
hermes profile create work --clone                  # Clone from current profile
hermes profile use work                             # Set sticky default
hermes profile alias work --name h-work             # Create wrapper script
hermes profile export work -o work-backup.tar.gz
hermes profile import work-backup.tar.gz --name restored
hermes -p work chat -q "Hello from work profile"    # One-off without switching

Chaque profil dispose de son propre HERMES_HOME (~/.hermes-<name>/ par défaut), de sorte que plusieurs profils peuvent exécuter le gateway simultanément sans se gêner.[^7][^3]

Commandes CLI

Cette section constitue la référence praticien des commandes CLI de premier niveau. Pour la référence officielle dérivée du code, consultez le document CLI Commands Reference en amont.[^7]

Options globales

hermes [global-options] <command> [subcommand/options]

Commandes de premier niveau

hermes chat — Le point d’entrée principal

hermes sans argument lance le chat interactif. hermes chat est la forme explicite avec options :[^7]

hermes chat -q "Summarize the latest PRs"           # One-shot, non-interactive
hermes chat --provider openrouter --model anthropic/claude-sonnet-4.6
hermes chat --toolsets web,terminal,skills          # Enable specific toolsets
hermes chat --quiet -q "Return only JSON"           # Programmatic mode
hermes chat --worktree -q "Review repo and open a PR"

Options principales :

hermes setup — L’assistant complet

Lance l’assistant de configuration complet ou accède directement à une section :[^7]

hermes setup                 # Full wizard
hermes setup model           # Provider and model only
hermes setup terminal        # Terminal backend only
hermes setup gateway         # Messaging platforms only
hermes setup tools           # Tool enable/disable per platform
hermes setup agent           # Agent behavior only
hermes setup --non-interactive
hermes setup --reset         # Reset config to defaults before setup

hermes logs — Requêtes structurées sur les journaux

hermes logs est plus puissant qu’un simple tail -f sur les fichiers de journaux, car il prend en charge le filtrage simultané par niveau, identifiant de session et plage temporelle.[^7]

hermes logs                          # Last 50 lines of agent.log
hermes logs -f                       # Follow in real time
hermes logs gateway -n 100           # Last 100 lines of gateway.log
hermes logs --level WARNING --since 1h   # Warnings from the last hour
hermes logs --session abc123         # Filter by session ID substring
hermes logs errors --since 30m -f    # Follow errors.log from 30m ago
hermes logs list                     # List all log files with sizes

Les fichiers de journaux se trouvent dans ~/.hermes/logs/ :[^7] - agent.log — toute l’activité de l’agent (appels API, dispatch d’outils, cycle de vie des sessions, INFO+) - errors.log — avertissements et erreurs uniquement (sous-ensemble filtré de agent.log) - gateway.log — activité du gateway de messagerie (connexions aux plateformes, dispatch, webhooks)

La rotation est automatique via le RotatingFileHandler de Python — recherchez agent.log.1, agent.log.2, etc.[^7]

hermes doctor — Diagnostics

hermes doctor [--fix] est la première commande à exécuter en cas de problème. Elle vérifie la validité de la configuration, la présence des dépendances, la disponibilité des clés API, l’état des services, et peut tenter des réparations automatiques avec --fix.[^7]

Pour partager les diagnostics avec quelqu’un d’autre, utilisez hermes dump — cette commande produit un résumé compact en texte brut avec les clés API masquées, prêt à coller dans une issue GitHub ou un fil Discord.[^7]

Commandes slash

Les commandes slash s’exécutent à l’intérieur d’une session de chat active (CLI ou plateforme de messagerie). Elles sont distribuées depuis un COMMAND_REGISTRY partagé dans hermes_cli/commands.py, ce qui explique pourquoi la plupart des commandes fonctionnent de manière identique sur toutes les surfaces.[^10]

Contrôle de session

Configuration et modèle

La commande /model est l’outil de prédilection pour changer de provider en cours de session :[^10]

/model                              # Show current model and options
/model claude-sonnet-4              # Switch model (auto-detect provider)
/model zai:glm-5                    # Switch provider:model
/model custom:qwen-2.5              # Use model on custom endpoint
/model custom                       # Auto-detect model from custom endpoint
/model custom:local:qwen-2.5        # Named custom provider
/model openrouter:anthropic/claude-sonnet-4   # Back to cloud

Outils, skills et infos

Commandes slash dynamiques de skills

Chaque skill installée est automatiquement exposée en tant que commande slash :[^10]

/gif-search funny cats
/axolotl help me fine-tune Llama 3 on my dataset
/github-pr-workflow create a PR for the auth refactor
/excalidraw       # Just the skill name loads it and lets the agent ask what you need

Vous pouvez également définir des commandes rapides dans config.yaml qui font correspondre un nom court à un prompt plus long :[^10]

quick_commands:
  review: "Review my latest git diff and suggest improvements"
  deploy: "Run the deployment script at scripts/deploy.sh and verify the output"
  morning: "Check my calendar, unread emails, and summarize today's priorities"

Tapez ensuite /review, /deploy ou /morning dans le CLI.

Correspondance par préfixe

Les commandes prennent en charge la correspondance par préfixe : taper /h se résout en /help, /mod se résout en /model. Lorsqu’un préfixe est ambigu, la première inscription dans l’ordre du registre l’emporte. Les noms de commandes complets et les alias enregistrés ont toujours la priorité sur les correspondances par préfixe.[^10]

Commandes spécifiques à la messagerie

Certaines commandes ne fonctionnent que sur les plateformes de messagerie (Telegram, Discord, Slack, WhatsApp, Signal, Email, Home Assistant) :[^10]

• /status — afficher les infos de session
• /sethome (alias /set-home) — marquer le chat actuel comme home de plateforme
• /approve [session|always] — approuver une commande dangereuse en attente
• /deny — rejeter une commande dangereuse en attente
• /update — mettre à jour Hermes Agent vers la dernière version
• /commands [page] — parcourir toutes les commandes et skills (paginé)

Et certaines sont réservées au CLI : /skin, /tools, /toolsets, /browser, /config, /cron, /skills, /platforms, /paste, /statusbar, /plugins.[^10]

Outils et toolsets

Hermes est livré avec un vaste registre d’outils intégré couvrant la recherche web, l’automatisation du navigateur, l’exécution dans le terminal, l’édition de fichiers, la mémoire, la délégation, l’entraînement RL, l’envoi de messages, l’intégration Home Assistant, et plus encore.[^11] Les outils sont organisés en toolsets logiques qui peuvent être activés ou désactivés par plateforme.

Catégories générales

Les noms de toolsets courants incluent web, terminal, file, browser, vision, image_gen, moa, skills, tts, todo, memory, session_search, cronjob, code_execution, delegation, clarify, homeassistant et rl.[^11]

Gestion des outils

hermes chat --toolsets "web,terminal"       # Use specific toolsets
hermes tools                                # Interactive per-platform tool config
hermes tools --summary                      # Print enabled-tools summary

Les outils peuvent aussi être activés ou désactivés en cours de session via /tools disable <name> et /tools enable <name>, ce qui réinitialise la session afin que le nouveau jeu d’outils prenne effet.[^10]

Backends du terminal

L’outil de terminal peut exécuter des commandes dans 6 environnements différents :[^11]

Changez de backend avec hermes config set terminal.backend <name> ou dans config.yaml :

terminal:
  backend: docker      # or: local, ssh, singularity, modal, daytona
  cwd: "."             # Working directory
  timeout: 180         # Command timeout in seconds

Backend SSH (recommandé pour la sécurité — l’agent ne peut pas modifier son propre code) :[^11]

terminal:
  backend: ssh

# In ~/.hermes/.env
TERMINAL_SSH_HOST=my-server.example.com
TERMINAL_SSH_USER=myuser
TERMINAL_SSH_KEY=~/.ssh/id_rsa

Backend Docker :

terminal:
  backend: docker
  docker_image: python:3.11-slim

Ressources de conteneur (s’applique à docker, singularity, modal, daytona) :[^11]

terminal:
  container_cpu: 1
  container_memory: 5120          # MB (default 5GB)
  container_disk: 51200           # MB (default 50GB)
  container_persistent: true      # Persist filesystem across sessions

Avec container_persistent: true, les paquets installés, les fichiers et la configuration persistent d’une session à l’autre.[^11]

Tous les backends de conteneur s’exécutent avec un renforcement de sécurité : système de fichiers racine en lecture seule (Docker), toutes les capacités Linux supprimées sauf DAC_OVERRIDE, CHOWN et FOWNER, aucune élévation de privilèges, limites PID (256 processus), isolation complète par namespaces, espace de travail persistant via volumes.[^11]

Processus en arrière-plan

L’outil de terminal prend en charge l’exécution en arrière-plan avec une gestion explicite des processus :[^11]

terminal(command="pytest -v tests/", background=true)
# Returns: {"session_id": "proc_abc123", "pid": 12345}

process(action="list")                            # Show all running processes
process(action="poll", session_id="proc_abc123")  # Check status
process(action="wait", session_id="proc_abc123")  # Block until done
process(action="log", session_id="proc_abc123")   # Full output
process(action="kill", session_id="proc_abc123")  # Terminate
process(action="write", session_id="proc_abc123", data="y")  # Send input

Le mode PTY (pty=true) active les outils CLI interactifs comme Codex et Claude Code.[^11]

Sudo

Si une commande a besoin de sudo, Hermes vous demande votre mot de passe (mis en cache pour la session). Vous pouvez aussi définir SUDO_PASSWORD dans ~/.hermes/.env.[^11]

Kanban multi-agent (v0.13.0+)

La v0.13.0 transforme la collaboration multi-agent en primitive de premier ordre : un tableau Kanban durable qui suit les tâches, leur statut et l’identité des workers entre agents et après les redémarrages.[^24] C’est ce tableau qui permet à un essaim de workers Hermes de réellement terminer le travail au lieu de rester bloqué sur des passages de relais morts.

Le tableau Kanban s’associe naturellement à /goal (boucle Ralph à cible verrouillée) côté cible et à l’outil existant delegate_task pour la sémantique de spawn. Il en résulte un modèle d’essaim où chaque agent partage une source de vérité unique pour savoir quoi faire ensuite, qui s’en occupe et ce qui est bloqué.

Système de skills

Les skills sont des documents de connaissances à la demande que l’agent peut charger lorsqu’il en a besoin. Elles suivent un modèle de divulgation progressive pour réduire l’utilisation des tokens et sont compatibles avec le standard ouvert agentskills.io.[^12]

Toutes les skills se trouvent dans ~/.hermes/skills/ — le dossier principal et la source de vérité. Lors d’une nouvelle installation, les skills intégrées sont copiées depuis le repo. Les skills installées depuis le hub et créées par l’agent y sont également placées.[^12]

Divulgation progressive

Level 0: skills_list()           → [{name, description, category}, ...]   (~3k tokens)
Level 1: skill_view(name)        → Full content + metadata                 (varies)
Level 2: skill_view(name, path)  → Specific reference file                 (varies)

L’agent ne charge le contenu complet de la skill que lorsqu’il en a réellement besoin.[^12]

Format SKILL.md

---
name: my-skill
description: Brief description of what this skill does
version: 1.0.0
platforms: [macos, linux]      # Optional — restrict to OS platforms
metadata:
  hermes:
    tags: [python, automation]
    category: devops
    fallback_for_toolsets: [web]     # Conditional activation
    requires_toolsets: [terminal]    # Conditional activation
    config:                          # Config.yaml settings
      - key: my.setting
        description: "What this controls"
        default: "value"
        prompt: "Prompt for setup"
---

# Skill Title

## When to Use
Trigger conditions for this skill.

## Procedure
1. Step one
2. Step two

## Pitfalls
- Known failure modes and fixes

## Verification
How to confirm it worked.

Activation conditionnelle

Les skills peuvent s’afficher ou se masquer selon les outils disponibles. C’est particulièrement utile pour les skills de fallback — des alternatives gratuites ou locales qui ne doivent apparaître que lorsqu’un outil premium est indisponible :[^12]

Exemple : la skill intégrée duckduckgo-search utilise fallback_for_toolsets: [web]. Lorsque FIRECRAWL_API_KEY est défini, le toolset web est disponible et l’agent utilise web_search — la skill DuckDuckGo reste masquée. Sans la clé API, la skill DuckDuckGo apparaît automatiquement comme fallback.[^12]

Skills gérées par l’agent

L’agent peut créer, mettre à jour et supprimer ses propres skills via l’outil skill_manage. C’est la mémoire procédurale de l’agent — lorsqu’il comprend un workflow non trivial, il enregistre l’approche sous forme de skill pour la réutiliser plus tard.[^12]

Quand l’agent crée des skills :[^12] - Après avoir mené à bien une tâche complexe (5 appels d’outils ou plus) - Lorsqu’il a rencontré des erreurs ou des impasses et trouvé la voie qui fonctionne - Lorsque l’utilisateur a corrigé son approche - Lorsqu’il a découvert un workflow non trivial

Actions :[^12]

Hub de skills

Parcourez, recherchez, installez et gérez des skills depuis des registres en ligne :[^7][^12]

hermes skills browse                          # Browse all hub skills
hermes skills browse --source official        # Browse official optional skills
hermes skills search kubernetes               # Search all sources
hermes skills search react --source skills-sh # Search skills.sh directory
hermes skills inspect openai/skills/k8s       # Preview before installing
hermes skills install openai/skills/k8s       # Install with security scan
hermes skills install skills-sh/anthropics/skills/pdf --force
hermes skills check                           # Check for upstream updates
hermes skills update                          # Reinstall changed hub skills
hermes skills audit                           # Re-scan installed hub skills
hermes skills uninstall k8s
hermes skills publish skills/my-skill --to github --repo owner/repo
hermes skills tap add myorg/skills-repo       # Add custom GitHub source

Sources de hub intégrées :[^12]

Taps GitHub par défaut (consultables sans configuration) : openai/skills, anthropics/skills, VoltAgent/awesome-agent-skills, garrytan/gstack.[^12]

Analyse de sécurité

Toutes les skills installées depuis le hub passent par un scanner de sécurité qui recherche l’exfiltration de données, le prompt injection, les commandes destructrices, les signaux de supply-chain et d’autres menaces.[^12]

Niveaux de confiance :[^12]

--force peut contourner les blocages de politique non dangereux pour les skills communautaires. Il ne contourne pas un verdict d’analyse dangerous.[^12]

Dossiers de skills externes

Vous pouvez faire pointer Hermes vers des dossiers de skills supplémentaires, analysés avec le dossier local :[^12]

skills:
  external_dirs:
    - ~/.agents/skills
    - /home/shared/team-skills
    - ${SKILLS_REPO}/skills

Les chemins prennent en charge l’expansion de ~ et la substitution des variables d’environnement ${VAR}. Les dossiers externes sont en lecture seule — lorsque l’agent crée ou modifie une skill, il écrit toujours dans ~/.hermes/skills/. La priorité locale l’emporte si un nom de skill existe aux deux emplacements.[^12]

Mémoire persistante

Hermes dispose d’une mémoire limitée et organisée qui persiste d’une session à l’autre. Deux fichiers constituent la mémoire de l’agent, tous deux stockés dans ~/.hermes/memories/ :[^13]

Les deux sont injectés dans le prompt système sous forme de snapshot figé au démarrage de la session. L’agent gère sa propre mémoire via l’outil memory — add, replace ou remove.[^13]

Pattern de snapshot figé : l’injection dans le prompt système est capturée une seule fois au démarrage de la session et ne change jamais en cours de session. C’est intentionnel : cela préserve le cache de préfixe de LLM pour les performances. Les modifications effectuées pendant une session sont immédiatement persistées sur disque, mais n’apparaissent dans le prompt système qu’à la session suivante.[^13]

Que sauvegarder

À sauvegarder (l’agent le fait de manière proactive) :[^13] - Préférences utilisateur : « Je préfère TypeScript à JavaScript » → user - Faits sur l’environnement : « Ce serveur exécute Debian 12 avec PostgreSQL 16 » → memory - Corrections : « N’utilisez pas sudo pour les commandes Docker, l’utilisateur fait partie du groupe docker » → memory - Conventions : « Le projet utilise des tabulations, une largeur de ligne de 120 caractères et des docstrings de style Google » → memory - Travail terminé : « Base de données migrée de MySQL vers PostgreSQL le 15 janvier 2026 » → memory

À ignorer :[^13] - Informations triviales ou évidentes - Faits faciles à retrouver - Dumps de données brutes (trop volumineux pour la mémoire) - Éléments éphémères propres à une session - Informations déjà présentes dans les fichiers de contexte

Recherche de sessions

Au-delà de MEMORY.md et USER.md, l’agent peut rechercher dans ses conversations passées avec l’outil session_search. Toutes les sessions CLI et de messagerie sont stockées dans SQLite (~/.hermes/state.db) avec une recherche plein texte FTS5. Les requêtes renvoient des conversations passées pertinentes, avec synthèse par Gemini Flash.[^13]

Fournisseurs de mémoire externes

Pour une mémoire persistante plus approfondie au-delà de MEMORY.md et USER.md, Hermes inclut huit plugins de fournisseurs de mémoire externes : Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover et Supermemory.[^13]

Les fournisseurs externes s’exécutent en parallèle de la mémoire intégrée (sans jamais la remplacer) et ajoutent des capacités comme les graphes de connaissances, la recherche sémantique, l’extraction automatique de faits et la modélisation utilisateur intersessions :[^7][^13]

hermes memory setup         # Pick a provider and configure it
hermes memory status        # Check what's active
hermes memory off           # Disable external provider (built-in only)

Un seul fournisseur externe peut être actif à la fois. La mémoire intégrée est toujours active.[^7]

Reprise automatique de session (v0.13.0+)

v0.13.0 rend les interruptions au milieu d’un agent récupérables. Le gateway reprend automatiquement les sessions interrompues après un redémarrage ; les redémarrages /update préservent l’état de session pendant la mise à niveau ; les rechargements de fichiers source pendant le développement gardent la session active en vie au lieu d’en forcer une nouvelle.[^24] Effet pratique : les travaux gateway de longue durée et les tâches pilotées par cron ne réinitialisent plus leur fenêtre de contexte lorsque le processus redémarre.

Checkpoints v2 (v0.13.0+)

La persistance d’état est réécrite en v0.13.0 sous la forme d’une conception à stockage unique, avec véritable élagage, garde-fous disque et aucun dépôt fantôme orphelin.[^24] L’ancien système de checkpoint accumulait de l’état sur disque dans les profiles de longue durée ; le store v2 impose un plafond strict au stockage local des checkpoints et supprime la comptabilité dupliquée qui provoquait cette croissance. Aucun changement de configuration côté utilisateur n’est requis ; la prochaine écriture de checkpoint utilise le chemin v2.

Personnalité et SOUL.md

SOUL.md est l’identité principale d’une instance Hermes. Il occupe l’emplacement n° 1 dans le prompt système, en remplaçant l’identité par défaut codée en dur.[^14]

Hermes initialise automatiquement un SOUL.md par défaut dans ~/.hermes/SOUL.md (ou $HERMES_HOME/SOUL.md pour les profiles personnalisés). Les fichiers utilisateur existants ne sont jamais écrasés. Hermes charge SOUL.md uniquement depuis HERMES_HOME — il ne cherche pas dans le dossier de travail courant. La personnalité reste ainsi prévisible d’un projet à l’autre.[^14]

Ce qui a sa place dans SOUL.md

Utilisez-le pour des consignes durables de voix et de personnalité :[^14] - ton - style de communication - niveau de franchise - style d’interaction par défaut - éléments stylistiques à éviter - manière dont Hermes doit gérer l’incertitude, le désaccord et l’ambiguïté

À utiliser moins pour :[^14] - instructions ponctuelles propres à un projet - chemins de fichiers - conventions de repo - détails temporaires de workflow

Ces éléments relèvent de AGENTS.md, pas de SOUL.md.

SOUL.md vs AGENTS.md

Voici la distinction la plus importante dans la gestion de l’identité Hermes :[^14]

SOUL.md — identité, ton, style, valeurs par défaut de communication, comportement au niveau de la personnalité.

AGENTS.md — architecture du projet, conventions de code, préférences d’outils, workflows propres au repo, commandes, ports, chemins, notes de déploiement.

Règle utile : si cela doit vous suivre partout, cela relève de SOUL.md. Si cela appartient à un projet, cela relève de AGENTS.md.[^14]

Personnalités intégrées

Hermes inclut des personnalités intégrées que vous pouvez activer avec /personality :[^14]

Personnalités personnalisées dans config.yaml :[^14]

agent:
  personalities:
    codereviewer: >
      You are a meticulous code reviewer. Identify bugs, security issues,
      performance concerns, and unclear design choices. Be precise and constructive.

Passez ensuite à /personality codereviewer.

SOUL.md vs /personality

SOUL.md est la voix de base. /personality est une surcouche au niveau de la session.[^14] Gardez un SOUL.md pragmatique par défaut, puis utilisez /personality teacher pour une conversation de tutorat ou /personality creative pour du brainstorming.

Nous Tool Gateway (v0.10.0+)

Depuis Hermes Agent v0.10.0 (16 avril 2026), les abonnés Nous Portal payants bénéficient d’un accès géré à un ensemble d’outils sélectionnés via leurs identifiants Portal existants — sans clés API supplémentaires à gérer.[^21] Le CLI Hermes lui-même reste sous licence MIT et entièrement open source. Ce qui change, c’est que votre authentification Portal déverrouille désormais plus que l’inférence de modèles.

Contenu du gateway

Fonctionnement

Le gateway est opt-in par outil via un nouveau champ de configuration use_gateway. Si vous avez des identifiants Portal dans hermes auth et activez le gateway pour un outil, les appels de cet outil passent par Portal. Sinon, votre clé API directe (si présente) est utilisée.

# config.yaml — per-tool gateway opt-in
tools:
  web_search:
    provider: firecrawl
    use_gateway: true          # route via Nous Portal subscription
  image_generation:
    provider: fal
    use_gateway: true

Priorité à l’exécution : lorsque le gateway est disponible et qu’un outil a use_gateway: true, Hermes privilégie le gateway même si vous avez aussi configuré une clé API directe. C’est important pour la facturation : les appels gateway sont décomptés de votre abonnement Portal, pas du solde de votre clé API directe.

Activer le gateway

hermes model                      # select Nous Portal (OAuth flow)
hermes tools                      # per-platform tool picker integrates gateway tools
hermes status                     # confirms gateway/subscription detection

Il n’existe pas de commande séparée hermes subscribe ou hermes login --portal. L’abonnement est détecté automatiquement à partir des identifiants OAuth Portal que vous avez déjà dans hermes auth.

Tarifs et accès

Les tarifs et noms de paliers sont publiés sur la page de tarification Nous Portal (https://portal.nousresearch.com/pricing). Ce guide n’énumère pas les paliers, car ils relèvent du produit Portal, pas du CLI Hermes, et changent indépendamment des versions de Hermes. Inscrivez-vous sur https://portal.nousresearch.com/ et consultez la page de tarification pour connaître les paliers actuels.

Avis de dépréciation

• La variable d’environnement HERMES_ENABLE_NOUS_MANAGED_TOOLS est supprimée dans v0.10.0. Les outils gérés sont désormais activés via le champ de configuration par outil use_gateway et conditionnés par l’état de votre abonnement Portal.[^21]

Cadrage : ce que cette version n’est pas

Le CLI Hermes Agent n’est pas verrouillé derrière un abonnement. Le projet reste sous licence MIT, et toutes les fonctionnalités de base (CLI, skills, mémoire, gateway de messagerie, cron, MCP, dashboard local, BYOK pour chaque fournisseur) fonctionnent de bout en bout sans payer qui que ce soit. v0.10.0 ajoute un chemin pratique pour les utilisateurs qui paient déjà Nous Portal — il ne retire rien au parcours gratuit.

Gateway de messagerie

Hermes peut fonctionner comme un processus gateway de longue durée qui se connecte à 20 plateformes de messagerie depuis un seul processus gateway : Telegram, Discord, Slack, WhatsApp, Signal, SMS, Email, Home Assistant, Mattermost, Matrix, DingTalk, Feishu/Lark, WeCom, Weixin (WeChat), BlueBubbles (iMessage), QQBot, Microsoft Teams, Tencent Yuanbao, Google Chat, et un adaptateur Webhook générique.[^3][^22][^23][^24] v0.9.0 a ajouté iMessage via BlueBubbles (enregistrement automatique du webhook, assistant de configuration, résilience aux crashs) et la prise en charge native de WeChat via iLink Bot API, avec le mode callback WeCom pour les applications d’entreprise.[^20] v0.11.0 a ajouté QQBot.[^22] v0.12.0 a ajouté Microsoft Teams et Tencent Yuanbao.[^23] v0.13.0 a ajouté Google Chat comme 20e plateforme, en s’appuyant sur la même architecture d’adaptateurs enfichables ; IRC et Microsoft Teams ont aussi été migrés vers le nouveau modèle d’adaptateur avec des hooks plugin génériques env_enablement_fn / cron_deliver_env_var.[^24]

Configuration

hermes gateway setup                # Interactive platform configuration
hermes gateway install              # Install as user service (systemd/launchd)
hermes gateway start                # Start the installed service
hermes gateway stop
hermes gateway restart
hermes gateway status
hermes gateway run                  # Run in foreground (debugging)

La configuration interactive vous guide dans la connexion de chaque plateforme : tokens API, IDs de bot, correspondances de canaux, allowlists.[^7]

Flux des messages

D’après la documentation d’architecture upstream :[^3]

Platform event → Adapter.on_message() → MessageEvent
  → GatewayRunner._handle_message()
    → authorize user
    → resolve session key
    → create AIAgent with session history
    → AIAgent.run_conversation()
    → deliver response back through adapter

Chaque plateforme de messagerie passe par la même boucle de conversation AIAgent que le CLI. C’est pourquoi les commandes slash fonctionnent de façon identique aux deux endroits et pourquoi une tâche cron planifiée dans Telegram peut livrer sa sortie dans Discord : la différence de plateforme se situe uniquement en périphérie.[^3]

Autorisation et appairage des utilisateurs

hermes pairing list                    # Show pending and approved users
hermes pairing approve <platform> <code>
hermes pairing revoke <platform> <user-id>
hermes pairing clear-pending

Les codes d’appairage empêchent des inconnus de parler à votre gateway. Un utilisateur envoie un code d’appairage depuis sa plateforme de messagerie ; vous l’approuvez avec hermes pairing approve ; dès lors, il est autorisé.[^7]

Tâches planifiées (Cron)

Hermes dispose d’un système cron de premier ordre où les jobs sont des tâches d’agent, pas des commandes shell. Chaque job planifié s’exécute via un nouvel AIAgent avec le prompt configuré, des skills associés facultatifs, et livre les résultats vers n’importe quelle plateforme :[^3][^7]

hermes cron list
hermes cron create --prompt "Check HN for AI news and summarize" --schedule "0 9 * * *" --deliver telegram
hermes cron edit <id>
hermes cron pause <id>
hermes cron resume <id>
hermes cron run <id>         # Trigger now on the next tick
hermes cron remove <id>
hermes cron status           # Check if scheduler is running
hermes cron tick             # Run due jobs once and exit

Ou créez-en un de manière conversationnelle dans un chat de messagerie :

Every morning at 9am, check Hacker News for AI news and send me a summary on Telegram.

L’agent configurera le job cron via ses tools. Les jobs persistent dans JSON et survivent aux redémarrages.[^3]

Intégration MCP

Hermes prend en charge le Model Context Protocol à la fois comme client et comme serveur :[^7]

Comme client — connectez Hermes à des serveurs MCP externes pour étendre sa surface de tools :

hermes mcp add <name> --url https://example.com/mcp
hermes mcp add <name> --command npx --args "-y,@modelcontextprotocol/server-github"
hermes mcp list
hermes mcp test <name>
hermes mcp remove <name>
hermes mcp configure <name>   # Toggle individual tool selection

Ou manuellement dans config.yaml :[^15]

mcp_servers:
  github:
    command: npx
    args: ["-y", "@modelcontextprotocol/server-github"]
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "ghp_xxx"

Comme serveur — exposez les conversations Hermes à d’autres agents :

hermes mcp serve
hermes mcp serve -v    # Verbose

Compression du contexte

Hermes compresse automatiquement les longues conversations pour rester dans la fenêtre de contexte de votre modèle. Le résumeur de compression est un appel LLM séparé : vous pouvez le faire pointer vers n’importe quel provider ou endpoint.[^4]

compression:
  enabled: true
  threshold: 0.50                           # Compress at this % of context limit
  target_ratio: 0.20                        # Fraction to preserve as recent tail
  protect_last_n: 20                        # Min recent messages to keep uncompressed
  summary_model: "google/gemini-3-flash-preview"
  summary_provider: "auto"                  # "auto", "openrouter", "nous", "codex", "main", etc.
  summary_base_url: null                    # Custom OpenAI-compatible endpoint

Options de provider :[^4]

summary_model doit prendre en charge une longueur de contexte au moins aussi grande que celle de votre modèle principal, puisqu’il reçoit toute la section centrale de la conversation à compresser.[^4]

Avertissements de pression sur le budget

Quand l’agent travaille sur une tâche complexe avec de nombreux appels de tools, il peut consommer tout son budget d’itérations (par défaut : 90 tours) sans s’en rendre compte. La pression sur le budget avertit automatiquement le modèle :[^4]

Délais d’expiration de stream

La connexion de streaming LLM comporte deux couches de délai d’expiration qui s’ajustent automatiquement pour les providers locaux (localhost, IPs LAN) :[^4]

Le délai de lecture socket est porté à 30 minutes pour les endpoints locaux, car les LLM locaux peuvent prendre plusieurs minutes de préremplissage sur de grands contextes avant de produire le premier token.[^4]

Dashboard web local (v0.9.0+)

Un dashboard dans le navigateur pour gérer localement votre Hermes Agent. Configurez les paramètres, surveillez les sessions, parcourez les skills et gérez votre gateway sans toucher aux fichiers de configuration ni au terminal.[^20] Lancez-le avec hermes dashboard. C’est le parcours d’onboarding le plus simple pour les nouveaux utilisateurs qui préfèrent une GUI.

Surveillance des processus en arrière-plan (v0.9.0+)

watch_patterns vous permet de définir des motifs à surveiller dans la sortie des processus en arrière-plan et d’être notifié en temps réel quand ils correspondent.[^20] Surveillez les erreurs, attendez des événements précis (« listening on port ») ou suivez les logs de build — le tout sans polling. Combiné à notify_on_complete de v0.8.0 (qui notifie la fin d’une tâche en arrière-plan), Hermes dispose désormais d’une couche complète d’observabilité des processus en arrière-plan.[^19]

Context engine enfichable (v0.9.0+)

La gestion du contexte est désormais un slot enfichable via hermes plugins. Remplacez-la par des context engines personnalisés qui contrôlent ce que l’agent voit à chaque tour : filtrage, synthèse ou injection de contexte propre à un domaine.[^20] Cela découple la stratégie de contexte de la boucle centrale de l’agent et permet une personnalisation du contexte par projet ou par domaine.

Sauvegarde et restauration (v0.9.0+)

hermes backup crée une archive complète de votre configuration, de vos sessions, de vos skills et de votre mémoire. hermes import restaure depuis une archive de sauvegarde.[^20] Utilisez-le pour migrer entre machines, créer des snapshots avant des changements majeurs ou partager une configuration connue comme fiable avec vos coéquipiers.

Prise en charge de Termux / Android (v0.9.0+)

Hermes s’exécute nativement sur Android via Termux. Les chemins d’installation adaptés, les optimisations TUI pour les écrans mobiles, la prise en charge du backend vocal et la commande /image fonctionnent directement sur l’appareil.[^20]

Renforcement de la sécurité (v0.13.0+)

v0.13.0 a corrigé 8 problèmes de sécurité P0 et changé un paramètre par défaut dans l’intérêt de l’utilisateur.[^24]

Si vous maintenez un déploiement Hermes, traitez v0.13.0 comme une mise à niveau pertinente pour la sécurité, pas seulement comme une livraison de fonctionnalités. Le contournement Discord inter-guildes et les deux fenêtres TOCTOU sont exploitables sur les versions antérieures.

Architecture pour les praticiens

Cette section s’adresse aux personnes qui souhaitent comprendre ce qui se passe sous le capot afin de pouvoir le déboguer, l’étendre ou raisonner sur les performances. Il s’agit d’une synthèse de la documentation d’architecture en amont.[^3]

Points d’entrée → AIAgent

Chaque point d’entrée dans Hermes appelle finalement AIAgent.run_conversation() :

┌──────────────────────────────────────────────────────────────────┐
│                        Entry Points                              │
│                                                                  │
│  CLI (cli.py)    Gateway (gateway/run.py)    ACP (acp_adapter/)  │
│  Batch Runner    API Server                  Python Library     │
└──────────┬──────────────┬───────────────────────┬────────────────┘
           │              │                       │
           ▼              ▼                       ▼
┌──────────────────────────────────────────────────────────────────┐
│                     AIAgent (run_agent.py)                       │
│                                                                  │
│  ┌─────────────┐  ┌──────────────┐  ┌──────────────┐             │
│  │ Prompt      │  │ Provider     │  │ Tool         │             │
│  │ Builder     │  │ Resolution   │  │ Dispatch     │             │
│  └──────┬──────┘  └──────┬───────┘  └──────┬───────┘             │
│         │                │                 │                    │
│  ┌──────┴───────┐ ┌──────┴───────┐  ┌──────┴───────┐             │
│  │ Compression  │ │ 3 API Modes  │  │ Tool Registry│             │
│  │ & Caching    │ │ chat_compl   │  │ 47 tools     │             │
│  │              │ │ codex_resp   │  │ 20 toolsets  │             │
│  │              │ │ anthropic    │  │              │             │
│  └──────────────┘ └──────────────┘  └──────────────┘             │
└──────────────────────────────────────────────────────────────────┘

Diagramme adapté de la documentation d’architecture en amont.[^3]

« 47 tools / 20 toolsets » vs « 28 tools » dans votre bannière. Le décompte « 47 tools » correspond au registre total des outils du dépôt en amont — chaque outil pour lequel Hermes fournit du code source, sur l’ensemble des toolsets. Votre CLI en cours d’exécution affichera un nombre plus petit dans sa bannière de démarrage (l’installation à partir de laquelle j’ai vérifié ce guide indique 28 tools / 89 skills). Ce n’est pas un bug. De nombreux toolsets sont opt-in et doivent être explicitement activés dans config.yaml sous toolsets: — adaptateurs de plateformes de messagerie, automatisation de navigateur, outils de scraping plus lourds, etc. Le total du registre représente « ce qui est disponible » ; le nombre de la bannière représente « ce qui est activé dans votre profil actuel ». Vérifiez quels toolsets sont actifs avec hermes tools --list et activez ou désactivez des toolsets individuels avec le bloc toolsets: dans ~/.hermes/config.yaml (ou /tools list / /tools enable <name> / /tools disable <name> dans une session en cours d’exécution — la suppression d’un outil déclenche une réinitialisation de session afin que l’agent reconstruise son manifeste d’outils).

Les trois modes API

Hermes abstrait les différences entre fournisseurs en trois modes API, sélectionnés automatiquement à l’exécution :[^3]

Le résolveur runtime_provider.py mappe les tuples (provider, model) vers (api_mode, api_key, base_url) pour plus de 18 fournisseurs, en gérant les flux OAuth, les pools d’identifiants et la résolution d’alias.[^3]

Flux de données dans une session CLI

User input → HermesCLI.process_input()
  → AIAgent.run_conversation()
    → prompt_builder.build_system_prompt()
    → runtime_provider.resolve_runtime_provider()
    → API call (chat_completions / codex_responses / anthropic_messages)
    → tool_calls? → model_tools.handle_function_call() → loop
    → final response → display → save to SessionDB

D’après la page d’architecture en amont.[^3]

Ordre d’assemblage du prompt

La pile de prompts comprend :[^14]

1. SOUL.md (identité de l’agent — ou solution de repli intégrée si indisponible)
2. Guidance comportementale tenant compte des outils
3. Mémoire/contexte utilisateur (MEMORY.md, USER.md)
4. Guidance des skills
5. Fichiers de contexte (AGENTS.md, .cursorrules)
6. Horodatage
7. Indications de formatage spécifiques à la plateforme
8. Surcouches optionnelles du prompt système telles que /personality

SOUL.md constitue le fondement — tout le reste se construit par-dessus.[^14]

Stockage de session

Stockage de session basé sur SQLite avec recherche en texte intégral FTS5. Les sessions disposent d’un suivi de lignée (parent/enfant à travers les compressions), d’une isolation par plateforme et d’écritures atomiques avec gestion de la contention.[^3]

Système de plugins

Trois sources de découverte : ~/.hermes/plugins/ (utilisateur), .hermes/plugins/ (projet) et points d’entrée pip. Les plugins enregistrent des outils, des hooks et des commandes CLI via un contexte API. Les fournisseurs de mémoire sont un type de plugin spécialisé sous plugins/memory/.[^3]

hermes plugins                       # Interactive enable/disable UI
hermes plugins install <repo>        # Install from Git URL or owner/repo
hermes plugins enable <name>
hermes plugins disable <name>
hermes plugins list

Principes de conception

D’après la page d’architecture en amont :[^3]

Migration depuis OpenClaw

Hermes Agent est le successeur d’OpenClaw. Si vous migrez depuis une installation OpenClaw existante :[^7][^5]

hermes claw migrate --dry-run                    # Preview what would be migrated
hermes claw migrate --preset full                # Full migration including API keys
hermes claw migrate --preset user-data --overwrite   # User data only, no secrets
hermes claw migrate --source /custom/path        # Non-default OpenClaw location

hermes claw migrate lit depuis ~/.openclaw par défaut (détecte également automatiquement les répertoires hérités ~/.clawdbot et ~/.moldbot) et écrit dans ~/.hermes.[^7]

Importés directement (plus de 30 catégories) : SOUL.md, MEMORY.md, USER.md, AGENTS.md, skills depuis 4 répertoires sources, modèle par défaut, fournisseurs personnalisés, serveurs MCP, tokens et listes d’autorisation des plateformes de messagerie (Telegram, Discord, Slack, WhatsApp, Signal, Matrix, Mattermost), valeurs par défaut de l’agent (effort de raisonnement, compression, délai humain, fuseau horaire, sandbox), politiques de réinitialisation de session, règles d’approbation, configuration TTS, paramètres du navigateur, paramètres des outils, délai d’expiration d’exec, liste d’autorisation des commandes, configuration de la gateway et clés API depuis 3 sources.[^7]

Archivés pour examen manuel : tâches cron, plugins, hooks/webhooks, backend mémoire (QMD), configuration du registre des skills, UI/identité, journalisation, configuration multi-agents, liaisons de canaux, IDENTITY.md, TOOLS.md, HEARTBEAT.md, BOOTSTRAP.md.[^7]

La résolution des clés API vérifie trois sources par ordre de priorité : valeurs de config → ~/.openclaw/.env → auth-profiles.json.[^7]

Dépannage

« API key not set »

Exécutez hermes model pour configurer votre fournisseur de manière interactive, ou hermes config set OPENROUTER_API_KEY your_key. La commande hermes doctor vous indiquera précisément quelles clés sont manquantes.[^8]

« Context limit: 2048 tokens » au démarrage (modèles locaux)

Hermes détecte automatiquement la longueur du contexte depuis l’endpoint /v1/models de votre serveur, mais de nombreux serveurs locaux rapportent des valeurs par défaut faibles. Définissez-la explicitement dans config.yaml :[^2]

model:
  default: your-model
  provider: custom
  base_url: http://localhost:11434/v1
  context_length: 32768

Les appels d’outils apparaissent comme du texte au lieu de s’exécuter

Votre serveur n’a pas l’appel d’outils activé, ou le modèle ne le prend pas en charge via l’implémentation du serveur.[^2]

Les réponses sont coupées en milieu de phrase

Deux causes possibles :[^2]

1. Plafond de sortie faible (max_tokens) sur le serveur — SGLang utilise par défaut 128 tokens par réponse. Définissez --default-max-tokens sur le serveur ou configurez model.max_tokens dans config.yaml.
2. Épuisement du contexte — Le modèle a rempli sa fenêtre de contexte. Augmentez model.context_length ou activez la compression de contexte dans Hermes.

« Connection refused » depuis WSL2 vers un serveur de modèle hébergé sur Windows

WSL2 utilise un adaptateur réseau virtuel avec son propre sous-réseau — localhost à l’intérieur de WSL2 fait référence à la VM Linux, pas à l’hôte Windows. Deux options :[^2]

Réseau en miroir (Windows 11 22H2+) : modifiez %USERPROFILE%\.wslconfig :

[wsl2]
networkingMode=mirrored

Puis wsl --shutdown et redémarrez. localhost fonctionne désormais de manière bidirectionnelle.

Repli sur l’IP de l’hôte (Windows plus anciens) : récupérez l’IP de l’hôte Windows depuis WSL2 et utilisez-la à la place de localhost :

ip route show | grep -i default | awk '{ print $3 }'
# Use that IP as the base_url host

Vous devez également faire en sorte que le serveur de modèle écoute sur 0.0.0.0, et non sur 127.0.0.1 — définissez OLLAMA_HOST=0.0.0.0 pour Ollama, ajoutez --host 0.0.0.0 pour llama-server/SGLang, ou activez « Serve on Network » dans LM Studio.[^2]

Où se trouve quoi ?

hermes status et hermes dump sont vos alliés. hermes logs list affiche tous les fichiers de logs avec leur taille. hermes config path affiche l’emplacement du fichier de configuration. hermes config env-path affiche l’emplacement du fichier .env.[^7]

FAQ

Quelle est la différence entre Hermes Agent et Claude Code ?

Claude Code est le CLI officiel de Anthropic, verrouillé sur les modèles Anthropic. Hermes Agent est un framework d’agent open-source de Nous Research qui fonctionne avec n’importe quel fournisseur compatible OpenAI — Nous Portal, OpenRouter, Anthropic, GitHub Copilot, z.ai, Kimi, MiniMax, DeepSeek, Hugging Face, Google, ou votre propre endpoint auto-hébergé.[^1][^2] Hermes embarque également une passerelle de messagerie pour Telegram/Discord/Slack/WhatsApp/Signal que Claude Code n’a pas.

Puis-je utiliser Hermes avec une clé API Anthropic ?

Oui. Trois façons :[^2]

1. Définissez ANTHROPIC_API_KEY dans ~/.hermes/.env et exécutez hermes chat --provider anthropic --model claude-sonnet-4-6
2. Exécutez hermes model et sélectionnez Anthropic — Hermes utilisera le magasin d’identifiants de Claude Code lorsqu’il est disponible
3. Définissez un ANTHROPIC_TOKEN manuel (setup-token ou jeton OAuth) en repli

L’option 2 est à privilégier si vous utilisez déjà Claude Code sur la même machine — elle conserve les identifiants Claude rafraîchissables.

Comment changer de fournisseur sans perdre ma conversation ?

Utilisez /model provider:model à l’intérieur d’une session. L’historique de conversation, la mémoire et les skills sont tous conservés :[^10]

/model zai:glm-5
/model openrouter:anthropic/claude-sonnet-4
/model custom:local:qwen-2.5

J’ai configuré Anthropic mais la vision/le web/la compression ne fonctionnent pas

Vous touchez au repli du modèle auxiliaire. La vision, la synthèse web, la compression et d’autres tâches secondaires utilisent un LLM auxiliaire distinct — par défaut Gemini Flash via détection automatique (OpenRouter → Nous → Codex). Si aucun de ces fournisseurs n’est configuré et que vous n’avez paramétré que Anthropic, ces fonctionnalités se dégradent silencieusement.[^4]

Correctif : soit ajoutez une OPENROUTER_API_KEY pour les tâches auxiliaires, soit reconfigurez les emplacements auxiliaires pour utiliser votre fournisseur principal. Notez que la compression de contexte vit dans son propre bloc compression: de niveau supérieur et prend summary_provider, pas auxiliary.compression.provider — l’emplacement auxiliary.compression n’expose qu’un timeout. Correctif complet :

auxiliary:
  vision:      { provider: "main" }
  web_extract: { provider: "main" }

compression:
  summary_provider: "main"

Quelle est la différence entre SOUL.md et AGENTS.md ?

SOUL.md est l’identité de votre agent — ton, style, valeurs par défaut de communication. Il vit dans ~/.hermes/SOUL.md et vous suit partout. AGENTS.md est spécifique au projet — architecture, conventions, commandes, chemins — et vit dans votre répertoire de projet.[^14] Si cela doit vous suivre partout, SOUL.md. Si cela appartient à un projet, AGENTS.md.

Comment exécuter plusieurs instances Hermes côte à côte ?

Les profiles. Chaque profile dispose de son propre HERMES_HOME, configuration, mémoire, sessions et PID de gateway :[^7]

hermes profile create work --clone
hermes profile use work                 # Sticky default
hermes -p work chat -q "..."            # One-off without switching
hermes profile alias work --name h-work # Wrapper script

Hermes prend-il en charge les LLM locaux ?

Oui, via le chemin d’endpoint personnalisé. Hermes fonctionne avec tout serveur compatible OpenAI : Ollama, vLLM, SGLang, llama.cpp/llama-server, LM Studio, LocalAI, Jan, ou le vôtre.[^2] Voir Custom & Self-Hosted Endpoints pour la configuration par serveur.

Pourquoi ma bannière de démarrage affiche-t-elle moins d’outils que ce que le guide indique pour Hermes ?

Le guide cite 47 outils / 20 toolsets depuis le registre d’architecture amont — c’est le total des outils dont Hermes embarque le code source à travers tous les toolsets. Votre installation en cours d’exécution affiche un nombre plus petit dans la bannière (l’installation de référence utilisée pour ce guide rapporte 28 outils) parce que Hermes n’active que l’ensemble de toolsets par défaut au démarrage. De nombreux toolsets sont opt-in : les adaptateurs de la passerelle de messagerie, l’automatisation de navigateur, les piles de scraping plus lourdes et plusieurs intégrations spécialisées doivent être explicitement listés sous toolsets: dans ~/.hermes/config.yaml avant d’être chargés. Total du registre = « ce qui est disponible si vous l’activez ». Total de la bannière = « ce que votre profile actuel a réellement chargé ». Utilisez hermes tools --list pour voir quels toolsets sont actifs et lesquels sont disponibles mais désactivés. Activez ou désactivez des toolsets individuels à l’exécution avec /tools enable <name> et /tools disable <name> (la désactivation déclenche une réinitialisation de session afin que l’agent reconstruise son manifeste d’outils avec la nouvelle forme).

Comment Hermes gère-t-il le repli de modèle lorsque mon fournisseur principal échoue ?

Configurez un bloc fallback_model dans config.yaml :[^2]

fallback_model:
  provider: openrouter
  model: anthropic/claude-sonnet-4

Lorsque le principal échoue (limite de débit, erreur serveur, échec d’authentification), Hermes bascule vers le repli en cours de session sans perdre l’historique de conversation. Se déclenche au plus une fois par session.

L’agent peut-il améliorer ses propres skills au fil du temps ?

Oui — c’est la partie « auto-amélioration » de Hermes Agent. L’agent peut créer, mettre à jour et supprimer des skills via l’outil skill_manage. Lorsqu’il identifie un workflow non trivial, il enregistre l’approche en tant que skill pour une réutilisation future.[^12] L’agent crée des skills après des tâches complexes (5+ appels d’outils), lorsqu’il rencontre des erreurs et trouve le chemin qui fonctionne, lorsque vous corrigez son approche, ou lorsqu’il découvre un workflow non trivial.

Existe-t-il une intégration IDE ?

Oui — Hermes peut s’exécuter en tant que serveur ACP (Agent Client Protocol) pour VS Code, Zed et JetBrains :[^7]

pip install -e '.[acp]'
hermes acp

Journal des modifications

Références

[^1] : Nous Research, « Hermes Agent », README du projet sur GitHub. Source principale pour la description du produit (agent auto-améliorant, multi-fournisseur, passerelle de messagerie, backends de terminal, évolution des skills, planificateur cron, délégation) et la commande « Quick Install » en une ligne.

[^2] : Nous Research, « AI Providers » dans la documentation Hermes Agent. Source principale pour la liste complète des fournisseurs, les méthodes d’authentification par fournisseur (Nous Portal OAuth, code d’appareil Codex, types de jetons Copilot GitHub, authentification à trois méthodes Anthropic, fournisseurs d’IA chinois, routage Hugging Face, points de terminaison personnalisés), les trois chemins d’authentification (clé API dans .env, OAuth via hermes model, point de terminaison personnalisé dans config.yaml), la syntaxe de la commande slash /model (y compris custom:name:model), les modèles de configuration Ollama/vLLM/SGLang/llama.cpp/LM Studio, les instructions réseau WSL2, la chaîne de détection de longueur de contexte, la configuration du modèle de repli, le routage intelligent des modèles et les fournisseurs personnalisés nommés. Tous les noms de variables d’environnement spécifiques aux fournisseurs, types de jetons, remplacements d’URL de base et identifiants de modèles dans cet article proviennent de cette page.

[^3] : Nous Research, « Architecture » dans le guide développeur Hermes Agent. Source principale pour le schéma d’aperçu du système, la structure des dossiers, le flux de données à travers la session CLI et les chemins de messages de la passerelle, les trois modes API (chat_completions, codex_responses, anthropic_messages), la résolution des fournisseurs via runtime_provider.py, la persistance de session via SQLite + FTS5, la liste des plateformes de la passerelle de messagerie, les sources de découverte du système de plugins, l’isolation des profils et les six principes de conception.

[^4] : Nous Research, « Configuration » dans le guide utilisateur Hermes Agent. Source principale pour la structure du dossier de configuration, la règle config.yaml vs .env (« config.yaml l’emporte pour les paramètres non sensibles »), la chaîne de précédence de configuration (arguments CLI → env → config.yaml → .env → valeurs par défaut), les paramètres de compression de contexte (bloc compression.* avec threshold, target_ratio, protect_last_n, summary_model, summary_provider, summary_base_url), les seuils de pression du budget (70 % attention, 90 % avertissement), les délais d’attente de streaming avec ajustement automatique du fournisseur local et le bloc complet de configuration des modèles auxiliaires (auxiliary: avec les emplacements vision, web_extract, approval, compression, session_search, skills_hub, mcp, flush_memories). La restriction du fournisseur "main" aux emplacements auxiliary/compression/fallback provient également de cette page.

[^5] : Nous Research, « Migrate from OpenClaw » dans les guides Hermes Agent. Source pour le flux de migration OpenClaw → Hermes.

[^7] : Nous Research, « CLI Commands Reference » dans la documentation de référence Hermes Agent. Source principale pour chaque commande CLI de niveau supérieur documentée dans cet article, notamment hermes chat, hermes model, hermes gateway, hermes setup, hermes auth, hermes status, hermes cron, hermes webhook, hermes doctor, hermes dump, hermes logs, hermes config, hermes pairing, hermes skills, hermes honcho, hermes memory, hermes acp, hermes mcp, hermes plugins, hermes tools, hermes sessions, hermes insights, hermes claw, hermes profile, hermes completion, hermes update et hermes uninstall. Tous les flags de sous-commandes, descriptions d’options, comportements de pool d’identifiants, syntaxe de filtrage des logs, flags de migration OpenClaw, commandes de gestion de profils et commandes d’installation de service présents dans cet article proviennent de cette page.

[^8] : Nous Research, « Installation » dans le guide de démarrage Hermes Agent. Source principale pour la commande d’installation en une ligne, le comportement de l’installateur (prérequis, prise en charge des plateformes, détection automatique de Termux, exigences Windows/WSL2), le tableau des extras optionnels, les étapes d’installation manuelle et les commandes de vérification.

[^9] : Nous Research, « CLI Commands Reference » — voir spécifiquement la section hermes dump décrivant le format de sortie de la commande (en-tête, environnement, identité, modèle, terminal, clés API, fonctionnalités, services, charge de travail, surcharges de configuration) et son usage prévu pour partager des diagnostics.

[^10] : Nous Research, « Slash Commands Reference » dans la documentation de référence Hermes Agent. Source principale pour chaque commande slash listée dans cet article, l’architecture COMMAND_REGISTRY, la séparation CLI vs messagerie, les commandes slash dynamiques de skills, les commandes rapides dans config.yaml, le comportement de correspondance de préfixe et les commandes uniquement messagerie (/status, /sethome, /approve, /deny, /update, /commands).

[^11] : Nous Research, « Tools & Toolsets » dans le guide utilisateur Hermes Agent. Source principale pour l’aperçu des catégories d’outils, les commandes d’utilisation des toolsets, les six backends de terminal (local, docker, ssh, singularity, modal, daytona), la configuration des conteneurs (cpu, memory, disk, persistent), le durcissement de sécurité pour les conteneurs, la gestion des processus en arrière-plan API et la prise en charge de sudo.

[^12] : Nous Research, « Skills System » dans le guide utilisateur Hermes Agent. Source principale pour la divulgation progressive, le format SKILL.md, les skills spécifiques aux plateformes, l’activation conditionnelle (fallback_for_toolsets, requires_toolsets, fallback_for_tools, requires_tools), les skills gérés par l’agent via skill_manage, les commandes du skill hub et la liste des sources (official, skills-sh, well-known, github, clawhub, claude-marketplace, lobehub), l’analyse de sécurité et les niveaux de confiance, ainsi que les répertoires de skills externes.

[^13] : Nous Research, « Persistent Memory » dans le guide utilisateur Hermes Agent. Source principale pour les limites de caractères de MEMORY.md / USER.md, le modèle d’instantané figé, les actions de l’outil mémoire (add, replace, remove), ce qu’il faut sauvegarder ou ignorer, la comparaison entre mémoire et recherche de session, et la liste des huit fournisseurs de mémoire externes (Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory).

[^14] : Nous Research, « Personality & SOUL.md » dans le guide utilisateur Hermes Agent. Source principale pour le comportement de SOUL.md (réside dans HERMES_HOME, jamais écrasé, emplacement n° 1 dans le prompt système, analysé pour la sécurité avant inclusion), la distinction entre SOUL.md et AGENTS.md, la liste des personnalités intégrées (14 personnalités, de helpful à hype), les personnalités personnalisées dans config.yaml, le modèle de superposition /personality et l’ordre complet d’assemblage de la pile de prompts.

[^15] : Nous Research, « Use MCP with Hermes » et MCP Config Reference dans les guides et la référence Hermes Agent. Source pour le format de configuration mcp_servers: dans config.yaml avec les champs command, args, env.

[^19] : Hermes Agent v0.8.0 Release Notes. 8 avril 2026. Notifications automatiques des processus en arrière-plan, MiMo v2 Pro gratuit sur Nous Portal, basculement /model en direct sur toutes les plateformes, fournisseur natif Google AI Studio, Qwen OAuth, délais d’attente basés sur l’inactivité, boutons d’approbation sur Slack/Telegram, MCP OAuth 2.1 PKCE, journalisation centralisée, expansion du système de plugins.

[^20] : Hermes Agent v0.9.0 Release Notes. 13 avril 2026. Tableau de bord web local, Fast Mode (/fast), iMessage via BlueBubbles, WeChat + WeCom, Termux/Android, surveillance des processus en arrière-plan (watch_patterns), fournisseurs natifs xAI + Xiaomi MiMo, moteur de contexte enfichable, prise en charge unifiée du proxy, durcissement de sécurité (corrections de path traversal, injection shell, SSRF, RCE), hermes backup/hermes import, /debug + hermes debug share, 16 plateformes prises en charge. 487 commits, 269 PR fusionnées, 24 contributeurs.

[^23] : Hermes Agent v0.12.0 Release Notes. 30 avril 2026. « The Curator release. » Curator autonome en arrière-plan qui note, élague et consolide la bibliothèque de skills sur un cycle par défaut de 7 jours s’exécutant sur le ticker cron de la passerelle. Boucle d’auto-amélioration mise à niveau : notation basée sur une grille, biais de mise à jour active, héritage runtime correct, toolsets restreints en portée à la mémoire et aux skills. Quatre nouveaux fournisseurs d’inférence : GMI Cloud, Azure AI Foundry, MiniMax OAuth, Tencent Tokenhub. LM Studio promu en première classe. Les manifestes du catalogue de modèles distants se mettent à jour automatiquement sans nouvelles versions. Deux nouvelles plateformes de messagerie : Microsoft Teams (19e, via une architecture de passerelle enfichable) et Tencent Yuanbao (18e, texte natif + médias). Spotify natif via PKCE OAuth avec skill intégré ; plugin Google Meet pour appels et transcription ; fournisseur TTS local Piper. ComfyUI v5 + TouchDesigner-MCP intégrés par défaut. Nouveaux skills : Humanizer, claude-design, design-md, airtable. CLI : mode one-shot hermes -z, contrôle préalable hermes update --check, commande slash /reload-skills, styles d’indicateur d’activité enfichables. Démarrage à froid du TUI réduit d’environ 57 % grâce à l’initialisation paresseuse. Sécurité : rédaction des secrets désactivée par défaut ; liste de blocage stricte pour les commandes irrécupérables. Statistiques depuis v0.11.0 : 1 096 commits, 550 PR fusionnées, 213 contributeurs de la communauté. Voir aussi : v2026.4.30 release tag.

[^24] : Hermes Agent v0.13.0 Release Notes. 7 mai 2026. « The Tenacity release. » Tableau Kanban multi-agents avec heartbeat, reclaim, détection des zombies, contrôle anti-hallucination, max_retries par tâche, tableaux multi-projets. Commande slash /goal pour le verrouillage d’objectif transversal aux tours (primitive de boucle Ralph) avec budget de tours configurable. Outil video_analyze, Gemini en priorité avec extensibilité multimodale compatible. Fournisseur TTS xAI Custom Voices avec clonage vocal. Internationalisation en 7 langues : zh-Hans, ja, de, es, fr, uk, tr (CLI + messages de la passerelle ; documentation en zh-Hans uniquement). Google Chat comme 20e plateforme de messagerie via un modèle d’adaptateur enfichable avec hooks de plugin génériques env_enablement_fn / cron_deliver_env_var ; IRC et Microsoft Teams migrés vers le même modèle. ABC ProviderProfile + plugins/model-providers/ pour des fournisseurs tiers enfichables. Reprise automatique de session après redémarrage de la passerelle, /update et rechargements de fichiers source. Réécriture en magasin unique des Checkpoints v2 avec élagage réel, garde-fous disque, sans dépôts shadow orphelins. Huit clôtures de sécurité P0 : rédaction des secrets activée par défaut, contournement DM cross-guild Discord (CVSS 8.1, listes d’autorisation de rôles à portée de guild), WhatsApp rejette par défaut les inconnus + ne répond jamais en chat avec soi-même, TOCTOU à l’enregistrement des identifiants MCP OAuth, TOCTOU sur auth.json CLI dans les écrivains d’identifiants, plancher SSRF sur métadonnées cloud du navigateur en routage hybride, analyse cron des prompts assemblés (y compris contenu des skills) pour injection de prompt, rédaction du contenu des logs hermes debug share au moment de l’envoi. Autres éléments notables : linting post-écriture pour Python/JSON/YAML/TOML, mode watchdog cron no_agent script-only, listes d’autorisation de plateformes sur Slack/Telegram/Mattermost/Matrix/DingTalk, améliorations MCP (transport SSE, transmission OAuth, résultats d’images sous forme de balises MEDIA). Statistiques depuis v0.12.0 : 864 commits, 588 PR fusionnées, 829 fichiers modifiés, 295 contributeurs de la communauté, 282 issues fermées (13 P0, 36 P1).

[^22] : Hermes Agent v0.11.0 Release Notes. 23 avril 2026. « The Interface release » — réécriture complète React/Ink du CLI interactif avec un backend Python JSON-RPC (tui_gateway) ; architecture de transport enfichable (agent/transports/) ; AWS Bedrock natif via Converse API ; cinq nouveaux chemins d’inférence (NVIDIA NIM, Arcee AI, Step Plan, Google Gemini CLI OAuth, Vercel ai-gateway) ; GPT-5.5 via Codex OAuth ; QQBot comme 17e plateforme de messagerie avec configuration par scan QR ; surface de plugins étendue (commandes slash, dispatch d’outils, blocage d’exécution, transformation des résultats) ; /steer <prompt> pour des nudges d’agent en cours d’exécution qui injectent du contexte après le prochain appel d’outil sans casser le cache de prompt ; hooks shell pour les événements de cycle de vie sans plugins Python ; mode webhook de livraison directe qui transmet les charges utiles directement à un chat de plateforme ; délégation plus intelligente avec rôles d’orchestrateur + profondeur de spawn configurable + coordination de fichiers ; système de plugins de tableau de bord, basculement de thème en direct, i18n, réactivité mobile. Statistiques depuis v0.9.0 : 1 556 commits · 761 PR fusionnées · 1 314 fichiers modifiés · 224 174 insertions · 29 contributeurs de la communauté. Voir aussi : Hermes Agent v0.11.0 GitHub release tag.

[^21] : Hermes Agent v0.10.0 Release Notes. 16 avril 2026. « The Tool Gateway Release. » Intégration du Nous Tool Gateway pour les abonnés Nous Portal payants — accès géré à la recherche web Firecrawl, à la génération d’images FAL / FLUX 2 Pro, au TTS OpenAI et à l’automatisation de navigateur Browser Use sans clés API supplémentaires. Activation par outil via le nouveau champ de configuration use_gateway. Le runtime préfère la passerelle aux clés API directes lorsque les deux sont configurées. Intégration complète avec hermes tools et hermes status. Remplace la variable d’environnement obsolète HERMES_ENABLE_NOUS_MANAGED_TOOLS. Implémentation par @jquesnelle (emozilla). Le CLI Hermes Agent reste sous licence MIT et entièrement open source ; la passerelle est une intégration au produit d’abonnement Portal existant, et non un paywall sur le CLI. Voir aussi : Nous Portal pour les tarifs d’abonnement et l’inscription.