Hermes Agent 社群提出上下文覆寫修補，自訂供應端名稱轉換可能讓設定失效

Hermes Agent 社群於 10 月 6 日回報，自訂 OpenAI 相容供應端的上下文長度解析可能出現兩層問題：舊偵測結果持續生效，使用者設定的覆寫值也可能被忽略。案例使用 v0.21.5、Docker 與自架 LiteLLM 代理，附有啟動紀錄及函式檢查結果；目前仍屬社群回報，影響範圍待上游確認。問題回報

官方文件將 context_length 定義為輸入與輸出 token 的合計預算，Hermes 用它決定歷史壓縮時機及驗證請求。解析順序中，手動設定應優先於持久快取，而快取會跨重啟保留。因此，代理端修正部署後，客戶端仍可能持有不同的容量認知。供應端文件

回報者描述，同一模型別名背後配置不同容量的部署，啟動探測取得 24,000 token 後便被快取；即使移除較小部署並重啟，Hermes 仍沿用該值而初始化失敗。嘗試設定 model.context_length 時，custom:litellm 又在執行期被解析為 custom，名稱比對誤判路由變更，清掉覆寫值。回報者表示，同時明確設定符合實際端點的 model.base_url 可讓覆寫生效。重現與暫時處理方式

草稿 PR #133615 只處理名稱比對：將具名自訂供應端與其執行期的 custom 視為相同身分，仍保留不同具名供應端之間的差異。作者回報八項相關測試通過，但這是作者提供的驗證，尚無合併或正式發布證據；持久快取缺乏到期機制的問題也不在此修補範圍。修補提案

對維運工程師而言，這個案例提示：排查上下文錯誤時，應同時核對後端容量、客戶端快取與設定是否實際生效。後續值得追蹤供應端身分修補是否合併，以及快取是否加入重新驗證機制；現有證據仍不足以推論所有 LiteLLM 或自訂端點都會受影響。