OpenClaw LLMのコールドモデル読み込み時のタイムアウト修正

問題: コールドモデルが60秒でタイムアウト
ユーザーから報告があった問題では、OpenClawでコールドロードされたローカルモデルが、一般的なエージェントのタイムアウト設定がはるかに高いにもかかわらず、約60秒後に一貫して失敗していました。この問題は、Ollama経由のクラウドモデルや、時にはOpenAI Codexでも発生しました。
典型的な失敗パターン:
- モデルはウォーム状態であれば動作する
- コールドモデルは約60秒で停止する
- ログにはタイムアウト / 埋め込みフェイルオーバー / ステータス: 408 と記載される
- フォールバックモデルが引き継ぐ
誤解を招く設定
ソースでは、いくつかの明白な設定オプションが実際の修正策ではなく、開発者を誤った方向に導く可能性があると警告しています:
agents.defaults.timeoutSeconds.zshrcエクスポートLLM_REQUEST_TIMEOUT- LM Studio / Ollamaをすぐに非難すること
根本原因
この問題は、OpenClawがモデルが最初のストリームトークンを出力するまでの期間に対して、別個の埋め込みランナーLLMアイドルタイムアウトを持っていることに起因します。
ソーストレースは以下で確認できます:
src/agents/pi-embedded-runner/run/llm-idle-timeout.ts
デフォルト値:
DEFAULT_LLM_IDLE_TIMEOUT_MS = 60_000
設定パスは以下から解決されます:
cfg?.agents?.defaults?.llm?.idleTimeoutSeconds
したがって、実際の設定パラメータは:
agents.defaults.llm.idleTimeoutSeconds
修正方法
テストの結果、有効な設定は以下の通りです:
{
"agents": {
"defaults": {
"llm": {
"idleTimeoutSeconds": 180
}
}
}
}
テストでは、以前は約60秒で失敗していたコールドGemma呼び出しが、その閾値を超えて生存し、最終的には即時のフェイルオーバーなしで正常に応答することが確認されました。
推奨される恒久的な設定
{
"agents": {
"defaults": {
"timeoutSeconds": 300,
"llm": {
"idleTimeoutSeconds": 300
}
}
}
}
300秒という推奨値は、ローカルモデルが予測不可能であることを考慮しており、誤ったフェイルオーバーが発生するよりも、真にコールドなモデルを長く待つ方が問題が少ないという判断に基づいています。
📖 Read the full source: r/openclaw
👀 See Also

クロード ステルスモード指令 自律AI実行のための
Redditユーザーが、Claudeを完全に静かに自律的に動作させ、作業が完了するまで会話出力なしでワンショットの結果を提供する『ステルスモード』の指示を共有しています。

5つの一般的なオープンクロー設定ミス:無駄な出費とセキュリティリスクを生む原因
50以上のOpenClawセットアップをレビューした結果、同じ5つの問題が繰り返し発生しています:ほとんどのタスクでSonnetではなくOpusをデフォルトモデルとして使用すること、新しいセッションを開始しないこと、ソースコードを読まずにスキルをインストールすること、ゲートウェイをネットワークに公開すること、最初のエージェントを修正する前に2番目のエージェントを追加することです。

批判的LLM対話のための実践的習慣
Redditの投稿では、LLMを扱う際に確証バイアスを回避する具体的な手法が概説されており、中立的な説明のための「ストロベリー」モードや対立的な精査のための「ソクラテス」モードといったカスタムプロンプトモード、さらにトレーニングデータの構成評価などが含まれています。

マルチモデルルーティングにより、OpenClaw APIのコストが50%削減されます。
ある開発者が、異なるタスクを異なるモデルにルーティングすることでOpenClaw APIコストを50%削減しました:複雑な推論にはClaude、ファイル操作やテスト生成にはDeepSeek、中程度のタスクにはGeminiまたはGPTを使用しています。