使用 Codex 和 OpenCode 的 Hermes Agent：四个凭据界面，三个计量器

Hermes Agent 不会取代 Codex 或 OpenCode——它会驱动它们。Hermes 附带两个内置技能 codex 和 opencode，分别将各 CLI 作为子进程启动，每个子进程使用自己的凭据付费，而不是使用 Hermes 的模型提供商。这是规划时值得注意的事实：一个工作流、四个凭据界面、三个独立计量器，以及两个只能与提供 Responses API 的端点通信的界面。

此页面介绍的是来自 Nous Research、采用 MIT 许可证的代理软件 Hermes Agent——不是 Hermes 3 或 Hermes 4（同一公司的开放权重模型系列），不是同名的 JavaScript 引擎，也不是奢侈品品牌。2026 年 9 月 19 日对该仓库进行实时检查，返回了 archived: false、MIT 许可证以及当天的推送记录；最新发布的版本是Hermes Agent v0.21.3，于 2026 年 9 月 14 日标记为 v2026.9.14。有关代理自身的运行成本，请参阅 Hermes Agent 定价。

Hermes 内部三个名为“codex”的事物

首先需要解决名称冲突，因为三者都出现在配置中，而其中只有一个是大多数人所说的 hermes codex。

来源：内置的 codex 技能、提供商文档和 Codex app-server 运行时页面，均于 2026 年 9 月 19 日读取。

将编码任务委派给 Codex

codex 技能的版本为 1.0.1，采用 MIT 许可证，其声明的工作是“将编码工作委派给 OpenAI Codex CLI（功能、PR）”。其前置条件很明确：使用 npm install -g @openai/codex 安装 Codex；OpenAI 身份验证必须配置为 OPENAI_API_KEY 或 Codex OAuth 会话之一；工作必须在 git 仓库内运行，因为 Codex 拒绝在仓库外运行；终端调用需要 pty=true，因为 Codex 是交互式终端应用。

启动方式是后台终端调用——codex exec --sandbox workspace-write 'Refactor the auth module' 并指定 workdir——它会返回会话 ID。之后 Hermes 轮询会话、读取日志、使用 submit 操作回答审批提示，并在出错时终止它。结果会以进程输出以及 Codex 留在工作树中的内容传回主代理；两个进程之间不会共享内存。

该技能记录了两个边界，而不是将其隐藏。--full-auto 仍然有效，但当前 CLI 会警告应改用 --sandbox workspace-write。此外，当 Codex 从 Hermes 网关或服务上下文中调用时——例如由聊天驱动的代理会话——workspace-write 沙箱可能会失败，即使相同命令在交互式 shell 中可以正常运行；错误可能来自 bubblewrap 或用户命名空间，例如 setting up uid map: Permission denied。该技能本身给出的解决方法是 --sandbox danger-full-access，它会完全移除 Codex 沙箱；如果采用该方法，运行 Hermes 的进程边界将成为剩下的唯一隔离层。

将编码任务委派给 OpenCode

opencode 技能的版本为 1.2.0，采用 MIT 许可证，其描述为“将编码工作委派给 OpenCode CLI（功能、PR 审查）”。使用 npm i -g opencode-ai@latest 或 brew install anomalyco/tap/opencode 安装，然后运行 opencode auth login 并使用 opencode auth list 验证。OpenCode 自己的文档还提供终端 UI 中的 /connect 命令，该命令会将凭据写入 ~/.local/share/opencode/auth.json——两种路径目前都有效，因此采用其中一种并不意味着另一种已经过时。

对于有界任务，该技能倾向于一次完成：opencode run 'Add retry logic to API calls and update tests'，并使用 --model provider/model 固定模型。交互式会话会在带 pty 的后台运行，并通过 poll、log 和 submit 驱动。技能以粗体指出了一个陷阱：不要发送 /exit——它不是有效的 OpenCode 命令，而是会打开代理选择对话框。使用 Ctrl+C 或 kill 操作退出。

这里的命名本身就有一个容易踩的坑。npm 包 opencode-ai 是当前产品；名为 opencode-ai 的 GitHub 组织 保存着已归档的前身，最后一次推送于 2025 年 9 月 18 日。而当前仓库是 anomalyco/opencode，不是 sst/opencode——GitHub API 会将旧路径解析到新路径，而 sst 组织现在显示“我们已迁移到 https://github.com/anomalyco”。最新版本 v1.18.31，2026 年 9 月 14 日（GitHub REST API，2026 年 9 月 19 日）。

