Debugging von OpenClaw + Ollama-Lokalmodelle-Zeitüberschreitungen: Fünf Lösungen für stille Fehler

Problem: OpenClaw-Agenten fallen stillschweigend mit lokalen Ollama-Modellen aus

Ein Entwickler, der OpenClaw 2026.4.2 mit Ollama 0.20.2 und dem Gemma 4 26B-A4B Q8_0-Modell auf einem M4 Max Mac Studio debuggte, stellte fest, dass Agenten nach einem /new-Befehl nicht antworteten, obwohl das Modell über ollama run sofort funktionierte. In den Protokollen erschienen keine Fehler, und der Agent zeigte keinen Tippindikator.

Hauptursachen und Lösungen

• Hauptursache #1: Blockierender Slug-Generator: Der session-memory-Hook von OpenClaw führt einen Slug-Generator aus, der eine Anfrage mit einem fest codierten 15-Sekunden-Timeout an Ollama sendet. Wenn das Modell den Systemprompt von OpenClaw nicht rechtzeitig verarbeiten kann, bricht OpenClaw die Anfrage ab, aber Ollama verarbeitet sie weiter und blockiert damit nachfolgende Agentenanfragen.
  Lösung: openclaw hooks disable session-memory
• Hauptursache #2: Großer Systemprompt: OpenClaw injiziert pro Anfrage etwa 38.500 Zeichen Systemprompt (Identität, Tools, Bootstrap-Dateien). Lokale Modelle benötigen 40-60 Sekunden für die Prefill-Phase.
  Lösung: Zur Konfiguration hinzufügen, um Bootstrap-Injektion zu überspringen und Zeichen zu begrenzen:

  { "agents": { "defaults": { "skipBootstrap": true, "bootstrapTotalMaxChars": 500 } } }

  Dies reduziert den Prompt auf ~19K Zeichen.
• Hauptursache #3: Verstecktes Leerlauf-Timeout: OpenClaw hat einen DEFAULT_LLM_IDLE_TIMEOUT_MS von 60 Sekunden. Wenn das Modell innerhalb dieser Zeit kein erstes Token erzeugt, beendet es die Verbindung und wechselt stillschweigend zu einem Fallback-Modell (z.B. Claude Sonnet).
  Lösung: Einen undokumentierten Konfigurationsschlüssel setzen:

  { "agents": { "defaults": { "llm": { "idleTimeoutSeconds": 300 } } } }

• Hauptursache #4: Serielle Verarbeitung von Ollama: Ollama verarbeitet Anfragen seriell, sodass abgebrochene Slug-Generator-Anfragen Verarbeitungsslots blockieren können.
  Lösung: Zur Ollama plist/Service-Konfiguration hinzufügen: OLLAMA_NUM_PARALLEL=4
• Hauptursache #5: Denkmodus-Verzögerung: Gemma 4 standardmäßig eine Denk-/Argumentationsphase, die 20-30 Sekunden vor dem ersten Token hinzufügt.
  Lösung: In der Konfiguration deaktivieren:

  { "agents": { "defaults": { "thinkingDefault": "off" } } }

Vollständige funktionierende Konfiguration

Der Entwickler stellte diese vollständige Konfiguration für einen funktionierenden Setup bereit:

{ "agents": { "defaults": { "model": { "primary": "ollama/gemma4:26b-a4b-it-q8_0", "fallbacks": ["anthropic/claude-sonnet-4-6"] }, "thinkingDefault": "off", "timeoutSeconds": 600, "skipBootstrap": true, "bootstrapTotalMaxChars": 500, "llm": { "idleTimeoutSeconds": 300 } } } }

Zusätzlich das Modell im Speicher fixieren, um das Entladen zwischen Anfragen zu verhindern:

curl http://localhost:11434/api/generate -d '{"model":"gemma4:26b-a4b-it-q8_0","keep_alive":-1,"options":{"num_ctx":16384}}'

Ergebnisse und Kompromisse

Nach Anwendung der Lösungen dauert die erste Nachricht nach /new etwa 60 Sekunden aufgrund der Systemprompt-Prefill-Phase, was für lokale Modelle als unvermeidbar beschrieben wird. Nachfolgende Nachrichten sind schnell, da Ollama den KV-Zustand zwischenspeichert. Das Setup verwendet 31 GB VRAM, 100 % GPU und ein 16K-Kontextfenster und läuft vollständig lokal ohne API-Kosten.

Die anfängliche Verzögerung ist der Kompromiss für vollständigen lokalen Betrieb, Privatsphäre und keine Kosten. Der Entwickler merkt an, dass es sich lohnt, wenn diese Faktoren priorisiert werden.