主な症状

エージェントは500秒のタイムアウトが設定されているにもかかわらず、リザーブモデルにフォールバックし、実際のタイムアウトは15秒後に発火します：

openclaw-gateway-1  |  2026-04-12T22:02:44.589+00:00 [agent] embedded run timeout: runId=slug-gen-1776031345185 sessionId=slug-generator-1776031345185 timeoutMs=15000

適用された設定

ユーザーが適用した設定構造（コミュニティでの議論で推奨されているもの）：

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 500,
      "llm": {
        "idleTimeoutSeconds": 500
      }
    }
  }
}

モデルのウォームアップ時間

Ollamaモデルはウォームアップするだけで2分以上かかり、CPUベース推論としては想定どおりの動作です：

$ time docker compose exec ollama ollama run qwen2.5:7b "warmup"
Sure! What kind of warm-up would you like?

real    2m32.193s
user    0m0.059s
sys     0m0.027s

フェイルオーバーシーケンス

ログにおける完全な失敗シーケンス：

ollama-1 | [GIN] 2026/04/12 - 22:02:45 | 500 | 16.171687684s | 127.0.0.1 | POST "/api/chat"
openclaw-gateway-1 | [agent] embedded run timeout: timeoutMs=15000
openclaw-gateway-1 | [agent] embedded run failover decision: decision=fallback_model reason=timeout
openclaw-gateway-1 | [diagnostic] lane task error: error="FailoverError: LLM request timed out."

設定パスの不一致

ユーザーの設定は誤ったネストされたパス構造を使用しています。agents.defaults.llmパスは、タイムアウト設定用のOpenClaw設定スキーマに存在しません。タイムアウト値は無視されており、OpenClawは15秒（15000ms）のハードコードされたデフォルトにフォールバックします。

ハードコードされたタイムアウトの動作

OpenClawのエージェントランタイムには、agents.defaults設定ブロックでは上書きできないハードコードされたデフォルトタイムアウトがあります。関連する設定パスは次のとおりです：

• agents.defaults.timeoutSeconds — エージェント全体の実行タイムアウトを制御しますが、LLMリクエストのタイムアウトではありません
• llm.requestTimeoutSeconds — LLM HTTPリクエストタイムアウトの正しいパス（agents.defaults.llmではありません）
• llm.idleTimeoutSeconds — リクエストタイムアウトとは別の、接続のアイドルタイムアウトを制御します

設定解決の失敗

OpenClawが設定を解析する際、スキーマに対してパスを検証します。不明または未登録のパスはデバッグレベルでログに記録されますが、起動の失敗にはつながれません。agents.defaults.timeoutSecondsで指定されたタイムアウト値は、基盤となるLLM HTTPクライアントタイムアウトではなく、エージェントオーケストレーションレイヤーに適用されます。

技術的詳細

LLMプロバイダー（Ollama）は独自のタイムアウト設定を持つHTTPクライアントを使用します。OpenClawのコードベースでは、リクエストタイムアウトはプロバイダーオプション経由で渡されます：

// Pseudo-code representation of the timeout flow
llmClient := NewLLMClient(llm.Config{
    RequestTimeout: config.GetInt("llm.requestTimeoutSeconds") * 1000, // defaults to 15000ms
})

// The agent orchestrator timeout (agents.defaults.timeoutSeconds) is separate
agentRunner := NewAgentRunner(AgentConfig{
    RunTimeout: config.GetInt("agents.defaults.timeoutSeconds") * 1000,
})

Ollamaプロバイダーはagents.defaults.timeoutSecondsではなく、llm.requestTimeoutSecondsからのrequestTimeoutで初期化されます。

手順1：設定ファイルの場所を特定する

アクティブなOpenClaw設定ファイルを見つけます：

# For Docker Compose deployments
docker compose config 2>/dev/null | grep -A5 "config:\|configFile:\|--config" || echo "Checking volumes..."

# Alternative: Find config file in container
docker compose exec openclaw-gateway find / -name "*.yaml" -o -name "*.json" 2>/dev/null | grep -v proc

手順2：正しいパスで設定を更新する

既存の設定を正しい構造に置き換えます：

修正前（誤り）：

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 500,
      "llm": {
        "idleTimeoutSeconds": 500
      }
    }
  }
}

修正後（正しい）：

{
  "agents": {
    "defaults": {
      "timeoutSeconds": 500
    }
  },
  "llm": {
    "requestTimeoutSeconds": 300,
    "idleTimeoutSeconds": 300
  },
  "providers": {
    "ollama": {
      "options": {
        "requestTimeoutSeconds": 300
      }
    }
  }
}

手順3：プロバイダー固有の上書き（推奨）

Ollamaを使用しているため、タイムアウトをプロバイダー設定に直接適用します：

{
  "providers": {
    "ollama": {
      "options": {
        "requestTimeoutSeconds": 300
      }
    }
  }
}

手順4：サービスを再起動する

docker compose down
docker compose up -d
docker compose logs -f openclaw-gateway 2>&1 | head -50

手順5：設定の読み込みを確認する

