openclaw - ✅(Solved) Fix [Bug] Xiaomi MiMo reasoning_content passthrough missing for multi-turn tool calls [2 pull requests, 3 comments, 3 participants]

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…
GitHub stats
openclaw/openclaw#81419Fetched 2026-05-14 03:32:25
View on GitHub
Comments
3
Participants
3
Timeline
7
Reactions
2
Timeline (top)
cross-referenced ×4commented ×3

Root Cause

Root cause In @earendil-works/pi-ai detectCompat(), requiresReasoningContentOnAssistantMessages is only true for DeepSeek. MiMo uses the same protocol (thinking format deepseek) but is not recognized.

Fix Action

Fixed

PR fix notes

PR #81573: fix(compat): add Xiaomi MiMo detection for deepseek thinking format

Description (problem / solution / changelog)

Summary

Fixes #81419

Xiaomi MiMo models (mimo-v2.5, mimo-v2.5-pro) use the same thinking protocol as DeepSeek (reasoning_content on assistant messages), but were not recognized by the compat detection logic. This caused 400 Param Incorrect errors on multi-turn tool calls because reasoning_content was missing from assistant messages.

Root Cause

In src/agents/openai-completions-compat.ts, resolveOpenAICompletionsCompatDefaults() only recognized DeepSeek for thinkingFormat: "deepseek". MiMo uses the same protocol but was falling through to the default "openai" format.

Fix

Add isXiaomiMiMo detection matching providers xiaomi and xiaomi-coding, and include it in:

  1. thinkingFormat → set to "deepseek" (same protocol as DeepSeek)
  2. isNonStandard → MiMo needs non-standard handling for store/developer-role compat

Note on reasoning_content passthrough

This PR addresses the compat detection layer. The ensureDeepSeekV4AssistantReasoningContent() function in provider-stream-shared.ts handles injecting empty reasoning_content fields — the maintainer may want to consider generalizing that wrapper for all thinkingFormat: "deepseek" providers in a follow-up, since MiMo has the same requirement.

Testing

  • Code reviewed line-by-line against the existing DeepSeek detection pattern
  • Logic verified: isXiaomiMiMo correctly mirrors isDeepSeek pattern
  • Cannot test with actual MiMo API (no key), but the change is structurally identical to existing working DeepSeek detection

AI-assisted

This PR was written with AI assistance. I have reviewed and understand every line of the change.

Changed files

  • src/agents/openai-completions-compat.ts (modified, +7/-2)

PR #81589: fix(xiaomi): MiMo reasoning models fail multi-turn tool calls (#81419)

Description (problem / solution / changelog)

Fix: Xiaomi MiMo reasoning models fail on multi-turn tool calls

Closes #81419

Summary

Xiaomi MiMo reasoning models (mimo-v2-pro, mimo-v2-omni, mimo-v2.5, mimo-v2.5-pro) return 400 Param Incorrect ("provider rejected the request schema or tool payload") on any turn that replays a prior assistant message — for example the second turn of a tool-call conversation. MiMo uses the same OpenAI-compatible reasoning wire format as DeepSeek V4 and requires reasoning_content on every assistant message in the request payload. OpenClaw was never adding that field for MiMo.

The fix mirrors the existing DeepSeek V4 plumbing:

  1. xiaomi-native is now a first-class endpoint class (src/agents/provider-attribution.ts) and recognized in isKnownNativeEndpoint. Manifest-driven host resolution maps the bundled host plus the three regional token-plan-*.xiaomimimo.com hosts (used by self-hosted/custom MiMo proxies) to that class.
  2. OpenAI-completions compat detection (src/agents/openai-completions-compat.ts) now sets thinkingFormat: "deepseek" and requiresReasoningContentOnAssistantMessages: true for xiaomi-native endpoints, alongside the existing DeepSeek path.
  3. The bundled xiaomi plugin (extensions/xiaomi/) registers wrapStreamFn, resolveThinkingProfile, isModernModelRef, and buildProviderReplayFamilyHooks({ family: "openai-compatible", dropReasoningFromHistory: false }) — same shape as the DeepSeek plugin. Two new local helpers (thinking.ts, stream.ts) reuse the shared createDeepSeekV4OpenAICompatibleThinkingWrapper SDK helper rather than copying its logic.
  4. Core fallback wrapper for "unowned" proxies (src/agents/pi-embedded-runner/extra-params.ts). When MiMo reasoning models are reached through a custom/proxy provider (e.g. a user-configured xiaomi-orbit provider pointing at token-plan-ams.xiaomimimo.com), the bundled xiaomi plugin's wrapStreamFn does not match. Core already has the same fallback pattern for DeepSeek V4 in this file; this PR adds the parallel MiMo matcher so the shared wrapper fires there too.

What we found

Original bug

