CodexとOpenCodeを使うHermes Agent：4つの認証情報の入口、3つのメーター

Hermes AgentはCodexやOpenCodeに取って代わるものではなく、それらを操作します。Hermesにはcodexとopencodeという2つの同梱スキルがあり、それぞれのCLIをサブプロセスとして起動します。各サブプロセスはHermesのモデルプロバイダーではなく、独自の認証情報で支払います。計画時に重要なのは、1つのワークフローに4つの認証情報の接点、3つの独立したメーター、そしてResponses APIを提供するエンドポイントとのみ通信する2つの接点があるという事実です。

このページで扱うのはNous ResearchによるMITライセンスのエージェントソフトウェア、Hermes Agentです。同じ会社のオープンウェイトモデルファミリーであるHermes 3やHermes 4、同名のJavaScriptエンジン、ラグジュアリー用品ブランドではありません。2026年9月19日にリポジトリを確認したところ、archived: false、MITライセンス、同日付のpushが返されました。最新の公開リリースはHermes Agent v0.21.3で、2026年9月14日にv2026.9.14としてタグ付けされています。エージェント自体の実行料金についてはHermes Agentの料金を参照してください。

Hermes内部で「codex」と呼ばれる3つのもの

この衝突を最初に整理する必要があります。3つすべてが設定に登場し、そのうち大多数の人がhermes codexで意味するものは1つだけだからです。

出典: 同梱のcodexスキル、プロバイダードキュメント、Codex app-serverランタイムのページ。すべて2026年9月19日に確認しました。

コーディングタスクをCodexに委譲する

codexスキルはバージョン1.0.1、MITライセンスで、明記された役割は「OpenAI Codex CLIにコーディングを委譲します（機能、PR）。」です。前提条件は明確です。Codexをnpm install -g @openai/codexでインストールしていること、OpenAI認証をOPENAI_API_KEYまたはCodex OAuthセッションのいずれかで設定していること、gitリポジトリ内で作業を実行すること（Codexは外部での実行を拒否します）、そしてCodexが対話型ターミナルアプリケーションであるため、ターミナル呼び出しにpty=trueが必要です。

起動はバックグラウンド化されたターミナル呼び出しで、codex exec --sandbox workspace-write 'Refactor the auth module'をworkdirとともに実行し、セッションIDを返します。その後、Hermesはセッションをポーリングし、ログを読み取り、submitアクションで承認プロンプトに回答し、問題が起きた場合は終了させます。結果はプロセス出力と、Codexが作業ツリーに残した内容としてメインエージェントに届きます。2つのプロセス間でメモリは共有されません。

このスキルが隠さずに文書化している境界が2つあります。--full-autoは引き続き動作しますが、現在のCLIは代わりに--sandbox workspace-writeを使うよう警告します。また、Hermesのゲートウェイやサービスのコンテキスト、たとえばチャット駆動のエージェントセッションからCodexを呼び出す場合、workspace-writeサンドボックスは、対話型シェルで同じコマンドが動作しても、setting up uid map: Permission deniedのようなbubblewrapまたはユーザーネームスペースのエラーで失敗することがあります。スキル自身が示す対処法は--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に書き込みます。どちらの方法も現行なので、一方に従ったからといって他方が古いわけではありません。

範囲を限定した作業では、スキルは1回の実行を推奨します。opencode run 'Add retry logic to API calls and update tests'を使い、モデルを固定する場合は--model provider/modelを付けます。対話型セッションはpty付きでバックグラウンド化し、poll、log、submitで操作します。スキルが太字で指摘する注意点が1つあります。/exitは送信しないでください。これは有効なOpenCodeコマンドではなく、代わりにエージェント選択ダイアログを開きます。Ctrl+Cまたはkillアクションで終了します。

ここには固有の名称上の注意点があります。npmパッケージopencode-aiは現行の製品です。一方、GitHub組織であるopencode-aiには、2025年9月18日に最後のpushが行われたアーカイブ済みの前身プロジェクトがあります。現在のリポジトリはanomalyco/opencodeであり、sst/opencodeではありません。GitHub APIは旧パスを新しいパスに解決し、sst組織には現在「We've moved to https://github.com/anomalyco」と表示されます。最新リリースはv1.18.31、2026年9月14日です（GitHub REST API、2026年9月19日）。

