N100/WSL2でtimeoutSeconds設定にもかかわらずllm-idle-timeoutが2分で発火

r/openclawのユーザーが、Intel N100(16GB RAM)をWSL2で動作させた場合、llm-idle-timeoutウォッチドッグがagents.defaults.timeoutSeconds=300の設定に関係なく、ちょうど2分後に発動すると報告しています。ゲートウェイの起動には45秒以上かかり、その間にアイドルタイマーが切れてしまいます。
主な詳細
- ハードウェア: Intel N100、16GB RAM、WSL2
- 問題: ゲートウェイの起動に45秒以上かかり、その後2分のアイドルウォッチドッグが発動。セッションが途中で終了する。設定した
timeoutSeconds=300は無視される。 - 要望: 起動の遅さを考慮した設定可能な
noOutputTimeoutMsパラメータ、または低電力ハードウェアに最適化された高速な起動パス。
問題の根本は、ウォッチドッグがアイドル時間を最初のLLMリクエストからではなく、ゲートウェイプロセスの開始時点からカウントすることにあります。N100のような遅いハードウェアでは、初期化に時間がかかり、デフォルトの2分タイムアウトがLLM呼び出しの前に発動してしまいます。
回避策として、システムレベルのアイドルタイムアウトを増やしたり、ゲートウェイの起動スクリプトを調整して初期化時間を短縮する方法が考えられます。しかし、根本的な解決にはコードレベルの変更、つまり初期アイドル猶予期間の延長か、起動フェーズ用の独立したnoOutputTimeoutMsの公開が必要です。
これは、WSL2経由でOpenClawを低電力デバイス(シンクライアント、NASボックスなど)で実行する開発者にとって既知の痛点です。GitHubのIssueはOpenClawリポジトリで管理されています。
📖 フルソースを読む: r/openclaw
👀 See Also

AIエージェントの精度を向上させるための4層ナレッジベースアーキテクチャ
ある開発者が、AIエージェントにドメイン固有のコンテキストを提供するために200以上の記事からなる構造化ナレッジベースを構築し、クエリ分類を含む4層パイプラインを実装することでトークンコストを約40%削減しました。

ClamBot: セキュリティのためWASMサンドボックスでLLM生成コードを実行するAIエージェント
ClamBotは、QuickJSをWasmtime上で使用してWebAssemblyサンドボックス内で全てのLLM生成コードを実行するAIエージェントフレームワークであり、exec()やサブプロセス呼び出しを不要にします。ツール呼び出しの承認ゲート、'clams'としての永続的なスクリプトキャッシュ、複数のLLMプロバイダーサポートを含みます。

Nexusデスクトップアプリ、TTRPGキャンペーン管理のためのMCPセットアップを自動化
Claude Desktopの設定を毎回手動で編集するのにうんざりしていませんか?Nexusを使えば、TTRPGキャンペーン管理のためのArchivist、Foundry VTT、Notion、Obsidian、NotebookLMのMCPをインストール・設定できます。

PRECCツール、事前ツール呼び出し圧縮でClaudeコードAPIコストを削減
開発者がPRECCというオープンソースツールを構築しました。このツールはClaude Codeのツール呼び出しを傍受し、RTK(冗長性を考慮したトークン圧縮)を使用してペイロードを圧縮します。これにより、入力トークンが40〜66%削減され、知覚できる遅延の影響はありません。