真正决定账单的映射

这是两家供应商的文档都没有涵盖的部分，因为每家只负责其中一半。在此工作流中有四个凭证入口，每个都在不同的文件中配置。四者都可以指向第三方端点——但条件并不相同，而且两个 Codex 入口只接受 Responses API。

Hermes 明确说明了这种分离：它自己的 Codex OAuth 位于 ~/.hermes/auth.json，而独立 CLI 的会话位于 ~/.codex/auth.json；运行时页面还补充了原因——Hermes 有意不与 Codex CLI 共享 OAuth 状态，以避免两者在刷新令牌时相互覆盖。因此，委托的编码任务不会继承 Hermes 的提供商配置；它会读取 ~/.codex/config.toml 或 opencode.json，只有在你有意将其指向同一个密钥时，才会使用同一个余额。这在你希望隔离影响范围时是一个优点，但如果你以为一个余额涵盖所有内容，就会令人意外。

app-server 运行时带来的变化

如果启用 Codex app-server 运行时，在开启之前需要了解计算方式会有三点变化。它会路由 openai/*、openai-codex/* 和 命名的自定义提供商回合；其功能表将其他非 OpenAI 提供商标记为“n/a — not routed through codex”，而使用裸基础 URL 的匿名 provider: custom 明确不符合条件，因为没有稳定名称可交给 Codex。四个 Hermes 工具在此运行时不可用——delegate_task、memory、session_search 和 todo——因为它们需要正在运行的代理循环，而无状态回调无法驱动它们。还有一项大多数人会忽略的成本：对于 openai-codex 提供商，辅助任务默认也会通过你的 ChatGPT 订阅执行——标题生成、上下文压缩、视觉自动检测以及后台自我改进审查分支——因为未设置每项任务的覆盖配置时，Hermes 的辅助客户端会使用主提供商。

第三方端点并未被此运行时排除，但需要再配置一个文件。运行时页面记录了具体路由：在 ~/.hermes/config.yaml 中添加 providers.<name> 条目并设置 openai_runtime: codex_app_server，再在 ~/.codex/config.toml 中添加同名 条目的 [model_providers.<name>] 表，其中包含 base_url、env_key 和 wire_api = "responses"。线程启动时，Hermes 只发送模型和提供商名称，从不转发密钥，因此该环境变量必须存在于运行 Hermes 的进程环境中；辅助调用仍使用 Hermes 自己为该提供商配置的条目。同一页面还说明了一个注意事项：两个名称必须完全匹配，否则 Codex 会报告未知提供商，而不会回退到 Hermes 端点。使用默认运行时（openai_runtime: auto）和 custom: 提供商仍是更简单的路径，也是唯一不要求端点支持 Responses 的路径。还要注意，无论当前启用哪个 Hermes 配置，Hermes 都会将 Codex 子进程指向 ~/.codex/，因此 hermes -p work 和 hermes -p personal 共用一个 Codex 身份验证，除非你设置 CODEX_HOME 并重新登录。

将三个开放入口都指向一个端点

下面每一块内容都来自供应商源文档，而非运行时测试。Kunavo 没有针对其端点执行 Hermes 会话、codex exec 或 opencode run，而已发布的设置指南是配置参考，不是兼容性测试。尝试这些配置时，请保留一条可用的工作路径。

# 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 是 Hermes 自己回合的全部配置。Kunavo 提供 /v1/chat/completions、/v1/messages 和 /v1/responses，因此 Hermes 的三个传输值各自都有匹配的端点——这是文档层面的匹配，并非经过测试的匹配。Hermes 的提供商文档称，基于 URL 的自动检测仅在字段为空时作为回退，因此请设置该字段。使用 /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.

Codex 这一部分有硬性门槛，值得直接查看源代码，而不是仅凭信任接受。在 2026 年 9 月 19 日查阅的 codex-rs/model-provider-info/src/lib.rs 中，通信协议枚举恰好只有一个变体：Responses。设置 wire_api = "chat" 现在会导致硬性配置错误，错误消息会告诉你改为设置 responses。只支持 Chat Completions 的网关根本不能作为 Codex 提供商。当前的配置键参考文档位于 learn.chatgpt.com——任何仍引用 developers.openai.com/codex/… 的链接都会返回 308 重定向，我们在同一天确认了这一点。

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

对于 OpenCode，npm 包决定线路格式：@ai-sdk/openai-compatible 调用 /chat/completions，@ai-sdk/openai 调用 /responses。请选择与你的端点实际提供的路径相匹配的那个；文档没有说明为另一种路径命名时的失败模式，我们也未进行测试。捆绑的技能是否会遵循以这种方式配置的自定义提供商，是根据子 CLI 文档作出的推断——技能只是通过 shell 调用普通子进程，因此应该会遵循——但没有任何 Hermes 文档明确说明这一点，我们也没有运行测试。

跨三个计量器的示例估算

这些是说明性令牌算术，不是实测任务成本，也不是账单上限。假设一天处于繁忙状态：编排器及其辅助槽位接收1,500,000 个未缓存输入令牌和 80,000 个输出令牌，每个委托的编码工作者接收2,000,000 个输入令牌和 120,000 个输出令牌。这些比例仅是用于说明的假设。费率是实时的Kunavo 目录价格，按每百万令牌计。

在这些假设下，如果三个角色都使用 Claude Sonnet 4.6 模型，一天的费用约为 $14.91；如果让编排器及其辅助流量使用 Claude Haiku 4.5，而两个编码工作者都使用 Claude Sonnet 4.6 模型，则约为 $12.25。这一区别正是按角色选择模型的理由，也说明了上面的凭证映射为何重要：如果编码工作者使用不同账户，就必须针对三个计量器分别计算三次，而不是只计算一次。

Kunavo 目录中的金额是计费下限，而不是上限：上游报告费用时，账单取目录成本与上游成本乘以适用加价后的较大值。缓存费用和外部工具不包含在此示例中。最低充值额为预付余额 $10，这是资金最低额，而不是任务费用或订阅——参见 计费详情。

不同情况下哪种资金路径更优

先纠正两种常见说法。“Codex 每月收费 $20”和“Codex 按令牌计费”都犯了同一种错误：learn.chatgpt.com（于 2026 年 9 月 19 日查阅）描述了两条分支——名为 Free、Go、Plus、Pro、Business 和 Enterprise & Edu 的 ChatGPT 套餐，其额度涵盖 Codex 使用；或者使用按标准 API 费率计费、无需订阅的 API 密钥。只有第二条分支才有可能替换为第三方端点。我们有意不列出各套餐的消息额度：该页面说明数量取决于模型和任务规模，而且我们是通过摘要器而非渲染后的 HTML 读取到这些内容的。请查看你自己的账户。另一方面，OpenCode Zen 表示它“完全可选，不使用它也能使用 OpenCode”，按请求从预充值余额中扣费，并且默认在余额低于 $5 时自动充值 $20——这与需要你自行充值的预付余额相比，确实存在成本控制上的差异。

完成设置，然后读取三个计量器

从你实际需要的入口开始。Kunavo 为两个编码工作者都发布了设置参考：Codex CLI涵盖仅支持 Responses 的提供商配置块，OpenCode涵盖决定线路格式的 npm 包选择。执行一次有界委托，然后读取每个账户为其记录的费用——Hermes 的 /usage、opencode stats --days 7 以及 Codex 工作者自己的账户——之后再假设这三个数字中的任何一个涵盖其他数字。准备为密钥充值时，创建 Kunavo 账户。

如果你是在比较两个编码工作者，而不是将它们连接起来？OpenCode 与 Codex 对比会直接回答这个问题，而OpenAI 兼容 API介绍这两种线路格式在实践中的含义。

常见问题

截至 2026 年 9 月 19 日核查：该仓库中的 Hermes Agent codex 和 opencode 技能文件、Codex app-server 运行时及提供商文档；openai/codex 中的 codex-rs/model-provider-info/src/lib.rs；learn.chatgpt.com 的定价和配置参考，包括从 developers.openai.com 发出的 308 重定向；opencode.ai 的提供商和 Zen 页面；以及通过 GitHub REST API 获取的四个项目的仓库状态。未核查：实际运行其中任何内容。没有执行 Hermes 会话、codex exec、opencode run，也没有执行这些工具针对 Kunavo 端点发出的请求；由于我们通过摘要器读取了那两个页面，各套餐消息额度和 Zen 模型费率也有意省略。Kunavo 令牌费率来自实时目录；这里的每个美元数字都是说明性令牌算术。