v0.14.0 は性能改善の束を出荷した。束ねて見ると、Hermes Agent は別物のプログラムのように動くようになる。リリースノートのヘッドラインは 3 つ：
- •冷起動から約 19 秒削減。 import グラフ、doctor のチェック、モデルカタログ参照、歓迎バナーの各所にまたがる。
- •
browser_consoleが 180 倍速に。 呼び出しごとに新規 DevTools セッションを開く代わりに、永続化された CDP 接続を 1 本持つ。 - •セッション横断で Claude プロンプトキャッシュを 1 時間保持。
/newでも温かい prefix キャッシュを失わない。
このどれもが「ゼロから書き直し」ではない。各々、特定のホットパスを狙った小さく位置付けられた PR の連鎖だ。この記事は PR ごとの分解版——何が遅かったか、何を変えたか、そしてエージェントを書く人なら誰にとっても汎用化する教訓。
出発点
2026 年 5 月の初めに hermes を走らせたとき、冷起動の道筋はこんな感じだった：
- 1.Python インタプリタの起動（約 100 ms）
- 2.
import hermesが残りの import グラフを引っ張り上げる（約 5–10 s） - 3.
hermesのプラグイン探索がインストール済みプラグインを掃く（約 2–3 s） - 4.
hermes doctorが API 接続確認を順次走らせる（約 3–5 s） - 5.skills インデックスのロード、しばしばネットワークから再取得（約 2–4 s）
- 6.歓迎バナーの描画（約 1 s）
- 7.プロンプトが出る
タイプし始められるまでに 15–25 秒。フローを切るのに十分な長さだ。v0.14.0 の性能改善は、その一段一段を攻める。
冷起動の波（10+ PR）
skills キャッシュ ＋ アダプタの lazy import（#22138）
単独で最大の勝利。並行で 2 つの変更：
- 1.skills インデックスをディスクにキャッシュ。 旧挙動：
hermesを起動するたびに skills ディレクトリを読み、軽量索引を再構築。新挙動：索引はキャッシュファイルに住み、ディレクトリが変わったとき（mtime で判定）だけ再構築。 - 2.重量級アダプタ SDK の lazy 化。 以前：
hermesを import すると Feishu SDK、WhatsApp SDK、各 voice/TTS プロバイダ、各画像生成 SDK の import も巻き込まれた。今：それぞれ初回使用まで遅延される。Feishu を使わないなら、Feishu SDK は決してロードされない。
両方とも #22138 内、約 5–8 秒の削減。lazy import パターンは縁の下の主役だ——コードベース全体に機械的に適用され、単独のドラマティックな PR として現れない。
既知サブコマンドではプラグイン探索をスキップ（#22120）
hermes config set X Y を走らせるならプラグイン探索は要らない。hermes tools、hermes model、hermes doctor も同じ。ディスパッチャはコマンドが既知の組み込みのときプラグイン探索を短絡するようになった。大半の CLI 起動で約 2 秒節約。
models.dev を cache-first で参照（#22808）
Hermes は規範的なモデルカタログのために models.dev を叩く。v0.14.0 以前は hermes の起動ごとに HTTP コール。今はディスクキャッシュを先に読み、古い（>24 h）ときだけ再取得。キャッシュヒットは約 5 ms、HTTP 往復の約 200–500 ms と比べてだいぶ違う。
hermes doctor の API 接続確認を並列化（#22766）
hermes doctor は「Nous Portal、OpenRouter、Anthropic、OpenAI に届くか」を順次チェックしていた。今は asyncio.gather でまとめて投げ、クラウド外マシンでタイムアウトしがちな IMDS（instance metadata service）の探索は外した。典型ケースで doctor から約 3–5 秒削減。
chat -q で歓迎バナーをスキップ（#22904）
単発クエリモード（hermes chat -q "what's the time"）では歓迎バナーはノイズだ。v0.14.0 はそのケースで描画をスキップする。スクリプト・自動化用途で約 1 秒戻ってくる。
グラフ全体に散らばる遅延 import
長いテールの PR が、それぞれ 1 つずつ重い import を遅延する：
- •
google_chatアダプタのgoogle-cloud——Google Chat を初めて使うときだけロード（#22681） - •
QQAdapter、YuanbaoAdapter——PEP 562 経由でモジュールレベルの遅延（#22790） - •teams アダプタの
httpx——最初の webhook 呼び出しまで（#22831） - •
fal_client——最初の画像生成まで（#22859）
各 PR は小さい。合わせて 2–4 秒。
Nous 認証と .env のロードをキャッシュ（#25341）
hermes tools の All-Platforms 画面は以前、プラットフォームごとに同期で認証プローブを走らせていた。キャッシュが入ってからは 14 秒から 1.5 秒未満に下がった。画面の挙動は同じ、ただ毎回 14 秒のネットワーク時間を燃やさなくなっただけ。
正味の結果
勝利を合算すると、ヘッドラインの 19 秒になる。単独で派手なものはない、合わせるとプログラムが反応してくれる感触が出る。
browser_console 180 倍の話（#23226）
Hermes の browser ツールは Chrome DevTools Protocol（CDP）で headless Chrome を駆動する。v0.14.0 以前、browser_console の評価はこういう道筋だった：
- 1.Chrome へ新規 CDP WebSocket を開く
- 2.ハンドシェイクを待つ（約 1–2 s）
- 3.評価する JavaScript を送る
- 4.結果を読む
- 5.WebSocket を閉じる
連鎖する評価——例えばエージェントがページを段階的に検査するワークフロー——では、評価あたり約 1.5 s かかっていた。典型的な「このページを見て教えて」フローは耐え難く遅かった。
v0.14.0 の変更：supervisor あたり永続化 WebSocket を 1 本、browser ツール呼び出し全体で共有。CDP ハンドシェイクはセッションあたり 1 回だけ起き、後続の評価はステップ 1–2 をまるごと飛ばしてペイロードだけ送る。
結果：呼び出しあたりレイテンシが約 1.5 s から約 8 ms へ。およそ 180×。
教訓は汎用だ。エージェントが N 回ツール呼び出しをし、毎回新規接続を開く類の場所はどこでも：チャットペースの負荷では、並列性より接続プーリングの方が効く。作業全体は接続セットアップに住んでいて、本体ではない。
セッション横断 1 時間のプロンプトキャッシュ（#23828, #25434, #24778）
Claude のプロンプトキャッシュ（Anthropic API の機能）は、コンテキストの一部をキャッシュ可能とマーク付けできる。TTL 内の後続リクエスト——歴史的には 5 分——はキャッシュ済み prefix をはるかに低いコストとレイテンシで再利用する。
v0.14.0 以前、Hermes はこれをセッション内で使っていた：システムプロンプト ＋ アクティブな skill がキャッシュされ、同じ会話内のヒットは速くて安い。だが /new を走らせるとキャッシュは無効化され、次の会話は冷たい状態から始まる。
v0.14.0 の作業は 3 つの PR にまたがり、キャッシュ TTL を 1 時間に伸ばし、キャッシュキーが /new を生き残るようにした。新しいセッションの最初の応答が、前のセッションが残した温かいキャッシュの恩恵を受ける。1 日に短い会話を何度も持つ人にとって、意味のあるコストとレイテンシの勝利だ。
このキャッシュはバックグラウンドの memory レビューフォーク（#25434）にも乗る——定期的に memory ファイルを見直して整理するプロセスが、毎回フル料金を払う代わりに同じプロンプトキャッシュにヒットするようになった。
この領域のおまけの修正：プロンプトキャッシュキーが日付だけのタイムスタンプを使うようになり、タイムゾーンを跨いでもキャッシュが壊れない。冗長な gateway-DB 往復ログも整理されて、観測性も上がった。
どうやってこの勝利を見つけたか
著者はどうやってこの特定のホットパスを見つけたか。答えは 2 つ：
- •本物のインストールでの冷起動プロファイリング。
hermesを計測下で走らせ、どの import が一番遅いかを追う。そして 1 つずつ潰した。 - •「Hermes が遅い」というユーザ報告。
hermes toolsAll-Platforms 画面の遅さは具体的なバグ報告だった——浮かんでくれば、修正は素直だった。
魔法はない。python -X importtime、cProfile、そして人が不満を言うのを聞く——勝利はそれで見つかる。
エージェントを書く人へ向けた教訓
自分のエージェントを作っているなら、v0.14.0 の波は数本のルールに一般化できる：
- 1.使わないものを import するな。 各アダプタ・各プロバイダ SDK は lazy にする。冷起動は import グラフだ。
- 2.安定しているものは全部キャッシュする。 skills インデックス、モデルカタログ、認証トークン。古いと分かっているときだけ再取得。
- 3.接続をプールする。 同じ API や CDP サーバをセッション内で複数回呼ぶなら、接続を握っておく。
- 4.独立したプローブは並列に走らせる。 doctor、ヘルスチェック、順序が問われない処理は何でも。
- 5.要らない UI は描画しない。 歓迎バナー、装飾的な出力——非インタラクティブな経路では飛ばす。
これらは新しい話ではない。任意の CLI に対する標準的な性能プレイブックだ。v0.14.0 で面白いのは、1 つのリリース窓口でプレイブック全体を適用しきって、結果がユーザの更新の瞬間に体感できたことだ。
5 月初頭の Hermes が動きが渋く感じたなら、v0.14.0 が「冷たい経路が消えたリリース」だ。