openclaw - 💡(How to fix) Fix [Bug]: Custom Xiaomi/MiMo provider reasoning models completely broken after 2026.5.x update

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

After updating from OpenClaw 2026.4.29 to 2026.5.12, custom Xiaomi MiMo provider (xiaomi-coding) with reasoning models (mimo-v2.5, mimo-v2.5-pro) no longer works at all. Previously, these models would occasionally produce empty responses requiring a /new reset, but were functional. After the update, every attempt to use these models results in [assistant turn failed before producing content] and the gateway becomes unresponsive.

Error Message

  1. [assistant turn failed before producing content] error

Root Cause

MiMo reasoning models return their complete response in the reasoning_content field with an empty content field (both streaming and non-streaming). This is the same protocol as DeepSeek V4.

The 2026.5.x changelog includes changes that classify reasoning-only responses as invalid terminal runs:

  • Fixes #73115: "classify empty, reasoning-only, and planning-only terminal agent runs before accepting a model fallback candidate, so invalid or incompatible models can advance to the next configured fallback instead of returning a 30-second terminal failure"
  • Fixes #74409: "honor explicit silentReply.direct: "allow" for clean empty or reasoning-only direct chat turns"

While these changes correctly handle reasoning-only as a failure case for known providers (DeepSeek has special handling), custom OpenAI-compatible providers like xiaomi-coding with reasoning: true models fall into the generic "reasoning-only = failure" path without the DeepSeek-specific recovery logic.

Fix Action

Fix / Workaround

Workarounds attempted

  1. reasoning: false — MiMo API still returns reasoning_content regardless
  2. compat.thinkingFormat: "deepseek" — The flag is read but the stream processing path for custom providers does not use it to route reasoning_content as visible text
  3. compat.requiresThinkingAsText: true — Flag exists in schema but is never consumed anywhere in the codebase (only assigned, never read)
  4. enable_thinking: false in request payload — MiMo v2.5 API ignores this parameter
  5. Only working workaround: Use a different model (e.g., DeepSeek V4)

Code Example

{
  "choices": [{
    "message": {
      "content": "",
      "reasoning_content": "The actual response text is here"
    }
  }]
}
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked in 2026.4.29, broken in 2026.5.12)

Summary

After updating from OpenClaw 2026.4.29 to 2026.5.12, custom Xiaomi MiMo provider (xiaomi-coding) with reasoning models (mimo-v2.5, mimo-v2.5-pro) no longer works at all. Previously, these models would occasionally produce empty responses requiring a /new reset, but were functional. After the update, every attempt to use these models results in [assistant turn failed before producing content] and the gateway becomes unresponsive.

Root Cause Analysis

MiMo reasoning models return their complete response in the reasoning_content field with an empty content field (both streaming and non-streaming). This is the same protocol as DeepSeek V4.

The 2026.5.x changelog includes changes that classify reasoning-only responses as invalid terminal runs:

  • Fixes #73115: "classify empty, reasoning-only, and planning-only terminal agent runs before accepting a model fallback candidate, so invalid or incompatible models can advance to the next configured fallback instead of returning a 30-second terminal failure"
  • Fixes #74409: "honor explicit silentReply.direct: "allow" for clean empty or reasoning-only direct chat turns"

While these changes correctly handle reasoning-only as a failure case for known providers (DeepSeek has special handling), custom OpenAI-compatible providers like xiaomi-coding with reasoning: true models fall into the generic "reasoning-only = failure" path without the DeepSeek-specific recovery logic.

Environment

  • OpenClaw version: 2026.5.12 (f066dd2)
  • Previous working version: 2026.4.29
  • Provider: custom xiaomi-coding (baseUrl: https://token-plan-cn.xiaomimimo.com/v1)
  • Models: mimo-v2.5, mimo-v2.5-pro
  • OS: WSL2 Ubuntu on Windows 11
  • GPU: NVIDIA RTX 4080

Expected behavior

MiMo reasoning models should work like DeepSeek models: reasoning_content should be recognized as a valid response format, either by:

  1. Detecting the xiaomi-coding provider (or any xiaomimimo.com baseUrl) as DeepSeek-thinking-format compatible, OR
  2. Allowing compat.thinkingFormat: "deepseek" on custom providers to properly route reasoning_content through the DeepSeek-compatible stream processing path, OR
  3. Implementing the requiresThinkingAsText compat flag (currently defined in schema but not used anywhere in the codebase)

Actual behavior

Every request to MiMo reasoning models results in:

  1. Model returns full response in reasoning_content, content is empty
  2. OpenClaw classifies this as a "reasoning-only" terminal failure
  3. [assistant turn failed before producing content] error
  4. Gateway becomes unresponsive, requires manual reset

Steps to reproduce

  1. Configure a custom xiaomi-coding provider with baseUrl: https://token-plan-cn.xiaomimimo.com/v1
  2. Add models with reasoning: true (e.g., mimo-v2.5)
  3. Switch to the model
  4. Send any message
  5. Observe: gateway hangs with [assistant turn failed before producing content]

API response example (confirming the model works fine outside OpenClaw)

{
  "choices": [{
    "message": {
      "content": "",
      "reasoning_content": "The actual response text is here"
    }
  }]
}

Workarounds attempted

  1. reasoning: false — MiMo API still returns reasoning_content regardless
  2. compat.thinkingFormat: "deepseek" — The flag is read but the stream processing path for custom providers does not use it to route reasoning_content as visible text
  3. compat.requiresThinkingAsText: true — Flag exists in schema but is never consumed anywhere in the codebase (only assigned, never read)
  4. enable_thinking: false in request payload — MiMo v2.5 API ignores this parameter
  5. Only working workaround: Use a different model (e.g., DeepSeek V4)

Related issues/PRs

  • #60261 — Original bug report (closed as duplicate of #60304)
  • #60304 — Fix: "Normalize Xiaomi reasoning-only completions" (Open, CI failing, not merged)
  • #60283 — Alternative fix: "disable thinking for MiMo reasoning models" (Closed, abandoned)
  • #81419 — "MiMo reasoning_content passthrough missing for multi-turn tool calls" (Open)
  • #81589 — Fix for #81419 (Open)
  • #81969 — "5.12 strict tool schema injection breaks Xiaomi MiMo custom provider" (Closed, merged via #80738)
  • #73115 — The change that introduced the regression
  • #74409 — Related reasoning-only handling change

Suggested fix

The compat.thinkingFormat: "deepseek" flag should be fully implemented for custom providers. When set, the stream processing should:

  1. Route reasoning_content through the same path as DeepSeek's thinking format
  2. Promote reasoning-only final messages to visible text when requiresThinkingAsText: true
  3. Handle multi-turn reasoning_content replay (as described in #81419)

This would allow any OpenAI-compatible provider using DeepSeek's thinking format to work correctly with OpenClaw, without requiring a dedicated provider plugin.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

MiMo reasoning models should work like DeepSeek models: reasoning_content should be recognized as a valid response format, either by:

  1. Detecting the xiaomi-coding provider (or any xiaomimimo.com baseUrl) as DeepSeek-thinking-format compatible, OR
  2. Allowing compat.thinkingFormat: "deepseek" on custom providers to properly route reasoning_content through the DeepSeek-compatible stream processing path, OR
  3. Implementing the requiresThinkingAsText compat flag (currently defined in schema but not used anywhere in the codebase)

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Custom Xiaomi/MiMo provider reasoning models completely broken after 2026.5.x update