Hermes Agent avec Codex et OpenCode : quatre surfaces d’identifiants, trois compteurs

Hermes Agent ne remplace ni Codex ni OpenCode — il les pilote. Hermes fournit deux compétences intégrées, codex et opencode, qui lancent chaque CLI comme un sous-processus, et chaque sous-processus paie avec son propre identifiant plutôt qu’avec le fournisseur de modèles d’Hermes. C’est le fait à prendre en compte : un workflow, quatre surfaces d’identifiants, trois compteurs distincts et deux surfaces qui ne communiqueront qu’avec un endpoint fournissant l’API Responses.

Cette page concerne Hermes Agent, le logiciel agent sous licence MIT de Nous Research — et non Hermes 3 ou Hermes 4, la famille de modèles open-weight de la même entreprise, ni le moteur JavaScript du même nom, ni la marque de produits de luxe. Une vérification en direct du dépôt le 19 septembre 2026 a renvoyé archived: false, une licence MIT et une mise à jour ce jour-là ; la dernière version publiée est Hermes Agent v0.21.3, étiquetée v2026.9.14 le 14 septembre 2026. Pour connaître le coût d’exécution de l’agent lui-même, consultez les tarifs d’Hermes Agent.

Trois éléments appelés « codex » dans Hermes

La collision est le premier point à régler, car les trois apparaissent dans la configuration et un seul correspond à ce que la plupart des gens entendent par hermes codex.

Sources : la compétence codex intégrée, la documentation des fournisseurs et la page du runtime du serveur d’application Codex, toutes consultées le 19 septembre 2026.

Déléguer une tâche de programmation à Codex

La compétence codex est en version 1.0.1, sous licence MIT, et sa fonction déclarée est « Delegate coding to OpenAI Codex CLI (features, PRs). » Ses prérequis sont explicites : Codex installé avec npm install -g @openai/codex ; authentification OpenAI configurée via OPENAI_API_KEY ou une session OAuth Codex ; le travail doit s’exécuter dans un dépôt git, car Codex refuse de s’exécuter en dehors d’un tel dépôt ; et les appels au terminal nécessitent pty=true car Codex est une application de terminal interactive.

Le lancement est un appel de terminal exécuté en arrière-plan — codex exec --sandbox workspace-write 'Refactor the auth module' avec un workdir — qui renvoie un identifiant de session. Hermes interroge ensuite la session, lit son journal, répond aux invites d’approbation avec une action submit et l’arrête en cas de problème. Le résultat parvient à l’agent principal sous forme de sortie du processus, ainsi que de tout ce que Codex a laissé dans l’arborescence de travail ; rien n’est partagé en mémoire entre les deux processus.

La compétence documente deux limites au lieu de les dissimuler. --full-auto fonctionne toujours, mais le CLI actuel recommande désormais d’utiliser --sandbox workspace-write à la place. Et lorsque Codex est appelé depuis une passerelle ou un contexte de service Hermes — par exemple une session d’agent pilotée par chat — le sandboxing workspace-write peut échouer même si la commande identique fonctionne dans un shell interactif, avec des erreurs bubblewrap ou d’espace de noms utilisateur telles que setting up uid map: Permission denied. Le remède proposé par la compétence elle-même est --sandbox danger-full-access, qui supprime entièrement le sandbox Codex ; si vous l’utilisez, la limite du processus dans lequel vous exécutez Hermes devient le seul confinement restant.

Déléguer une tâche de programmation à OpenCode

La compétence opencode est en version 1.2.0, sous licence MIT, et est décrite comme « Delegate coding to OpenCode CLI (features, PR review). » Installez-la avec npm i -g opencode-ai@latest ou brew install anomalyco/tap/opencode, puis opencode auth login et vérifiez avec opencode auth list. La documentation propre à OpenCode propose également la commande /connect dans l’interface de terminal, qui écrit les identifiants dans ~/.local/share/opencode/auth.json — les deux méthodes sont actuelles ; suivre l’une ne signifie donc pas que l’autre est obsolète.

