GitHub Repo
Hermes Agentコミュニティ、長い会話の転送失敗を報告 1 MiBの転送上限が新しいプロンプトを阻止
10月26日のHermes Agentコミュニティの報告によると、複数のバックエンドが設定ファイルを共有している場合、大きすぎる会話の復元データによってプロンプト転送が失敗する可能性がある。27日の再現・修正をめぐる議論では、上限の引き上げは緩和策にすぎず、不要な全履歴の転送にも対処が必要とされた。

Hermes Agentコミュニティは10月26日、複数のバックエンドが同じ設定ファイルを共有している場合、長い会話で新しいプロンプトを受け付けられなくなる可能性があると報告した。報告された状況には、ゲートウェイの所有者と、Desktop-SSHで分離されたバックエンドが含まれる。後者はリクエストを受け取った後、そのセッションを保持するバックエンドへプロンプトを転送する必要がある。問題は転送前の復元処理で発生し、ユーザーにはビジー状態や拒否を示すメッセージだけが表示される場合がある。問題報告と議論
コミュニティの分析によると、転送接続はまずsession.resumeを呼び出す。この応答には会話履歴全体が含まれる一方、WebSocketライブラリのデフォルト受信上限が適用されていた。データが1 MiBを超えると、接続はコード1009で閉じられ、その後のprompt.submitは実行されない。つまり、失敗箇所はエージェントの通信レイヤーにあり、これだけを根拠にモデルのコンテキストが上限に達したとは判断できない。技術分析
上流のwebsockets公式ドキュメントによると、connect()のmax_sizeのデフォルト値は1,048,576バイトで、受信メッセージのサイズを制御する。Noneを設定すると制限を解除できる。このドキュメントは報告された制限の仕組みを裏付けるが、Hermesのすべてのデプロイで影響が生じることを単独で証明するものではない。websockets APIドキュメント
コミュニティは、一般的なクライアント経路に合わせて上限を8 MiBに引き上げる案を提示した。27日には、9 MiBの応答でも失敗したという報告が別の参加者から寄せられ、転送側で必要なのはセッション識別子だけだと指摘された。こうした議論から、復元側でomit_messagesに従い、不要な履歴データを返さないようにする案も浮上した。修正と境界値テストに関する議論
長時間稼働するエージェントを運用するエンジニアにとって、この事例はセッションの永続化やバックエンド間のルーティングにも容量上限があることを示している。今後は、修正が正式リリースに含まれるか、上限超過エラーが明確に表示されるか、履歴を省略する動作が実装されるかを確認する必要がある。確認時点で問題は未解決のままであり、この記事では再現テストを独自に実施しておらず、正式な修正バージョンも確認していない。