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

35日間のClaude Code:3つの並列エージェントが本当の上限である理由
Claude Code の1,800ターン以上の分析で、ボトルネックはコンテキストではなく、人間の統合能力にあることが判明。N ≈ 1 / (待機時間の割合)という単純な式が、エージェント3つで壁にぶつかる理由を説明する。

Telegram vs Discord vs WhatsApp:あなたのOpenClawチャンネル選び
Telegram、Discord、WhatsAppの比較:あなたに合ったOpenClawチャンネルの選び方

2x3090でCPUオフロードを使用したMiniMax M2.7 Q8_0 128Kの実行 – 実世界のベンチマークと設定
あるユーザーがMiniMax M2.7(Q8_0量子化)を128Kコンテキストで2枚のRTX 3090とDDR4 RAM上で正常に実行し、プロンプト処理で約50 tps、トークン生成で約10 tpsを達成し、llama-serverのフラグを共有しています。

Claude AgentがTenor GIFを使用してDiscord経由でミームを送信 — 完全なプロトコル
Claudeコードエージェントのセットアップにより、すべてのDiscordトランスポートメッセージに、文脈に応じた絵文字リアクション、一言ステータスメッセージ、検証済みのTenor GIF URLが追加され、無効なリンクを避けるために明示的なウェブ検索とフェッチの手順が含まれています。