Pour les tâches limitées, la compétence privilégie une exécution unique : opencode run 'Add retry logic to API calls and update tests', avec --model provider/model pour épingler un modèle. Les sessions interactives sont exécutées en arrière-plan avec un pty et pilotées avec poll, log et submit. Un piège est signalé en gras dans la compétence : n’envoyez pas /exit — ce n’est pas une commande OpenCode valide et cela ouvre à la place une boîte de dialogue de sélection d’agent. Quittez avec Ctrl+C ou une action kill.

La nomenclature comporte ici son propre piège actuel. Le package npm opencode-ai est le produit actuel ; l’organisation GitHub nommée opencode-ai contient le prédécesseur archivé, mis à jour pour la dernière fois le 18 septembre 2025. Le dépôt actuel est anomalyco/opencode, et non sst/opencode — l’API GitHub redirige l’ancien chemin vers le nouveau, et l’organisation sst affiche désormais « We've moved to https://github.com/anomalyco ». Dernière version v1.18.31, 14 septembre 2026 (API REST GitHub, 19 septembre 2026).

La carte qui détermine réellement votre facture

C’est la partie que la documentation d’aucun des deux fournisseurs ne couvre, car chacun ne contrôle que sa moitié. Ce workflow comporte quatre surfaces d’identifiants, chacune configurée dans un fichier différent. Les quatre peuvent être dirigées vers un endpoint tiers — mais selon des conditions différentes, et les deux surfaces Codex n’acceptent que l’API Responses.

Hermes énonce clairement la séparation : son propre OAuth Codex se trouve dans ~/.hermes/auth.json, tandis que la session du CLI autonome se trouve dans ~/.codex/auth.json, et la page du runtime en donne la raison — Hermes ne partagera volontairement pas l’état OAuth avec le CLI Codex, afin d’éviter que les deux ne s’écrasent mutuellement lors du renouvellement du jeton. Une tâche de programmation déléguée n’hérite donc pas de la configuration du fournisseur d’Hermes ; elle lit ~/.codex/config.toml ou opencode.json, et utilise le même solde uniquement si vous la dirigez volontairement vers la même clé. C’est un avantage lorsque vous souhaitez isoler le rayon d’impact, et une surprise si vous pensiez qu’un seul solde couvrait tout.

Ce que le runtime du serveur d’application modifie

