openclaw - 💡(How to fix) Fix [Bug]: Custom MiMo Token Plan provider fails after upgrading to 2026.5.12, rollback to 2026.3.23 restores chat channels

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading OpenClaw to 2026.5.12, WeChat, WeCom, and Feishu chat channels using a custom OpenAI-compatible Xiaomi MiMo Token Plan provider started failing with a generic "Something went wrong" user-visible error. Rolling back to OpenClaw 2026.3.23 restored the same provider and channels.

Steps to reproduce

1. Run OpenClaw on Ubuntu with a custom OpenAI-compatible provider configured for Xiaomi MiMo Token Plan.
2. Use custom_mimo/mimo-v2.5-pro as the default model.
3. Connect chat channels: WeChat/openclaw-weixin, WeCom, and Feishu.
4. Verify that simple prompts work before upgrading.
5. Upgrade OpenClaw to 2026.5.12.
6. Send normal prompts in existing multi-turn or tool-enabled chat sessions.
7. Observe the user-visible error: "⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session."
8. Roll back to OpenClaw 2026.3.23.
9. Observe that the same provider and chat channels work again.

Expected behavior

The same custom OpenAI-compatible provider and model that worked before the upgrade should continue to handle normal multi-turn chat and tool-enabled session history after upgrading.

Actual behavior

After upgrading to 2026.5.12, WeChat, WeCom, and Feishu conversations returned the user-visible error:

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

The issue appeared after the upgrade and recovered after rolling back to 2026.3.23 while keeping the same custom_mimo/mimo-v2.5-pro provider setup.

OpenClaw version

First known bad: 2026.5.12 Known good after rollback: 2026.3.23 (ccfeecb)

Operating system

Ubuntu Linux on Tencent Cloud Lighthouse server Kernel: Linux 6.8.0-71-generic x86_64 Node.js: v22.22.1 pnpm: 10.32.1

Install method

pnpm global / systemd user service

Model

custom_mimo/mimo-v2.5-pro

Provider / routing chain

OpenClaw -> custom OpenAI-compatible provider -> Xiaomi MiMo Token Plan endpoint -> mimo-v2.5-pro

Additional provider/model setup details

The provider is intentionally custom because this deployment uses Xiaomi MiMo Token Plan, not the normal Xiaomi API billing endpoint.

Redacted endpoint: https://token-plan-cn.xiaomimimo.com/v1

The built-in Xiaomi/MiMo provider configuration appears to target the normal API endpoint, so replacing the custom provider with the built-in provider is not equivalent for this deployment.

No API keys, tokens, account IDs, or full openclaw.json contents are included here.

Logs, screenshots, and evidence

User-visible error observed in WeChat, WeCom, and Feishu after upgrading to 2026.5.12:

⚠️ Something went wrong while processing your request. Please try again, or use /new to start a fresh session.

Known-good after rollback:

OpenClaw 2026.3.23 (ccfeecb)
Gateway Health: OK
Feishu: ok
openclaw-weixin: configured
WeCom: ok

After rollback to 2026.3.23, direct model tests succeeded:
- simple reply test succeeded
- system date tool call test succeeded
- follow-up after tool call succeeded

After rollback, no further provider/model/schema errors were observed in checked logs:
- provider rejected
- Param Incorrect
- LLM request failed

Impact and severity

Affected channels: WeChat, WeCom, Feishu. Affected provider: custom OpenAI-compatible Xiaomi MiMo Token Plan provider. Severity: High for this deployment because all primary chat channels became unreliable after the upgrade. Frequency: repeatedly observed after the upgrade; recovered after rollback. Consequence: chat-channel use of OpenClaw became unreliable, especially in multi-turn/tool-history sessions.

Additional information

This may be related to provider-specific tool/schema payload normalization for custom OpenAI-compatible providers.

I do not have the exact redacted 2026.5.12 request payload captured yet, but the version boundary and rollback behavior were clearly observed.

The deployment currently remains on 2026.3.23 as a workaround because 2026.5.12 caused the observed channel failures, while 2026.3.8 was too old for the existing WeChat/WeCom channel plugins.

I can provide additional redacted logs if maintainers indicate which subsystem or log level is most useful.