Hermes Agent with Codex and OpenCode: four credential surfaces, three meters

Hermes Agent does not replace Codex or OpenCode — it drives them. Hermes ships two bundled skills, codex and opencode, that launch each CLI as a subprocess, and each subprocess pays with its own credential rather than with Hermes' model provider. That is the fact worth planning around: one workflow, four credential surfaces, three separate meters, and two surfaces that will only talk to an endpoint serving the Responses API.

This page is about Hermes Agent, the MIT-licensed agent software from Nous Research — not Hermes 3 or Hermes 4, the same company's open-weight model family, not the JavaScript engine of the same name, and not the luxury-goods brand. A live check of the repository on September 19, 2026 returned archived: false, an MIT license and a push that day; the newest published release is Hermes Agent v0.21.3, tagged v2026.9.14 on September 14, 2026. For what the agent itself costs to run, see Hermes Agent pricing.

Three things called "codex" inside Hermes

The collision is the first thing to settle, because all three appear in configuration and only one of them is what most people mean by hermes codex.

Sources: the bundled codex skill, the provider documentation and the Codex app-server runtime page, all read September 19, 2026.

Delegating a coding task to Codex

The codex skill is version 1.0.1, MIT licensed, and its stated job is "Delegate coding to OpenAI Codex CLI (features, PRs)." Its prerequisites are explicit: Codex installed with npm install -g @openai/codex; OpenAI auth configured as either OPENAI_API_KEY or a Codex OAuth session; the work must run inside a git repository, because Codex refuses to run outside one; and terminal calls need pty=true because Codex is an interactive terminal application.

The launch is a backgrounded terminal call — codex exec --sandbox workspace-write 'Refactor the auth module' with a workdir — which returns a session id. From there Hermes polls the session, reads its log, answers approval prompts with a submit action, and kills it if it goes wrong. The result reaches the main agent as process output plus whatever Codex left in the working tree; nothing is shared in memory between the two processes.

Two boundaries the skill documents rather than hides. --full-auto still works but the live CLI now warns to use --sandbox workspace-write instead. And when Codex is invoked from a Hermes gateway or service context — a chat-driven agent session, say — workspace-write sandboxing can fail even though the identical command works in an interactive shell, with bubblewrap or user-namespace errors such as setting up uid map: Permission denied. The skill's own remedy is --sandbox danger-full-access, which removes the Codex sandbox entirely; if you take it, the process boundary you run Hermes in becomes the only containment left.

Delegating a coding task to OpenCode

The opencode skill is version 1.2.0, MIT licensed, described as "Delegate coding to OpenCode CLI (features, PR review)." Install with npm i -g opencode-ai@latest or brew install anomalyco/tap/opencode, then opencode auth login and verify with opencode auth list. OpenCode's own documentation also offers the /connect command inside the terminal UI, which writes credentials to ~/.local/share/opencode/auth.json — both routes are current, so following one does not mean the other is stale.

For bounded work the skill prefers one shot: opencode run 'Add retry logic to API calls and update tests', with --model provider/model to pin a model. Interactive sessions are backgrounded with a pty and driven with poll, log and submit. One trap is called out in the skill in bold: do not send /exit — it is not a valid OpenCode command and opens an agent selector dialog instead. Exit with Ctrl+C or a kill action.

The naming here has a live trap of its own. The npm package opencode-ai is the current product; the GitHub organization named opencode-ai holds the archived predecessor, last pushed September 18, 2025. And the current repository is anomalyco/opencode, not sst/opencode — the GitHub API resolves the old path to the new one, and the sst organization now reads "We've moved to https://github.com/anomalyco". Latest release v1.18.31, September 14, 2026 (GitHub REST API, September 19, 2026).

The map that actually decides your bill

This is the part neither vendor's documentation covers, because each one only owns its half. Four credential surfaces exist in this workflow, each configured in a different file. All four can be pointed at a third-party endpoint — but not on the same terms, and the two Codex surfaces accept only the Responses API.

Hermes states the separation plainly: its own Codex OAuth lives in ~/.hermes/auth.json while the standalone CLI's session lives in ~/.codex/auth.json, and the runtime page adds the reason — Hermes deliberately will not share OAuth state with the Codex CLI, to avoid the two clobbering each other on token refresh. So a delegated coding task does not inherit Hermes' provider configuration; it reads ~/.codex/config.toml or opencode.json, and lands on the same balance only if you deliberately point it at the same key. That is a feature when you want blast-radius isolation and a surprise when you assumed one balance covered everything.

What the app-server runtime changes

