Description
After upgrading to OpenClaw 2026.5.12, the Xiaomi MiMo v2.5 provider (configured as openai-compatible API at token-plan-cn.xiaomimimo.com/v1) started returning HTTP 400 "Param Incorrect" when the agent sends a request with full tool schemas. Before the upgrade, it worked fine.
The error is:
FailoverError: LLM request failed: provider rejected the request schema or tool payload.
Underlying: 400 Param Incorrect | providerRuntimeFailureKind: "schema" | failoverReason: "format"
Root Cause Analysis
The root cause traces to the 2026.5.12 changelog entry:
"Agents: add permissive item schemas to array tool parameters before provider submission, preventing OpenAI-compatible schema validation from rejecting plugin tools that omit items."
This change adds items schemas to array tool parameters. The Xiaomi MiMo API does not accept this extended schema format and returns 400.
Impact
All cron jobs and agent sessions using xiaomi-mimo-tp/mimo-v2.5 as the primary model are affected. The failure is intermittent - some runs succeed while others fail with the same error, suggesting the provider may have varying tolerance for schema payload size/format.
Affected scenarios:
- Isolated cron agent sessions with
tools.profile: "full" (sends all tool definitions)
- Both
mimo-v2.5 and potentially mimo-v2.5-pro models
- Sessions using the full tool payload including exec, read, write, web tools, feishu plugin tools, etc.
Timeline
| Date (Beijing) |
Event |
| May 15, 10:45 |
OpenClaw updated to 2026.5.12 |
| May 16, 09:15 |
First cron failure (morning-briefing) |
| May 16, 09:30 |
Second cron failure (daily-task-plan) |
| May 16 onwards |
All sessions using MiMo v2.5 with full tool schemas fail intermittently |
Log Evidence
{
"event": "embedded_run_agent_end",
"error": "LLM request failed: provider rejected the request schema or tool payload.",
"failoverReason": "format",
"model": "mimo-v2.5",
"provider": "xiaomi-mimo-tp",
"rawErrorPreview": "400 Param Incorrect",
"providerRuntimeFailureKind": "schema"
}
Workaround
Adding a fallback model (e.g. deepseek/deepseek-v4-flash) to cron job payloads bypasses the issue since the fallback model is used when MiMo rejects the request.
Request
Two possible fixes:
- Make the
items schema addition optional or configurable, allowing it to be skipped for providers that don't support it
- Detect schema rejection from the provider response and automatically strip
items from array parameters before retrying
Environment
- OpenClaw version: 2026.5.12
- Provider: Xiaomi MiMo Token Plan (token-plan-cn.xiaomimimo.com/v1)
- Model: mimo-v2.5 (openai-completions API)
- Agent tools profile: full
- Session type: isolated cron agentTurn
Description
After upgrading to OpenClaw 2026.5.12, the Xiaomi MiMo v2.5 provider (configured as
openai-compatibleAPI attoken-plan-cn.xiaomimimo.com/v1) started returning HTTP 400 "Param Incorrect" when the agent sends a request with full tool schemas. Before the upgrade, it worked fine.The error is:
Underlying:
400 Param Incorrect|providerRuntimeFailureKind: "schema"|failoverReason: "format"Root Cause Analysis
The root cause traces to the 2026.5.12 changelog entry:
This change adds
itemsschemas to array tool parameters. The Xiaomi MiMo API does not accept this extended schema format and returns 400.Impact
All cron jobs and agent sessions using
xiaomi-mimo-tp/mimo-v2.5as the primary model are affected. The failure is intermittent - some runs succeed while others fail with the same error, suggesting the provider may have varying tolerance for schema payload size/format.Affected scenarios:
tools.profile: "full"(sends all tool definitions)mimo-v2.5and potentiallymimo-v2.5-promodelsTimeline
Log Evidence
{ "event": "embedded_run_agent_end", "error": "LLM request failed: provider rejected the request schema or tool payload.", "failoverReason": "format", "model": "mimo-v2.5", "provider": "xiaomi-mimo-tp", "rawErrorPreview": "400 Param Incorrect", "providerRuntimeFailureKind": "schema" }Workaround
Adding a fallback model (e.g.
deepseek/deepseek-v4-flash) to cron job payloads bypasses the issue since the fallback model is used when MiMo rejects the request.Request
Two possible fixes:
itemsschema addition optional or configurable, allowing it to be skipped for providers that don't support ititemsfrom array parameters before retryingEnvironment