User reported FailoverError: LLM request failed: provider rejected the request schema or tool payload. (400 Param Incorrect) when running mimo-v2.5-pro on a custom xiaomi-orbit provider pointed at https://token-plan-ams.xiaomimimo.com/v1. The failure consistently fired on the second model turn — i.e., the one that includes a replayed assistant message + tool result.

Root cause: pi-ai's openai-completions message converter does not inject reasoning_content: "" on assistant messages for MiMo because OpenClaw never marked MiMo as a DeepSeek-style reasoning provider. The DeepSeek bundled plugin handles this via a wrapStreamFn that calls ensureDeepSeekV4AssistantReasoningContent on every outgoing payload. MiMo had no equivalent.

Code review findings (addressed in this PR)

A pre-PR self-review surfaced four issues, all fixed before this PR was opened:

  • Speculative model entries removed. An earlier draft added mimo-v2.5-flash, mimo-v2.5, and mimo-v2.5-pro to the bundled catalog without confirming those IDs exist on Xiaomi's official api.xiaomimimo.com. The bundled manifest in this PR only ships the existing officially-documented models (mimo-v2-flash, mimo-v2-pro, mimo-v2-omni). The reasoning detection set in extensions/xiaomi/thinking.ts still recognizes the v2.5 IDs, so users who configure those via a custom provider (the bug-report case) still get correct reasoning treatment.
  • xiaomi-native added to isKnownNativeEndpoint in src/agents/provider-attribution.ts. Matches the DeepSeek/xAI/zAI pattern.
  • xiaomi-native added to isNonStandard in src/agents/openai-completions-compat.ts. Functionally consistent with the DeepSeek precedent.
  • Host-resolution coverage test added in src/agents/provider-attribution.test.ts to lock in the *.xiaomimimo.comxiaomi-native mapping.

Live verification