If you turn the Codex app-server runtime on, the calculation changes in three ways worth knowing before you flip it. It routes openai/*, openai-codex/* and named custom-provider turns; its feature table marks other non-OpenAI providers "n/a — not routed through codex", and an anonymous provider: custom with a bare base URL is explicitly not eligible, because there is no stable name to hand to Codex. Four Hermes tools stop being available on it — delegate_task, memory, session_search and todo — because they need the running agent loop and a stateless callback cannot drive them. And the cost line most people miss: with the openai-codex provider, auxiliary tasks also flow through your ChatGPT subscription by default — title generation, context compression, vision auto-detect and the background self-improvement review fork — because Hermes' auxiliary client uses the main provider when no per-task override is set.

A third-party endpoint is not shut out on this runtime, but it costs you a second configuration file. The runtime page documents the route: a providers.<name> entry in ~/.hermes/config.yaml with openai_runtime: codex_app_server, plus a [model_providers.<name>] table of the same name in ~/.codex/config.toml carrying base_url, env_key and wire_api = "responses". Hermes sends only the model and the provider name when the thread starts and never forwards the key, so that environment variable has to be present in the process Hermes runs in; auxiliary calls keep using Hermes' own entry for that provider. One caveat the same page states: the two names must match exactly, or Codex reports an unknown provider rather than falling back to the Hermes endpoint. Staying on the default runtime (openai_runtime: auto) with a custom: provider remains the simpler route, and the only one that does not require the endpoint to speak Responses. Note also that Hermes points the Codex subprocess at ~/.codex/ regardless of which Hermes profile is active, so hermes -p work and hermes -p personal share one Codex auth unless you set CODEX_HOME and log in again.

Pointing all three open surfaces at one endpoint

Every block below is read from vendor source documents, not runtime tested. Kunavo has not executed a Hermes session, a codex exec or an opencode run against its endpoint, and a published setup guide is a configuration reference rather than a compatibility test. Keep a working route available while you try these.

# 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 is the whole story for Hermes' own turns. Kunavo serves /v1/chat/completions, /v1/messages and /v1/responses, so each of Hermes' three transport values has a matching endpoint — a documentation-level match, not a tested one. Hermes' provider doc says URL-based auto-detection happens only as a fallback when the field is blank, so set it. Switch mid-session with /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.

The Codex half is a hard gate, and it is worth seeing at source level rather than taking on trust. In codex-rs/model-provider-info/src/lib.rs, read September 19, 2026, the wire-protocol enum has exactly one variant: Responses. Setting wire_api = "chat" is now a hard configuration error whose message tells you to set responses instead. A gateway that speaks only Chat Completions cannot be a Codex provider at all. The current key reference lives at learn.chatgpt.com — anything still citing developers.openai.com/codex/… is a 308 redirect, which we confirmed the same day.

{
  "$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" } }
    }
  }
}

For OpenCode the npm package picks the wire format: @ai-sdk/openai-compatible calls /chat/completions, @ai-sdk/openai calls /responses. Name the one matching the path your endpoint actually serves; the documentation does not describe the failure mode for naming the other, and we did not test it. Whether the bundled skills honour a custom provider configured this way is an inference from the sub-CLI documentation — the skills are plain subprocess shell-outs, so they should — but no Hermes document states it and we did not run it.

A worked estimate across the three meters

These are illustrative token arithmetic, not measured task costs and not a bill ceiling. Assume one busy day: the orchestrator and its auxiliary slots see 1,500,000 uncached input and 80,000 output tokens, and each delegated coding worker sees 2,000,000 input and 120,000 output. Those ratios are assumptions for illustration. Rates are live Kunavo catalog prices per million tokens.

Under these assumptions, running all three roles on Claude Sonnet 4.6 models out at $8.52 for the day, while putting the orchestrator and its auxiliary traffic on Claude Haiku 4.5 and leaving both coding workers on Claude Sonnet 4.6 models out at $7.00. That gap is the argument for per-role model choice, and it is also why the credential map above matters: if the coding workers are on separate accounts, this arithmetic has to be done three times, against three meters, rather than once.

Kunavo's catalog amount is a billing floor rather than a cap: when the upstream reports its charge, the bill is the greater of catalog cost and upstream cost times the applicable markup. Cache charges and external tools sit outside this example. The minimum top-up is $10 in prepaid credit, which is a funding minimum rather than a task fee or a subscription — see billing details.

Which funding route wins when

Two corrections to common framings. "Codex costs $20 a month" and "Codex is pay-per-token" are both wrong in the same way: learn.chatgpt.com (read September 19, 2026) describes a fork — ChatGPT plans named Free, Go, Plus, Pro, Business and Enterprise & Edu whose allowances cover Codex usage, or an API key billed at standard API rates with no subscription required. Only the second branch makes a third-party endpoint substitutable at all. We are deliberately not printing the per-plan message allowances: that page states the number depends on the model and the size of your tasks, and our reading of it came through a summarizer rather than rendered HTML. Check your own account. And on the other side, OpenCode Zen states it is "completely optional and you don't need to use it to use OpenCode", charges per request from a credit balance, and by default reloads $20 when the balance falls below $5 — a real cost-control difference from a prepaid balance you top up yourself.

Set it up, then read all three meters

Start with the surface you actually need. Kunavo publishes setup references for both coding workers: Codex CLI covers the Responses-only provider block, and OpenCode covers the npm-package choice that decides the wire format. Run one bounded delegation, then read the charge each account recorded for it — Hermes' /usage, opencode stats --days 7, and the Codex worker's own account — before you assume any of the three numbers covers the others. Create a Kunavo account when you are ready to fund a key.

Comparing the two coding workers rather than wiring them together? OpenCode vs Codex takes that question directly, and OpenAI-compatible API covers what the two wire formats mean in practice.

FAQ

Checked September 19, 2026: the Hermes Agent codex and opencode skill files and the Codex app-server runtime and provider documents in that repository; codex-rs/model-provider-info/src/lib.rs in openai/codex; learn.chatgpt.com's pricing and configuration reference, including the 308 redirects from developers.openai.com; opencode.ai's provider and Zen pages; and repository state for all four projects through the GitHub REST API. Not checked: any of this running. No Hermes session, no codex exec, no opencode run and no request from any of these tools against Kunavo's endpoint was executed, and per-plan message allowances and Zen model rates are deliberately omitted because our reading of those two pages came through a summarizer. Kunavo token rates come from the live catalog; every dollar figure here is illustrative token arithmetic.