openclaw - 💡(How to fix) Fix [Bug]: openai-completions adapter hangs indefinitely on reasoning models — 5 models / 4 providers reproduced [2 comments, 2 participants]

Summary

OpenClaw 2026.4.15 openai-completions adapter hangs the main reply lane indefinitely for reasoning models, regardless of provider. active-memory (Anthropic Haiku) completes cleanly, then no further log output for the affected session — no error, no failover, no timeout. Tested 5 model/provider combinations, all hang. Direct curl to the same endpoints from inside the gateway container returns valid JSON in 1-3s.

This appears related to (and possibly the same root cause as) #44549, #45681, #71160, #69902, #5980, #46049 — but with broader reproduction scope including Kimi K2.6 direct, MiniMax M2.5 direct via OR, GLM-4.7 via OR.

Environment

• OpenClaw 2026.4.15
• Image ghcr.io/openclaw/openclaw:latest (auto-update on)
• Linux x86_64 / Docker (Hetzner CX22)
• Channel: telegram (@Oranssi_makkara_bot)
• Plugins: active-memory (Anthropic Haiku-pinned), memory-core, telegram
• Workspace bootstrap: ~32k chars (bootstrapMaxChars: 32000)

Reproduction (any of these)

Set as agents.defaults.model.primary, send a Telegram chat message:

So:

• Reasoning-declared-true models (5/5 tested) → hang indefinitely, never return
• Reasoning-declared-false but model still reasons internally (Kimi K2.6 with reasoning:false) → hangs the same way; declaration alone doesn't bypass the parser
• Truly non-reasoning model (OR auto) → eventually returns but at unusable latency (17min first request, second hangs)

Symptom in logs

Identical pattern across all 5 reproductions:

[telegram] sendMessage ok chat=… message=…    <- /new ack lands fast
[plugins] active-memory: … start
[diagnostic] liveness warning: … work=[active=…(processing/model_call,…,age=Xs last=model_call:started)]
[plugins] active-memory: … done status=empty elapsedMs=~10000
[agent/embedded] embedded run failover decision: runId=active-memory-… stage=assistant decision=surface_error reason=none from=anthropic/claude-haiku-4-5
[no further log entries for this session]

No [fetch-timeout], no [model-fallback/decision], no error surfaced to the user, no embedded run agent end.

Direct upstream verification

From inside the gateway container (so same network, same env), identical requests to the same endpoints succeed cleanly in 1-3s. Example for Kimi:

docker compose exec openclaw bash -c 'curl -s -X POST https://api.moonshot.ai/v1/chat/completions \
  -H "Authorization: Bearer $KIMI_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"kimi-k2.6\",\"messages\":[{\"role\":\"user\",\"content\":\"pong\"}],\"max_tokens\":500}"'

# Returns ~2.6s, valid JSON, choices[0].message.content="pong",
# choices[0].message.reasoning_content="<chain of thought>"

For MiniMax M2.5 via OR (also tested raw bytes):

HTTP/2 200
content-type: application/json
{first 5 lines whitespace/keep-alive padding}
{"id":"gen-…","object":"chat.completion","model":"minimax/minimax-m2.5-…",
 "choices":[{"message":{"content":"Pong! 🎯",
   "reasoning":"<thinking>","reasoning_details":[…]}}]}

So:

• Network works
• Auth works
• Models return valid responses
• Responses include reasoning content (reasoning_content for Kimi, reasoning+reasoning_details for OR-routed models)

Hypotheses (untested, leaving for the team)

1. The openai-completions adapter cannot exit its response-read loop when the response includes reasoning fields, regardless of whether reasoning: true|false is declared in our config
2. Streaming framing mismatch: adapter expects a specific SSE pattern that reasoning models don't follow; non-reasoning models eventually emit it (hence OR auto returning at 17min instead of never)
3. Per #71160, follow-up turns require sending reasoning_content back, but the adapter doesn't preserve it — causing later validation hangs (we wouldn't be triggering this since we're hitting first-turn hangs)
4. Per #69902, adapter doesn't forward provider-specific "disable reasoning" parameters (thinking: false for Kimi, think: false for Ollama qwen3) — model always reasons, parser hangs

Workaround currently in place

Reverted primary to anthropic/claude-sonnet-4-6. Anthropic-messages adapter works fine. OpenAI-completions adapter is unusable for any reasoning-enabled model in 2026.4.15.

Why this is high-impact

The openai-completions adapter is the path for nearly every cheap modern alternative to Anthropic — DeepSeek V4 reasoners, GLM-4.x reasoning, Kimi K2.5/K2.6, MiniMax M2.x, Qwen reasoning variants. With reasoning models being the dominant cost-effective frontier tier in mid-2026, this bug effectively blocks OpenClaw users from any modern non-Anthropic primary.

Available for triage

Happy to provide:

• Full server-side logs (sanitized, with my chat IDs / API keys redacted)
• Config dumps before/after each test
• Raw HTTP captures of the upstream responses

Just ping me with what would help.