OpenClaw → Codex Fallback Diagnosis
Datum: 2026-04-24 Rating: 🔴 BLOCKER für qwen3-primary Onboarding-Test Status: Wartet auf Chapaty-Entscheidung (A vs C)
Symptom
Howard-Test "Antworte kurz: welches Model nutzt du gerade?" dauert 5m48s. executionTrace.winnerModel = "gpt-5.4" (Codex), obwohl Howard-Config primary=qwen3:8b-32k. Codex halluziniert Antwort "Ich nutze gerade ollama/qwen3:8b-32k" — faktisch falsch, echt war Codex.
Angewandte Fixes (alle richtig, aber nicht kausal)
| Fix | Wert vorher → nachher | Kausal? |
agents.defaults.contextTokens | 16000 → 32000 | nein |
agents.defaults.heartbeat.model | qwen3:8b → qwen3:8b-32k | nein |
commands.nativeSkills | "auto" → false | nein (reduziert Prompt, verhindert aber OOM nicht) |
agents.defaults.model.primary | llama3.1:8b → qwen3:8b-32k | nein (Howard-per-agent-Config zog schon) |
Echter Root-Cause: OOM
Ollama-Logs während Test (05:13–05:19 UTC):
05:13:10 loading model layers=37 (qwen3:8b-Variant, Primary)
05:14:22 loading model layers=37 (Retry)
05:16:21 POST /api/chat → 500 nach 1m59s (qwen3:8b-32k crash)
05:16:25 loading model layers=41 (qwen3:14b-32k, Fallback)
05:16:52 error: llama runner process has terminated: signal: killed
05:17:16 error: llama runner process has terminated: signal: killed
05:18:23 error: llama runner process has terminated: signal: killed
05:19:07 error: llama runner process has terminated: signal: killed
signal: killed = SIGKILL = OOM Killer.
Host-Status während Test:
- Total: 31.3 GiB, Free: 13 GiB
- Swap: 0 B (nicht konfiguriert)
- qwen3:8b-32k im /api/ps geladen (10GB size)
- KV-Cache für 32k ctx auf 36 layers: ~15–17 GB bei realem Prompt
- → Summen-Footprint übersteigt 13GB free → OOM-Kill
Warum qwen3:8b-32k schon beim Primary OOM't
Selbst bei leerem Warm-Up (/api/generate mit 5 Tokens) = 10GB RAM ✅. Bei realem OpenClaw-Request (System-Prompt + Tool-Schemas + Workspace ~5–8k Token):
- KV-Cache wächst proportional
- Peak-Allokation überschreitet freie RAM
- llama-runner gets SIGKILL
Warum qwen3:14b-32k als Fallback 4× scheitert
14B weights = 9 GB base. Plus KV für 32k ctx = ~20+ GB. Nie genug free. OOM-Killer tötet Ollama-Runner (signal killed, nicht graceful shutdown).
Warum Codex "gewinnt"
OpenClaw-Cascade:
- qwen3:8b-32k → 1m59s → timeout/500
- qwen3:14b-32k → mehrfach OOM (~2min pro Versuch)
- nvidia-nim/llama-3.3-70b → nicht attemptet (oder auch gefailed?)
- openai-codex/gpt-5.4 → ✅ success, winnerModel
fallbackUsed: false im Trace ist irreführend — OpenClaw zählt Codex-Attempts als eigenen Primary-Versuch, nicht als Fallback.
Entscheidungsoptionen
Option A — Swap + num_ctx=16384 (technisch)
- Swap-File 16GB anlegen (
fallocate /swapfile 16G) - qwen3:8b-32k Modelfile:
PARAMETER num_ctx 16384(halbiert KV) - Realistisch: 16k ctx reichen für Single-Agent-Tasks
- Risiko: Swap-Thrashing macht qwen3 langsam (30+ tok/s CPU → 2-3 tok/s)
- Erwartete Latenz: 30–90s pro Howard-Call statt aktuell 5m Codex
Option B — Zurück auf qwen3:8b (8k ctx, kein -32k)
- Ollama default num_ctx=8k → ~5GB KV, kein OOM-Risiko
- Tool-Schema-Bloat muss gekürzt werden (nativeSkills=false + Workspace-Trim)
- Verlust: kein langes Arbeiten an einem Auftrag, nur kurze Turns
- Schnell: 10–30s pro Call
Option C — Codex als Primary akzeptieren
- Codex gratis via ChatGPT-OAuth, kein Lokal-Load
- Latenz: ~5 Min pro Call (wie gerade gesehen) — für interaktive Dispatch zu lang
- Datenschutz: Howard-Content geht zu OpenAI (ChatGPT)
- Für Onboarding-Langlauf akzeptabel, für Telegram-Dispatch nicht
Option D — Hybrid (Lenny=qwen3:8b 8k / Sheldon=Codex / Howard=Codex)
- Lenny bleibt lokal schnell (kein 32k nötig für Dispatch)
- Howard/Sheldon auf Codex (Qualität > Latenz)
- Realistisch, akzeptiert Hardware-Grenzen
Empfehlung
D — Hybrid. Die 32GB-Hardware reicht nicht für stabiles qwen3-32k. Lenny lokal schnell halten, Howard/Sheldon auf Codex (gratis) für Qualität.
Onboarding-Test kann mit Option D starten.