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.com → xiaomi-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.