Primäre Manifestation

Der Agent fällt trotz konfigurierter 500-Sekunden-Timeout auf ein Reserve-Modell zurück, wobei das tatsächliche Timeout nach 15 Sekunden ausgelöst wird:

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

Angewendete Konfiguration

Der Benutzer hat die folgende Konfigurationsstruktur angewendet (wie in Community-Diskussionen empfohlen):

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

Modell-Aufwärmzeit

Das Ollama-Modell benötigt über 2 Minuten nur zum Aufwärmen, was für CPU-basierte Inferenz erwartet wird:

$ 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

Failover-Sequenz

Die vollständige Fehlersequenz in den Logs:

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."

Konfigurationspfad-Fehlanpassung

Die Konfiguration des Benutzers verwendet die falsche verschachtelte Pfadstruktur. Der Pfad agents.defaults.llm existiert im OpenClaw-Konfigurationsschema für Timeout-Einstellungen nicht. Der Timeout-Wert wird stillschweigend ignoriert, und OpenClaw verwendet den fest codierten Standardwert von 15 Sekunden (15000ms).

Fest codiertes Timeout-Verhalten

Die Agent-Laufzeit von OpenClaw hat ein eingebautes Standard-Timeout, das nicht über den Konfigurationsblock agents.defaults überschrieben werden kann. Die relevanten Konfigurationspfade sind:

• agents.defaults.timeoutSeconds — Steuert das gesamte Agent-Ausführungs-Timeout, nicht das LLM-Anfrage-Timeout
• llm.requestTimeoutSeconds — Der korrekte Pfad für das LLM-HTTP-Anfrage-Timeout (nicht agents.defaults.llm)
• llm.idleTimeoutSeconds — Steuert das Verbindung-Inaktiv-Timeout, getrennt vom Anfrage-Timeout

Konfigurationsauflösungsfehler

Wenn OpenClaw die Konfiguration analysiert, validiert es Pfade gegen das Schema. Unbekannte oder nicht registrierte Pfade werden auf Debug-Ebene protokolliert, verursachen aber keine Startfehler. Der Timeout-Wert, angegeben unter agents.defaults.timeoutSeconds, gilt für die Agent-Orchestrierungsschicht, nicht für das zugrunde liegende LLM-HTTP-Client-Timeout.

Technische Vertiefung

Der LLM-Provider (Ollama) verwendet einen HTTP-Client mit eigenen Timeout-Einstellungen. Im OpenClaw-Quellcode wird das Anfrage-Timeout über Provider-Optionen übergeben:

// 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,
})

Der Ollama-Provider wird mit dem requestTimeout aus llm.requestTimeoutSeconds initialisiert, nicht aus agents.defaults.timeoutSeconds.

Schritt 1: Konfigurationsdatei-Standort identifizieren

Finden Sie die aktive OpenClaw-Konfigurationsdatei:

# 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

Schritt 2: Konfiguration mit korrekten Pfaden aktualisieren

Ersetzen Sie die vorhandene Konfiguration durch die korrigierte Struktur:

Vorher (Falsch):

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

Nachher (Korrekt):

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

Schritt 3: Für provider-spezifische Überschreibung (Empfohlen)

Da Sie Ollama verwenden, wenden Sie das Timeout direkt auf die Provider-Konfiguration an:

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

Schritt 4: Dienste neu starten

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

Schritt 5: Konfigurationsladen verifizieren

# 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

Methode 1: Startup-Logs auf Timeout-Wert prüfen

# 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"

Die erwartete Ausgabe sollte den konfigurierten Timeout-Wert zeigen, der geladen wird:

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

Methode 2: Testanfrage auslösen und messen

# 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’

Methode 3: Ollama-Antwortzeit bestätigen, die das alte Timeout überschreitet

# 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

Methode 4: Über Diagnose-Endpunkt verifizieren (falls verfügbar)

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

Erwartete Ausgabe: 300

1. Konfigurationspfad-Groß-/Kleinschreibung

OpenClaw-Konfigurationsschlüssel sind Groß-/Kleinschreibung-sensitiv. Diese sind nicht äquivalent:

# WRONG
"RequestTimeoutSeconds": 300

# CORRECT
"requestTimeoutSeconds": 300

2. Verschachtelte Pfad-Annahmen

Gehen Sie nicht davon aus, dass das Verschachteln von Timeout-Einstellungen unter agents.defaults.llm sich auf den LLM-Provider auswirkt. Das Konfigurationsschema verwendet flache Namespaces:

# 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. Zeiteinheiten-Mismatch

Verschiedene Konfigurationsfelder verwenden unterschiedliche Einheiten:

• timeoutSeconds — Sekunden (Integer)
• requestTimeoutSeconds — Sekunden (Integer)
• idleTimeoutSeconds — Sekunden (Integer)
• timeoutMs — Millisekunden (wie in Logs gesehen)

Umrechnung: 300 Sekunden = 300.000 Millisekunden

4. Docker-Volume-Caching

Über Volumes gemountete Konfigurationsdateien können gecached sein. Erzwingen Sie einen sauberen Neuladen:

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

5. Umgebungsvariable-Überschreibung

Umgebungsvariablen haben Vorrang vor Konfigurationsdateien. Prüfen Sie auf widersprüchliche Einstellungen:

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

6. macOS-Spezifisch: CPU-Drosselung

Auf macOS mit Apple Silicon verursacht die Ollama-CPU-Emulation extreme Langsamkeit. Die erste Antwort kann selbst bei einfachen Anfragen über 5 Minuten dauern. Stellen Sie sicher, dass Sie ein Timeout konfiguriert haben, das Ihre worst-case Latenz überschreitet.

7. Ollama-Modell-Laden

Die anfängliche Modellladezeit (in Logs sichtbar: "llama runner started in 11.87 seconds") zählt gegen das LLM-Timeout. Für CPU-basierte Modelle fügen Sie Pufferzeit hinzu, um Cold Starts zu berücksichtigen.

• FailoverError: LLM request timed out — Primärer Fehler, der auftritt, wenn der LLM-Provider das konfigurierte Timeout überschreitet
• embedded run timeout: timeoutMs=15000 — Log-Nachricht, die anzeigt, dass der 15-Sekunden-Standardwert verwendet wurde
• embedded run failover decision: fallback_model — Entscheidung, die aufgrund des Timeout-Auslösens getroffen wurde
• Issue #46049 — Zugehöriges Timeout-Konfigurationsproblem mit externen LLM-Providern
• Issue #24235 — Historische Timeout-Handling-Inkonsistenz in OpenClaw
• HTTP 500 from Ollama — Ollama gibt nach langsamer Antwort einen Serverfehler zurück; oft als Timeout fehlinterpretiert
• strconv.ParseInt: parsing "max" — CPU-Quota-Parsing-Warnung im Ollama-Container (harmlos, nicht mit Timeout verbunden)

Fehlerbehebungsmatrix