去年の夏、一ヶ月で LLM プロバイダのアカウントを 5 つ開設した。OpenAI、Anthropic、OpenRouter、Fireworks、Together。10 月にはどのクレジットカードがどこに請求されているのかわからなくなっていた。12 月、そのうちの一社が静かに価格を変えて、気付いたのは請求書が届いた三週間後だった。
これが、2026 年に LLM の上で何かを運用することの、地味で正直な現実だ。プロバイダ動物園は一時的な騒ぎではなく、常設の状態だ。新しいモデルが毎週出てくる。価格も動く。無料枠の組み合わせも並べ替えられる。3 月に最先端だったモデルが、5 月には脚注になっている。もしあなたのエージェントフレームワークがインストール時にプロバイダを決め打ちしてくるなら、数ヶ月ごとにセットアップを組み直す契約に署名したのと同じだ。
Hermes Agent は初日から、ここで逆張りをしている。プロバイダは設定値であって、アーキテクチャ側が勝手に決める選択ではない。そしてそれが実際に機能するためには、三つの機能が重なっていく必要がある。
中央ルーター（v0.2.0）
土台にあるのは、呼び出し窓口をひとつに絞ることだ。v0.2.0 のローンチ時にプロジェクトが導入したのが、集中化されたプロバイダルーターだ——エージェントのあらゆる部分が経由する、call_llm() / async_call_llm() というひとつの関数。ビジョン、要約、圧縮、トラジェクトリ保存、メインのチャットループ。全部が同じコードパスを通る。
リファクタリング上の細かい話に聞こえるだろうが、このレイヤーがない別のエージェントでプロバイダを差し替えようとすると、違いがよくわかる。ほとんどのフレームワークでは LLM を叩いている場所が 11 箇所くらいあり、それぞれが微妙に違う方法で認証情報を読んでいる。片方を直してもう片方を忘れ、壊れ方が見つけにくい場所で壊れる。Hermes はそれを「場所をひとつしか作らない」ことで不可能にした。
フォールバックチェーン（v0.6.0）
二週間後、v0.6.0 が次のレイヤーを重ねた——順序付きフォールバックプロバイダチェーンだ。config.yaml にプロバイダを順番に並べておくと、メインのプロバイダがエラー（429 のレートリミット、一時的な 500、到達不能なエンドポイント）に当たったとき、Hermes が自動的にチェーン上の次の候補を試しにいく。
肝心なのは、これがラウンドロビンではなく順序付きだ、という点だ。あなた自身が好みと予備を指定する。よくある構成は、安くてお得な OpenRouter を既定に、Anthropic 直結を信頼できるバックアップに、Nous Portal の無料枠を最後の非常用フォールバックに据える、というものだ。チェーンの先頭が機嫌の悪い日でも、あなた側では気付かない。v0.6.0 はついでに細かいバグもひとつ直した——hermes model でプロバイダを切り替えると api_mode が chat_completions に固定されてしまっていたのが、切り替え時に古い値をクリアするようになったので、Anthropic 互換エンドポイントが切り替え後に謎の 404 を返すこともなくなった。
認証情報プール（v0.7.0）
レジリエンス回である v0.7.0 は三層目を積み上げた——同一プロバイダ内の認証情報プールだ。ここでの核心はこうだ。「自分のメインプロバイダ」と「そのプロバイダで自分が持っている具体的な API キー」は別の話だ、という割り切り。Anthropic のキーを三つ持っているかもしれない——個人用、チーム用、もうひとつの別アカウントのバックアップ——そして Hermes にはその時点で一番暇なキーを選んでほしい。
セットアップウィザードか credential_pool ブロックで宣言すると、Hermes は既定で least_used 戦略でキーを選ぶ。あるキーが 401 を返したら、プールは自動的に次のキーへ回し、壊れた方にクールダウン期間のフラグを立てる。実装はスレッドセーフなので、CLI、Telegram ゲートウェイ、cron ジョブが同じプールを共有しても、互いに踏みつけ合わない。v0.7.0 はさらに、フォールバックプロバイダの切り替えが走ってもプールの状態が生き残るようにしている——メインプロバイダで 429 を食らったときに、「どのキーが疲れているか」というプールの記憶まで一緒に吹き飛んでしまわないようにだ。
なぜこのレイヤリングが効くのか
ここまでの機能は、それぞれ一つの狭い問題しか解いていない。それが合わさって強力に感じるのは、三つが重ならずにきれいに積み上がっているからだ。
- •ルーターのおかげで、どのプロバイダを使うかをひとつの場所で変えられる。
- •フォールバックチェーンのおかげで、再起動せずにプロバイダレベルの障害を処理できる。
- •認証情報プールのおかげで、ひとつのプロバイダの内側でキーレベルの障害と負荷を処理できる。
そして CLI 側から hermes model を叩けば、設定ファイルを手で編集しなくても、これらのどの層も作り直せる。結果として、新しいモデルが出てきたとき——誰が出そうが、何であろうが、どんな値段だろうが——乗り換えのコストは「設定一行を書き換える」になる。「アシスタントを設計し直す」ではない。何世代ものモデルをまたいで生き続けるつもりのプロジェクトにとって、これはおそらく唯一本当に重要なアーキテクチャ判断だ。