Si vous activez le runtime du serveur d’application Codex, le calcul change de trois façons qu’il est utile de connaître avant de l’activer. Il achemine les tours openai/*, openai-codex/* et les tours de fournisseurs personnalisés nommés ; son tableau des fonctionnalités marque les autres fournisseurs non OpenAI comme « n/a — not routed through codex », et un provider: custom anonyme avec une simple URL de base n’est explicitement pas éligible, car il n’existe aucun nom stable à transmettre à Codex. Quatre outils Hermes cessent d’être disponibles avec ce runtime — delegate_task, memory, session_search et todo — car ils nécessitent la boucle d’agent en cours d’exécution et un callback sans état ne peut pas les piloter. Enfin, le poste de coût que la plupart des utilisateurs manquent : avec le fournisseur openai-codex, les tâches auxiliaires passent également par défaut par votre abonnement ChatGPT — génération du titre, compression du contexte, détection automatique de la vision et branche de révision d’auto-amélioration en arrière-plan — car le client auxiliaire d’Hermes utilise le fournisseur principal lorsqu’aucune surcharge par tâche n’est définie.

Un endpoint tiers n’est pas exclu de ce runtime, mais il vous faut un second fichier de configuration. La page du runtime documente la procédure : une entrée providers.<name> dans ~/.hermes/config.yaml avec openai_runtime: codex_app_server, plus une table [model_providers.<name>] du même nom dans ~/.codex/config.toml contenant base_url, env_key et wire_api = "responses". Hermes envoie uniquement le modèle et le nom du fournisseur au démarrage du fil et ne transmet jamais la clé ; cette variable d’environnement doit donc être présente dans le processus qui exécute Hermes ; les appels auxiliaires continuent d’utiliser la propre entrée d’Hermes pour ce fournisseur. Une réserve indiquée sur la même page : les deux noms doivent correspondre exactement, sinon Codex signale un fournisseur inconnu au lieu de revenir à l’endpoint Hermes. Conserver le runtime par défaut (openai_runtime: auto) avec un fournisseur custom: reste la solution la plus simple, et la seule qui n’exige pas que l’endpoint parle Responses. Notez également qu’Hermes dirige le sous-processus Codex vers ~/.codex/ quel que soit le profil Hermes actif ; hermes -p work et hermes -p personal partagent donc une même authentification Codex, sauf si vous définissez CODEX_HOME et vous reconnectez.

Diriger les trois surfaces ouvertes vers un même endpoint

Chaque bloc ci-dessous est lu dans les documents sources des fournisseurs, et non testé à l’exécution. Kunavo n’a exécuté ni session Hermes, ni codex exec, ni opencode run contre son endpoint, et un guide de configuration publié constitue une référence de configuration plutôt qu’un test de compatibilité. Conservez une méthode fonctionnelle à disposition pendant vos essais.

# Surface 1: Hermes' own turns.
providers:
  kunavo:
    api: https://api.kunavo.com/v1     # aliases: base_url, url
    key_env: KUNAVO_API_KEY
    transport: chat_completions        # set it explicitly; auto-detection is only a fallback

model:
  default: claude-sonnet-4-6
  provider: custom:kunavo

transport résume toute l’histoire pour les propres tours d’Hermes. Kunavo fournit /v1/chat/completions, /v1/messages et /v1/responses ; chacune des trois valeurs de transport d’Hermes possède donc un endpoint correspondant — une correspondance au niveau de la documentation, pas une correspondance testée. La documentation des fournisseurs Hermes indique que la détection automatique fondée sur l’URL n’intervient qu’en secours lorsque le champ est vide ; définissez-le donc. Changez de modèle en cours de session avec /model custom:kunavo:<model-id>.

# Surface 2: the delegated Codex CLI. Keep this OUTSIDE Hermes' managed block.
model = "claude-sonnet-4-6"
model_provider = "kunavo"

[model_providers.kunavo]
name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
env_key = "KUNAVO_API_KEY"   # the NAME of the variable, not the key itself
# wire_api defaults to "responses", and "responses" is the only value that parses.
# Leave requires_openai_auth unset: true sends Codex to auth.json instead of env_key.

La moitié Codex constitue un contrôle bloquant, et il vaut la peine de l’examiner au niveau de la source plutôt que de l’accepter sur parole. Dans codex-rs/model-provider-info/src/lib.rs, consulté le 19 septembre 2026, l’énumération du protocole filaire ne comporte exactement qu’une variante : Responses. Définir wire_api = "chat" est désormais une erreur de configuration bloquante, dont le message vous indique de définir responses à la place. Une passerelle qui ne parle que Chat Completions ne peut pas être un fournisseur Codex. La référence actuelle des clés se trouve sur learn.chatgpt.com — toute référence citant encore developers.openai.com/codex/… correspond à une redirection 308, ce que nous avons confirmé le même jour.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": { "claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" } }
    }
  }
}

Pour OpenCode, le paquet npm détermine le format filaire : @ai-sdk/openai-compatible appelle /chat/completions, tandis que @ai-sdk/openai appelle /responses. Nommez celui qui correspond au chemin réellement exposé par votre point de terminaison ; la documentation ne décrit pas le mode d’échec lié au nommage de l’autre, et nous ne l’avons pas testé. La question de savoir si les compétences intégrées respectent un fournisseur personnalisé configuré de cette manière est une inférence tirée de la documentation du sous-CLI — les compétences ne sont que de simples appels à des sous-processus shell, donc elles devraient le faire — mais aucun document Hermes ne l’affirme et nous ne l’avons pas exécuté.

Estimation détaillée utilisant les trois compteurs

Il s’agit d’un calcul illustratif de jetons, et non de coûts de tâches mesurés ni d’un plafond de facturation. Supposons une journée chargée : l’orchestrateur et ses emplacements auxiliaires traitent 1,500,000 jetons d’entrée non mis en cache et 80,000 jetons de sortie, tandis que chaque agent de codage délégué traite 2,000,000 jetons d’entrée et 120,000 jetons de sortie. Ces ratios sont des hypothèses à titre illustratif. Les tarifs correspondent aux prix actuels du catalogue Kunavo par million de jetons.

Dans ces hypothèses, l’exécution des trois rôles sur des modèles Claude Sonnet 4.6 revient à $14.91 pour la journée, tandis que l’orchestrateur et son trafic auxiliaire utilisent Claude Haiku 4.5 et que les deux agents de codage, restés sur des modèles Claude Sonnet 4.6, reviennent à $12.25. Cet écart justifie le choix d’un modèle par rôle et explique également pourquoi la table des identifiants ci-dessus est importante : si les agents de codage utilisent des comptes distincts, ce calcul doit être effectué trois fois, avec trois compteurs, et non une seule fois.

Le montant du catalogue Kunavo constitue un plancher de facturation plutôt qu’un plafond : lorsque le fournisseur amont communique son coût, la facture correspond au plus élevé entre le coût du catalogue et le coût amont multiplié par la majoration applicable. Les frais de cache et les outils externes ne sont pas inclus dans cet exemple. Le rechargement minimal est de $10 de crédit prépayé, ce qui constitue un minimum de financement et non des frais de tâche ou un abonnement — voir les détails de facturation.

Quelle source de financement l’emporte lorsque

Deux corrections concernant des formulations courantes. « Codex coûte 20 $ par mois » et « Codex est facturé au jeton » sont toutes deux fausses de la même manière : learn.chatgpt.com (consulté le 19 septembre 2026) décrit un choix entre les forfaits ChatGPT nommés Free, Go, Plus, Pro, Business et Enterprise & Edu, dont les quotas couvrent l’utilisation de Codex, ou une clé API facturée aux tarifs API standard, sans abonnement requis. Seule la seconde branche permet de remplacer un point de terminaison tiers. Nous omettons volontairement les quotas de messages par forfait : cette page indique que leur nombre dépend du modèle et de la taille de vos tâches, et notre lecture s’est faite au moyen d’un résumeur plutôt qu’à partir du HTML rendu. Vérifiez votre propre compte. À l’inverse, OpenCode Zen précise qu’il est « complètement facultatif et que vous n’avez pas besoin de l’utiliser pour utiliser OpenCode », facture chaque requête à partir d’un solde de crédits et recharge par défaut 20 $ lorsque le solde passe sous 5 $ — une différence réelle de contrôle des coûts par rapport à un solde prépayé que vous rechargez vous-même.

Configurez-le, puis consultez les trois compteurs

Commencez par la surface dont vous avez réellement besoin. Kunavo publie des références de configuration pour les deux agents de codage : Codex CLI couvre le bloc de fournisseur réservé à Responses, tandis que OpenCode couvre le choix du paquet npm qui détermine le format filaire. Effectuez une délégation limitée, puis consultez le coût enregistré par chaque compte — /usage, opencode stats --days 7 et le propre compte de l’agent Codex — avant de supposer que l’un des trois nombres couvre les autres. Créez un compte Kunavo lorsque vous êtes prêt à financer une clé.

Vous comparez les deux agents de codage plutôt que de les relier ? OpenCode vs Codex répond directement à cette question, et API compatible avec OpenAI explique concrètement la signification des deux formats filaires.

Questions fréquentes

Vérifié le 19 septembre 2026 : les fichiers de compétences codex et opencode de Hermes Agent, ainsi que le runtime app-server et les documents de fournisseurs de Codex dans ce dépôt ; codex-rs/model-provider-info/src/lib.rs dans openai/codex ; les références de tarification et de configuration de learn.chatgpt.com, y compris les redirections 308 depuis developers.openai.com ; les pages de fournisseurs et de Zen d’opencode.ai ; et l’état des dépôts des quatre projets via l’API REST GitHub. Non vérifié : l’exécution de tout cela. Aucune session Hermes, aucune exécution codex, aucune exécution opencode et aucune requête de ces outils vers le point de terminaison Kunavo n’ont été effectuées, et les quotas de messages par forfait ainsi que les tarifs des modèles Zen sont volontairement omis, car notre lecture de ces deux pages s’est faite au moyen d’un résumeur. Les tarifs des jetons Kunavo proviennent du catalogue actuel ; chaque montant en dollars présenté ici est un calcul illustratif de jetons.