実際に料金を決める対応関係

これは、各ベンダーが自分の担当する半分しか所有していないため、どちらのドキュメントにも記載されていない部分です。このワークフローには4つの認証情報の接点があり、それぞれ別のファイルで設定されます。4つすべてをサードパーティのエンドポイントに向けられますが、条件は同じではなく、2つのCodexの接点はResponses APIのみを受け付けます。

Hermesは分離を明確に説明しています。Hermes自身のCodex OAuthは~/.hermes/auth.jsonに保存され、スタンドアロンCLIのセッションは~/.codex/auth.jsonに保存されます。ランタイムのページでは、その理由として、トークン更新時に互いが上書きし合うのを避けるため、HermesはCodex CLIとOAuth状態を意図的に共有しないと説明されています。したがって、委譲されたコーディングタスクはHermesのプロバイダー設定を引き継ぎません。~/.codex/config.tomlまたはopencode.jsonを読み取り、同じキーを意図的に指定した場合に限って同じ残高に到達します。これは影響範囲を分離したい場合には利点ですが、1つの残高ですべてを賄えると考えていた場合には予想外の結果になります。

app-serverランタイムによる変更

Codex app-serverランタイムを有効にすると、切り替える前に知っておくべき計算上の変更が3つあります。openai/*、openai-codex/*、名前付きカスタムプロバイダーのターンをルーティングします。機能表では、その他のOpenAI以外のプロバイダーを「n/a — codex経由ではルーティングされない」としています。また、ベースURLだけを持つ匿名のprovider: customは、Codexに渡す安定した名前がないため、明示的に対象外です。Hermesの4つのツール、delegate_task、memory、session_search、todoは利用できなくなります。これらは実行中のエージェントループを必要とし、ステートレスなコールバックでは操作できないためです。そして多くの人が見落とす料金面の注意点があります。openai-codexプロバイダーでは、補助タスクもデフォルトでChatGPTサブスクリプション経由になります。タイトル生成、コンテキスト圧縮、ビジョン自動検出、バックグラウンドの自己改善レビューの分岐が該当します。タスクごとの上書きが設定されていない場合、Hermesの補助クライアントはメインプロバイダーを使用するためです。

このランタイムでもサードパーティのエンドポイントは排除されませんが、設定ファイルがもう1つ必要になります。ランタイムのページには次の方式が記載されています。~/.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自身のエントリを使います。同じページには、2つの名前が完全一致しない場合、CodexはHermesのエンドポイントにフォールバックせず、unknown providerを報告するという注意点もあります。デフォルトランタイム（openai_runtime: auto）でcustom:プロバイダーを使う方が簡単で、エンドポイントにResponsesを話すことを要求しない唯一の方式です。なお、HermesはアクティブなHermesプロファイルにかかわらずCodexサブプロセスを~/.codex/に向けるため、hermes -p workとhermes -p personalは、CODEX_HOMEを設定して再ログインしない限り、1つのCodex認証を共有します。

3つすべての公開接点を1つのエンドポイントに向ける

以下の各項目はすべてベンダーのソース文書から読み取ったもので、実行時テストは行っていません。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

Hermes自身のターンについてはtransportがすべてです。Kunavoは/v1/chat/completions、/v1/messages、/v1/responsesを提供しているため、Hermesの3つのトランスポート値それぞれに対応するエンドポイントがあります。これは文書上の一致であり、テスト済みの一致ではありません。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では、ワイヤープロトコルのenumにResponsesというバリアントが1つだけあります。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 のドキュメントからの 推論 です。スキルは単純なサブプロセスのシェル呼び出しなので、尊重するはずですが、Hermes の文書にその記載はなく、私たちも実行していません。

3つのメーターをまたいだ試算

これらは 実測したタスクコストでも請求上限でもなく、トークン数に基づく例示的な計算 です。負荷の高い日を1日想定します。オーケストレーターとその補助スロットには キャッシュされていない入力トークン1,500,000個と出力トークン80,000個 が渡され、委譲された各コーディングワーカーには 入力トークン2,000,000個と出力トークン120,000個 が渡されるものとします。これらの比率は説明のための仮定です。料金は100万トークンあたりの現在の Kunavo カタログ価格です。

これらの仮定では、3つの役割すべてを Claude Sonnet 4.6 モデルで実行すると、1日あたり $14.91 になります。一方、オーケストレーターとその補助トラフィックを Claude Haiku 4.5 に割り当て、2つのコーディングワーカーを Claude Sonnet 4.6 モデルのままにすると、$12.25 になります。この差が役割ごとにモデルを選択する根拠であり、上記の認証情報マップが重要である理由でもあります。コーディングワーカーが別々のアカウントに割り当てられている場合、この計算は1回ではなく、3つのメーターに対して3回行う必要があります。

Kunavo のカタログ金額は上限ではなく請求の下限です。上流サービスが料金を報告した場合、請求額はカタログコストと、上流コストに適用されるマークアップを乗じた金額のうち大きい方になります。キャッシュ料金と外部ツールの料金はこの例の対象外です。前払いクレジットの最低チャージ額は $10 です。これはタスク料金やサブスクリプションではなく、資金投入の最低額です。詳しくは 請求の詳細 を参照してください。

どの資金調達方法が有利か

よくある説明について、2点訂正します。「Codexは月額$20」と「Codexはトークン単位の従量課金」は、どちらも同じ点で誤っています。learn.chatgpt.com（2026年9月19日閲覧）では、2つの選択肢が説明されています。Free、Go、Plus、Pro、Business、Enterprise & EduというChatGPTプランに含まれる利用枠でCodexを使うか、または、サブスクリプション契約を必要とせず、標準のAPI料金で課金されるAPIキーを使うかです。そもそもサードパーティのエンドポイントで代替できるのは、後者の場合だけです。プランごとのメッセージ利用枠は、意図的に掲載していません。そのページには、メッセージ数はモデルとタスクの規模によって変わると記載されており、私たちもレンダリングされたHTMLではなく、要約ツールを通じて内容を確認したためです。ご自身のアカウントで確認してください。一方、OpenCode Zenは、「完全に任意であり、OpenCodeを使うために利用する必要はない」と明記しています。クレジット残高からリクエストごとに料金が差し引かれ、デフォルトでは残高が$5を下回ると$20が自動チャージされます。これは、自分でチャージする前払い残高とは、コスト管理上の実質的な違いです。

設定してから、3つすべてのメーターを確認する

実際に必要な入口から始めてください。Kunavo は2つのコーディングワーカー向けにセットアップ手順を公開しています。Codex CLI は Responses 専用のプロバイダーブロックを扱い、OpenCode はワイヤ形式を決定する npm パッケージの選択を扱います。まず範囲を限定した委譲を1回実行し、その処理について各アカウントが記録した料金を、Hermes の /usage、opencode stats --days 7、および Codex ワーカー自身のアカウントで確認してください。確認するまでは、3つの数値のいずれかが他の料金も含んでいると決めつけないでください。キーに資金を投入する準備ができたら、Kunavo アカウントを作成してください。

2つのコーディングワーカーを接続するのではなく比較したい場合は、OpenCode と Codex の比較がその疑問を直接扱い、OpenAI 互換 APIが2つのワイヤ形式の実際の意味を説明します。

よくある質問

2026年9月19日に確認：そのリポジトリにある Hermes Agent の codex および opencode スキルファイル、Codex の app-server ランタイムおよびプロバイダードキュメント、openai/codex の codex-rs/model-provider-info/src/lib.rs、developers.openai.com からの308リダイレクトを含む learn.chatgpt.com の料金および設定リファレンス、opencode.ai のプロバイダーおよび Zen ページ、ならびに GitHub REST API を通じた4つすべてのプロジェクトのリポジトリ状態を確認しました。確認していないもの：これらの実際の動作。Hermes のセッション、codex exec、opencode run、これらのツールから Kunavo のエンドポイントへのリクエストはいずれも実行していません。また、プランごとのメッセージ利用枠と Zen のモデル料金は、これら2つのページを要約ツール経由で読んだため、意図的に省略しています。Kunavo のトークン料金は現在のカタログに基づいており、ここに記載するドル金額はすべて例示的なトークン計算です。