Hermes のコンテキスト圧縮がタイムアウト：修正方法

「Context compression timed out before it could commit」とは、auxiliary.compressionの下にあるHermesの要約モデル（メインモデルではありません）が、Hermesの圧縮予算が尽きる前に処理を進められず、メイン呼び出しを送信しないままターンが停止したという意味です。バージョンによって異なります。Hermes Agent v0.21.3では2つのメッセージを再現し、要約モデルを応答させて同じセッションで再試行することで復旧しました。一方、v0.21.5では同じ停滞がエラーではなく長い待機になりました。2026年10月1日に、実際のプロバイダーではなく、両モデルの代わりを務める記録用の代替サービスを使ってテストしました。

デバッグではなく自分のエンドポイントに接続してHermesを設定する場合は、まずカスタムAPIを使ったHermes Agentをご覧ください。

2つのメッセージと、それぞれが示す内容

表示される内容	表示された状況	メイン呼び出しは送信されたか？
「コンテキスト圧縮が結果を確定する前にタイムアウトし、リクエストは依然として約83,485トークンでした。プロバイダーへの呼び出しは送信されていません。/compressを実行して完了を待ち、その後再試行してください。」	v0.21.3、要約モデルが無応答、リクエスト（約83,485トークン）がモデルの64,000トークンウィンドウを超過	いいえ
「コンテキスト圧縮がタイムアウトし、この会話は縮小されませんでした。メッセージは一切削除されていません。新しいセッションを/newで開始するか、/compressを再試行する前にauxiliary.compressionを確認してください。」	v0.21.3、要約モデルが無応答、リクエスト（約57,489トークン）が54,400トークンの圧縮トリガーを超えているが、ウィンドウ内	いいえ

最初のメッセージのトークン数は、送信されるはずだったリクエストについてHermesが独自に推定した値です。両方のターンは、警告「Context compression made no progress for 5.0s」の後、reason=context_compression_timeoutとapi_calls=0を伴ってログに記録されました。テスト設定で実行時間を短くするためcompression.context_timeout_seconds: 5に設定したため5秒でした。デフォルトは120秒です。

使用中のバージョンによって動作が決まります

要約モデルの状態	v0.21.3（9月14日）	v0.21.5（9月24日）
無応答、リクエストはウィンドウ内	ターン停止 — 上記の2つ目のメッセージ	待機して圧縮（30秒と90秒の停止）し、9件のメッセージを5件に圧縮してリクエストを送信
無応答、リクエストはウィンドウ超過	ターン停止 — 上記の1つ目のメッセージ	無応答の要約モデルでは実行していません。ドキュメントでは、このケースを1回分の無応答待機時間の上限と決定的なフォールバック要約によって制限しています。
エラーへの応答（404）	2回試行し、圧縮をスキップしてリクエストを送信（ウィンドウ内でテスト）	同じです。ウィンドウ超過リクエストも送信されましたが、実際のプロバイダーなら拒否します
応答済み	圧縮して送信済み	圧縮して送信済み

境界はソースにあります。v0.21.4（タグ v2026.9.21）では、タイムアウトした圧縮後にターンを停止する関数が、問題 #113646 および #114594 を理由として、モデルのウィンドウを超えるリクエストだけに限定されました。v0.21.3ではすべて停止します。その後、v0.21.5の設定ドキュメントには、圧縮待機時間は「補助圧縮リクエスト自身のタイムアウト（auxiliary.compression.timeout、最小300秒）を下限とする」と追加されています。これが、ここで5秒に設定しても何も起きなかった理由です。したがって現在のビルドでは、遅い要約モデルならエラーではなく数分の待ち時間が発生し、停止したモデルならスキップされます。

最短の診断

バージョンを確認します（hermes --version）。v0.21.3以前では、上記の2つのメッセージはいずれも、停止した要約モデルに対する想定どおりの動作です。
要約モデルを見つけるには~/.hermes/logs/agent.logを確認します。「Auxiliary compression: using <provider> (<model>) at <url>」という行に、タイムアウトしたモデルとエンドポイントが示されます。auxiliary.compressionブロックがない場合は、メインモデルを継承します。
トリガー行を確認します。「Pre-API compression: ~N request tokens >= T threshold (context=W)」です。NがWを超えている場合、どのバージョンでもターンを圧縮せずに送信することはできません。
要約モデルのウィンドウを確認します。 Hermesのドキュメントでは、会話の中央部分全体が送信されるため、メインモデル以上の大きさが必要とされています。

検証済みの復旧方法

上記のv0.21.3のすべてのケースで、応答する要約モデルを使うようにスタンドインを再起動し、同じセッションでさらに1ターン送信すると（--resume）、会話を維持したまま正常な応答が返りました。実際の対処法は、auxiliary.compressionを到達可能な高速モデルに向ける、その設定が指しているエンドポイントを修正する、または要約モデルが遅いものの正常に動作している場合（たとえばローカルモデルの場合）にcompression.context_timeout_secondsを増やす、のいずれかです。その後、同じセッションで再試行してください。

応答可能な要約モデルへ圧縮先を向ける — 成功した復旧方法

# ~/.hermes/config.yaml — the summariser is its own model, with its own budget
auxiliary:
  compression:
    base_url: https://api.kunavo.com/v1   # overrides provider; any OpenAI-compatible endpoint
    api_key: sk-kn-...
    model: claude-haiku-4-5             # fast, and a context window >= your main model's
    timeout: 300