After the first round of fixes (commits 1-7) the live test still failed: pi-ai does not actually read requiresReasoningContentOnAssistantMessages (the field appears only in pi-ai's static models.generated.js, not in any logic), and the bundled plugin's wrapStreamFn only fires when model.provider === "xiaomi" — not for the user's xiaomi-orbit custom provider. The core fallback in applyPostPluginStreamWrappers only matched DeepSeek V4 model IDs.

Commit 10 (64df7f12dd) added the MiMo matcher to the core fallback so the shared DeepSeek-style wrapper fires for MiMo reasoning IDs on any provider, including custom proxy providers. Live test then passed.

Tests

  • 13/13 pass in src/agents/openai-completions-compat.test.ts (5 new xiaomi cases)
  • 8/8 pass in new extensions/xiaomi/index.test.ts (auth, catalog, replay policy, thinking profile, isModernModelRef, reasoning_content injection across thinking-on / thinking-off / cross-provider replay)
  • New host-resolution assertions in src/agents/provider-attribution.test.ts
  • pnpm build clean
  • pnpm check:changed clean (lint, typecheck, import cycles)

Real Behavior Proof

Behavior addressed: Xiaomi MiMo reasoning models (mimo-v2.5-pro on a xiaomi-orbit custom provider pointed at https://token-plan-ams.xiaomimimo.com/v1) returning 400 Param Incorrect on any multi-turn / tool-call conversation. Reproduced before the fix; verified fixed after the fix.

Real environment tested: Linux desktop, OpenClaw gateway built from this branch (fix/mimo-reasoning-content), run via pnpm dev gateway --force on the same port (18789) the user normally uses, exercised through the live Telegram channel against a real MiMo backend with a real API key.

Exact steps or command run after this patch: Stopped the systemd-installed openclaw gateway, then started a dev gateway from this branch on the same port the user normally uses. Then, through the user's normal Telegram chat client, sent a message that selects xiaomi-orbit / mimo-v2.5-pro (reasoning enabled), prompts a web_search tool call, and requires a follow-up model turn after the tool result. Exact commands:

systemctl --user stop openclaw-gateway
OPENCLAW_GATEWAY_PORT=18789 OPENCLAW_ALLOW_OLDER_BINARY_DESTRUCTIVE_ACTIONS=1 pnpm dev gateway --force

Evidence after fix (relevant log lines, gateway log /tmp/openclaw/openclaw-2026-05-13.log):

2026-05-13T20:04:02.327-05:00 [gateway] log file: /tmp/openclaw/openclaw-2026-05-13.log
2026-05-13T20:04:02.560-05:00 [gateway] ready
2026-05-13T20:04:25.330-05:00 [ws] webchat connected
2026-05-13T20:04:56.414-05:00 [diagnostic] phase=channels.telegram.start-account
  work=[active=agent:main:main(processing/model_call,q=1,age=12s last=model_call:started) ...]
2026-05-13T20:05:15.546-05:00 [tools] web_search failed: Ollama web search authentication failed.
  raw_params={"query":"Esperanto language overview history","count":5,"freshness":"year"}
2026-05-13T20:05:52.507-05:00 [tools] web_search failed: Ollama web search authentication failed.
  raw_params={"query":"Esperanto language history overview facts","count":5,"language":"en"}

Pre-fix evidence (same gateway, same user, same provider, before the wrapper was wired):

2026-05-13T19:55:04.005-05:00 embedded_run_agent_end isError=true
  error="LLM request failed: provider rejected the request schema or tool payload."
  failoverReason=format model=mimo-v2.5-pro provider=xiaomi-orbit
  rawErrorPreview="400 Param Incorrect" providerRuntimeFailureKind=schema
2026-05-13T19:55:04.090-05:00 model_fallback_decision decision=candidate_failed
  requestedProvider=xiaomi-orbit requestedModel=mimo-v2.5-pro
  attempt=1 reason=format status=400 errorPreview="400 Param Incorrect"

Observed result after fix: The MiMo agent received the prompt, emitted a tool call (web_search for "Esperanto language overview history"), received the tool result, then continued the conversation and emitted a second tool call (web_search for "Esperanto language history overview facts"). That second tool call requires the model to receive the prior assistant message + tool result and reason about a new request — exactly the multi-turn scenario the bug regressed. No FailoverError, no 400 Param Incorrect, no provider rejected the request schema in the log after the fix went live.

The web_search failed: Ollama web search authentication failed messages are an unrelated user-side configuration issue (Ollama needs ollama signin) — they show that the model did successfully emit valid tool-use payloads to the gateway and the gateway invoked the tool plugin.

What was not tested:

  • Bundled xiaomi provider against api.xiaomimimo.com directly. The user only currently has a xiaomi-orbit custom provider configured. The bundled-provider path is exercised by the new unit tests in extensions/xiaomi/index.test.ts (auth, catalog, thinking profile, reasoning_content injection), but no live API hit. The core fallback wrapper test (pi-embedded-runner-extraparams.test.ts style) is logically covered by the existing DeepSeek "unowned proxy" precedent.
  • TTS path unchanged and not re-verified live (the bundled xiaomi.live.test.ts for TTS is unmodified by this PR).
  • DeepSeek behavior: not retested live in this session; protected by existing tests and unchanged code paths.

AI assistance

This PR was developed with Claude Sonnet 4.6 acting as a coding agent over a single working session, driving edits, builds, and tests through Claude Code. After the initial implementation, a self-review pass (also via Claude Sonnet 4.6) identified the four issues listed under "Code review findings" above; all four were fixed before this PR was opened. The live verification step caught a remaining gap (the compat-flag plumbing alone does not fix the bug because pi-ai does not consume that field) which was then resolved by adding the core fallback wrapper.

The human author (Jim Dawdy) reviewed the plan and the final diffs, supplied live API credentials and gateway access for real-environment proof, ran the Telegram chat that produced the post-fix evidence above, and is the named contributor for this change. All blame falls on human shoulders.

Changed files

  • extensions/xiaomi/index.test.ts (added, +315/-0)
  • extensions/xiaomi/index.ts (modified, +10/-0)
  • extensions/xiaomi/openclaw.plugin.json (modified, +11/-0)
  • extensions/xiaomi/stream.ts (added, +14/-0)
  • extensions/xiaomi/thinking.ts (added, +37/-0)
  • src/agents/openai-completions-compat.test.ts (modified, +52/-0)
  • src/agents/openai-completions-compat.ts (modified, +14/-7)
  • src/agents/openai-transport-stream.ts (modified, +5/-0)
  • src/agents/pi-embedded-runner/extra-params.ts (modified, +27/-0)
  • src/agents/provider-attribution.test.ts (modified, +16/-0)
  • src/agents/provider-attribution.ts (modified, +3/-0)
RAW_BUFFERClick to expand / collapse

Describe the bug OpenClaw returns 400 when using Xiaomi MiMo models (mimo-v2.5, mimo-v2.5-pro) with thinking mode enabled and multi-turn tool calls. The model requires reasoning_content field on assistant messages that contain tool_calls, but OpenClaw does not include it.

To Reproduce

  1. Set agent model to xiaomi-coding/mimo-v2.5 with thinking enabled.
  2. Have a multi-turn conversation where the assistant makes tool calls.
  3. Subsequent user turns will fail with 400 Param Incorrect.

Expected behavior All assistant messages with tool_calls should include the reasoning_content field (even if empty) when sending request to MiMo API.

Root cause In @earendil-works/pi-ai detectCompat(), requiresReasoningContentOnAssistantMessages is only true for DeepSeek. MiMo uses the same protocol (thinking format deepseek) but is not recognized.

Possible solution Add MiMo detection in detectCompat (match provider xiaomi / xiaomi-coding or baseUrl xiaomimimo.com) and set requiresReasoningContentOnAssistantMessages and thinkingFormat accordingly.

Environment

  • OpenClaw version: 2026.5.12-beta.4
  • Model: mimo-v2.5, mimo-v2.5-pro
  • Platform: Windows / Node 24+

References:

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…

Still need to ship something?

×6

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

Back to top recommendations

TRENDING