Hermes Context Compression 逾時：修正方法

「Context compression timed out before it could commit」表示 Hermes 的摘要模型 — auxiliary.compression 下的模型，而不是你的主要模型 — 在 Hermes 的壓縮預算耗盡前沒有取得進展，而回合在主要呼叫送出前就停止了。這取決於版本：我們在 Hermes Agent v0.21.3 上重現了這兩則訊息，並透過讓摘要模型回應、再於同一工作階段重試而復原；而在 v0.21.5 上，同樣的停滯造成的是長時間等待，而非錯誤。測試於 2026 年 10 月 1 日進行，使用的是兩個模型的錄製替身，而非真實供應商。

如果你是要讓 Hermes 連線到自己的端點，而不是進行除錯，請先從使用自訂 API 的 Hermes Agent開始。

兩則訊息，以及各自代表的含義

你看到的情況	出現時機	主要呼叫已送出？
「上下文壓縮在提交結果前逾時，此時請求仍約為 83,485 個 token。供應商呼叫未送出。執行 /compress 並等待完成，然後重試。」	v0.21.3，摘要模型無回應，請求（約 83,485 個 token）大於模型的 64,000-token 視窗	否
「上下文壓縮逾時，未能縮減此對話。沒有訊息遭到捨棄。使用 /new 開始新的工作階段，或在再次執行 /compress 前檢查 auxiliary.compression。」	v0.21.3，摘要模型無回應，請求（約 57,489 個 token）超過 54,400-token 壓縮觸發值，但仍在視窗內	否

第一則訊息中的 token 數字是 Hermes 對即將送出的請求所做的自身估算。兩個回合在日誌中都以 reason=context_compression_timeout 搭配 api_calls=0 結束，此前出現「Context compression made no progress for 5.0s」形式的警告 — 之所以是五秒，是因為測試將 compression.context_timeout_seconds: 5 設為較短以縮短執行時間；預設值是 120。

你使用的版本決定會發生什麼事

摘要模型狀態	v0.21.3（9 月 14 日）	v0.21.5（9 月 24 日）
無回應，請求在視窗內	回合停止 — 上方第二則訊息	等待其回應（等待 30 秒及 90 秒），將 9 則訊息壓縮為 5 則，並送出請求
無回應，請求超過視窗	回合停止 — 上方第一則訊息	未使用無回應的摘要模型執行；文件以一個閒置預算及確定性的備援摘要限制此情況
回答錯誤（404）	嘗試兩次，略過壓縮，送出請求（在視窗內測試）	相同；也送出了一個超過視窗的請求，真實供應商會拒絕該請求
有回應	已壓縮並送出	已壓縮並送出

邊界位於原始碼中。在 v0.21.4（標籤 v2026.9.21）中，逾時壓縮後停止回合的函式被縮限為僅處理超過模型視窗的請求，並引用 issue #113646 與 #114594；v0.21.3 則會停止所有請求。v0.21.5 的設定文件接著補充，壓縮等待時間「以輔助壓縮請求自身的逾時值為下限（auxiliary.compression.timeout，最低 300s）」— 這就是為什麼我們的五秒設定在該版本中沒有作用。因此在目前版本中，摘要模型緩慢會讓你等待數分鐘，而不是產生錯誤；無回應的摘要模型則會被略過。

最短診斷方式

檢查版本，使用 hermes --version。在 v0.21.3 或更早版本中，上述兩則訊息是摘要模型停滯時的預期行為。
在 ~/.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 案例中，使用能回應的摘要模型重新啟動替身，並在同一工作階段再送出一個回合（--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

有兩項未經測試：Hermes Desktop 與 messaging-gateway 介面，它們有自己的衛生壓縮及不同預算；以及真實供應商拒絕超過視窗的請求。這些執行都是一次性的 hermes chat -Q 回合。

費用

停止的回合不會送出主要模型請求，因此主要模型不會為此產生費用。摘要請求已送出 — 這些執行中的提示約有 19,000 個字元 — 若最終完成，供應商會對它計費。接著重試會支付一次摘要呼叫及一次主要呼叫的費用。小型且快速的摘要模型能同時降低等待時間及額外成本；在 Kunavo 上，Claude Haiku 4.5 的價格是 $0.70每百萬個輸入 token，輸出則為 $3.50每百萬個 token，從預付餘額按 token 計費。Kunavo 沒有人使用其端點執行過 Hermes；此處的執行使用本機替身。

常見問題

Hermes 中的「Context compression timed out before it could commit」是什麼意思？

Hermes 嘗試在傳送你的回合前縮短對話，但它使用的摘要模型在時間預算內沒有取得任何進展，而請求太大，無法以未縮減的形式傳送 — 因此 Hermes 在完全沒有呼叫主要模型的情況下停止了此回合。使用 Hermes Agent v0.21.3、停滯的摘要模型，以及針對 64,000-token 視窗的 83,485-token 請求重現；該回合的日誌行為 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-token 視窗，測試回合前有四個恢復執行的填充回合。版本邊界取自 v2026.9.14、v2026.9.21 及 v2026.9.24 標籤中的 agent/turn_context.py，預算則取自各標籤的設定文件。該替身不是模型或供應商：它接受任何大小的請求，因此未重現供應商端的上下文錯誤。