compression:
  context_timeout_seconds: 120   # inactivity budget for the summary (default)
  context_total_ceiling_seconds: 600

テストしていないものが2つあります。異なる時間上限で独自の会話整理用圧縮を行うHermesのDesktopおよびメッセージングゲートウェイのインターフェースと、ウィンドウを超えるリクエストを実際のプロバイダーが拒否するケースです。実行は1回限りのhermes chat -Qターンでした。

料金

停止したターンはメインモデルへのリクエストを送信しないため、メインモデルには課金されません。要約リクエストは送信され、今回の実行ではプロンプト約19,000文字でした。最終的に完了すれば、プロバイダーはその分を課金します。その後の再試行では、要約呼び出し1回とメイン呼び出し1回の料金が発生します。小型で高速な要約モデルなら待ち時間とオーバーヘッドの両方を抑えられます。Kunavoでは、Claude Haiku 4.5は入力トークン100万個あたり$0.70、出力トークン100万個あたり$3.50で、前払い残高からトークン単位で課金されます。Kunavoの誰もHermesをそのエンドポイントに対して実行していません。ここでの実行にはローカルのスタンドインを使用しました。

よくある質問

Hermesで「Context compression timed out before it could commit」と表示される意味は？

Hermesはターンを送信する前に会話を短縮しようとしましたが、そのために使う要約モデルが制限時間内に処理を進められず、圧縮なしではリクエストが大きすぎて送信できなかったため、メインモデルを一度も呼び出さずにターンを停止しました。処理が停滞した要約モデルと、64,000トークンのウィンドウに対する83,485トークンのリクエストを使い、Hermes Agent v0.21.3で再現しました。ターンのログ行はapi_calls=0でした。問題はメインモデルでも、そのAPIタイムアウトでもありません。問題はconfig.yamlのauxiliary.compressionにあるモデル、つまり要約モデルです。

Hermesのコンテキスト圧縮タイムアウトを修正するには？

要約モデルが応答するようにしてから、同じセッションで再試行します。再現時はauxiliary.compressionを応答可能なモデルに向け、同じセッションで次のターンを送ると、履歴を保持したままv0.21.3で毎回成功しました。メッセージ自体にも、メッセージは削除されなかったとあります。アップグレードすると状況も変わります。v0.21.4以降では、タイムアウトした圧縮でも、モデルのウィンドウに収まるリクエストは停止しません。v0.21.5では要約待機時間が要約リクエスト自身のタイムアウト以上となり、少なくとも300秒になります。/newで新しいセッションを開始しても動作しますが、会話のコンテキストは失われます。

Hermesの圧縮タイムアウトは修正されていますか？

部分的に修正され、挙動も変わりました。v0.21.3（2026年9月14日）までは、事前圧縮がタイムアウトすると必ずターンが停止しました。v0.21.4（9月21日）では、モデルのコンテキストウィンドウを超えるリクエストだけが停止します。v0.21.5（9月24日）では、要約モデルの処理を30秒、続いて90秒停滞させても、ターンはまったく停止しませんでした。Hermesは待機し、圧縮してリクエストを送信しました。そのため現行バージョンでは、遅い要約モデルの症状はこのエラーではなく長い一時停止です。単に遅いのではなく完全に機能しなくなった要約モデルの場合は異なります。再試行後にスキップされ、ターンは圧縮なしで続行されます。

HERMES_API_TIMEOUTを大きくすると改善しますか？

いいえ。この変数はデフォルト1,800秒のメインモデル呼び出しを制御します。圧縮にはconfig.yaml内に独自の予算があります。compression.context_timeout_seconds（非アクティブ時間の予算、デフォルト120秒）、compression.context_total_ceiling_seconds（デフォルト600秒）、および要約リクエスト自体のauxiliary.compression.timeoutです。Hermesのドキュメントには速度と同じくらい重要な要件もあります。要約モデルのコンテキストウィンドウはメインモデル以上でなければなりません。会話の中央部分全体を受け取るためです。

タイムアウトしたターンには料金が発生しましたか？

Not on the main model: the turn ended before the main call was sent. The summary request was sent, though, and a summariser that eventually finishes is billed by its provider like any other call — in the runs here the summary prompt was about 19,000 characters. The retry then pays for one summary and one main call. That is why pointing compression at a small, fast model is cheaper as well as quicker: on Kunavo, Claude Haiku 4.5 lists at $0.70 per million input tokens.

2026年10月1日に、Hermes Agent v0.21.3（タグ v2026.9.14）およびv0.21.5（タグ v2026.9.24）で再現しました。各バージョンはリリースソースからインストールし、メインモデルと要約モデルの両方を提供するローカルの記録用スタンドインに対して実行しました。停止した要約モデルには応答を保留し、失敗するモデルには404を返し、ウィンドウは64,000トークン、テストターン前にはフィラーを含む再開済みターンを4回置きました。バージョン境界は、v2026.9.14、v2026.9.21、v2026.9.24のタグにおけるagent/turn_context.pyから読み取り、予算は各タグの設定ドキュメントから読み取りました。スタンドインはモデルでもプロバイダーでもなく、任意のリクエストサイズを受け付けるため、プロバイダー側のコンテキストエラーは再現されていません。

Hermes のコンテキスト圧縮がタイムアウトした理由と、効果のあった復旧方法