使用 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」，而沒有穩定名稱、只有基本 base 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 日查閱）描述了兩條分支——ChatGPT 方案 Free、Go、Plus、Pro、Business 及 Enterprise & Edu，其額度涵蓋 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 權杖費率來自目前的目錄；此處每個美元數字都是說明性的權杖算術。