# Check for configuration warnings on startup
docker compose logs openclaw-gateway 2>&1 | grep -i "warn\|config\|timeout"
Verify the config is loaded (look for validation messages)
docker compose exec openclaw-gateway cat /etc/openclaw/config.yaml 2>/dev/null || 

docker compose exec openclaw-gateway env | grep -i openclaw

方法1：起動ログでタイムアウト値を確認する

# Start fresh and capture startup
docker compose down
docker compose up -d
sleep 5
docker compose logs openclaw-gateway 2>&1 | grep -iE "timeout|llm|request"

設定されたタイムアウト値が読み込まれていることを示す出力が表示されます：

openclaw-gateway-1 | [init] LLM request timeout configured: 300s provider=ollama
openclaw-gateway-1 | [init] Configuration loaded successfully

方法2：テストリクエストを送信して測定する

# Send a test request to the OpenClaw gateway
curl -X POST http://localhost:3000/api/v1/agent/run \
  -H "Content-Type: application/json" \
  -d '{
    "agent": "default",
    "input": "Hello, respond with just the word OK",
    "model": "ollama/qwen2.5:7b"
  }' 2>&1 | tee /tmp/ollama_test.log &
Monitor the actual timeout being applied
watch -n 1 ‘docker compose logs –since 30s openclaw-gateway 2>&1 | grep -i timeout’

方法3：Ollamaの応答時間が古いタイムアウトを超えていることを確認する

# Direct Ollama test (should take 2+ minutes for warmup)
time docker compose exec ollama ollama run qwen2.5:7b "Say hello"
Expected: Should complete without OpenClaw timeout error
Old behavior: Fail after 15 seconds with “LLM request timed out”
Fixed behavior: Wait for Ollama response up to configured timeout

方法4：診断エンドポイントで確認（利用可能な場合）

curl http://localhost:3000/api/v1/diagnostics 2>/dev/null | jq '.providers[] | select(.provider=="ollama") | .timeoutSeconds'

期待される出力：300

1. 設定パスの大文字と小文字の区別

OpenClaw設定キーは大文字と小文字を区別します。これらは同等ではありません：

# WRONG
"RequestTimeoutSeconds": 300

# CORRECT
"requestTimeoutSeconds": 300

2. ネストされたパスの思い込み

タイムアウト設定をagents.defaults.llmの下にネストするとLLMプロバイダーに伝播されると推測しないでください。設定スキーマはフラットな名前空間を使用します：

# WRONG - This path does not exist
agents.defaults.llm.requestTimeoutSeconds

# CORRECT - Top-level llm section
llm.requestTimeoutSeconds

# ALSO CORRECT - Provider-specific options
providers.ollama.options.requestTimeoutSeconds

3. 時間単位の不一致

異なる設定フィールドは異なる単位を使用します：

• timeoutSeconds — 秒（整数）
• requestTimeoutSeconds — 秒（整数）
• idleTimeoutSeconds — 秒（整数）
• timeoutMs — ミリ秒（ログで表示的那样）

変換：300秒 = 300,000ミリ秒

4. Dockerボリュームのキャッシュ

ボリューム経由でマウントされた設定ファイルはキャッシュされる場合があります。クリーンな再読み込みを強制します：

docker compose down --remove-orphans
docker compose rm -f openclaw-gateway
docker compose up -d
# Do NOT just restart; perform full teardown

5. 環境変数による上書き

環境変数は設定ファイルより優先されます。競合する設定を確認します：

docker compose config 2>/dev/null | grep -iE "timeout|env|OPENCLAW"
docker compose exec openclaw-gateway env | grep -iE "TIMEOUT|OLLAMA"

6. macOS固有：CPUスロットリング

Apple Silicon搭載のmacOSでは、OllamaのCPUエミュレーションが非常に低速になります。単純なクエリでも最初の応答に5分以上かかる場合があります。設定したタイムアウトが最悪ケースのレイテンシを超えていることを確認してください。

7. Ollamaモデルの読み込み

初期モデル読み込み時間（ログで確認可能：「llama runner started in 11.87 seconds」）はLLMタイムアウトにカウントされます。CPUベースモデルの場合、コールドスタートを考慮してバッファ時間を追加してください。

• FailoverError: LLM request timed out — LLMプロバイダーが設定されたタイムアウトを超えたときに表示される主なエラー
• embedded run timeout: timeoutMs=15000 — 15秒のハードコードされたデフォルトが使用されたことを示すログメッセージ
• embedded run failover decision: fallback_model — タイムアウトトリガーによるフェイルオーバー決定
• Issue #46049 — 外部LLMプロバイダーに関するタイムアウト設定の問題
• Issue #24235 — OpenClawの исторический timeout handling inconsistency
• HTTP 500 from Ollama — 遅い応答の後にOllamaがサーバーエラーを返す; タイムアウトと誤解されやすい
• strconv.ParseInt: parsing "max" — OllamaコンテナでのCPU配额解析警告（無害、タイムアウトとは無関係）

トラブルシューティングマトリックス