openclaw - 💡(How to fix) Fix DeepSeek V4 Flash streaming with reasoning_content always triggers fallback to fallback model [1 comments, 2 participants]

Description

When using deepseek/deepseek-v4-flash as the primary model with fallbacks configured (e.g., minimax-cn/MiniMax-M2.7), every response generation triggers fallback to the fallback model, even though DeepSeek API responds correctly when tested directly.

This happens 100% of the time. The model only works for the first request after a session reset (session_status(model="default")), but falls back immediately on the next response generation.

Steps to Reproduce

1. Configure deepseek/deepseek-v4-flash as primary model with minimax-cn/MiniMax-M2.7 as fallback
2. Session model shows deepseek/deepseek-v4-flash correctly
3. Generate any response (even a simple heartbeat reply)
4. Session model switches to minimax-cn/MiniMax-M2.7
5. session_status(model="default") resets back to deepseek, but next response falls back again

Evidence

DeepSeek API is healthy

• Direct curl to DeepSeek streaming API: 10/10 requests succeed
• Latency: TTFB 0.09-0.22s
• Auth state shows errorCount=0, no cooldown

No fallback logs

• No "model-fallback/decision" log entries for the failing requests
• No timeout/auth errors logged
• The fallback happens silently with zero log evidence

Session status pattern

Before:

Model: deepseek/deepseek-v4-flash (1M context)

After same-turn HEARTBEAT_OK:

Model: minimax-cn/MiniMax-M2.7 (200K context)

DeepSeek streaming format

DeepSeek V4 Flash outputs reasoning tokens before visible content. The streaming chunks have:

// First chunk
{"delta":{"content":null,"reasoning_content":""}}
// During reasoning
{"delta":{"content":null,"reasoning_content":"thinking..."}}
// Final content
{"delta":{"content":"answer","reasoning_content":null}}

The reasoning_content field is a DeepSeek-specific extension of OpenAI streaming. delta.content is null during the thinking phase.

Suspected Root Cause

OpenClaw's OpenAI-completions streaming parser may not handle delta.content: null during streaming chunks, interpreting it as a stream error rather than "content not yet available". This would cause fallback on every request with reasoning-enabled models.

Notably, direct user chat works fine - the issue only manifests during automated/system event responses (heartbeat), suggesting different code paths for streaming parsing.

Environment

• OpenClaw: 2026.4.26
• Runtime: Pi Default
• Model: deepseek/deepseek-v4-flash (openai-completions API)
• Fallback: minimax-cn/MiniMax-M2.7
• Auth: api_key