[Compatibility] Xiaomi MiMo v2.5 fails on 2.12.0 with invalid tool calls and an incorrect reasoning ladder

[MAOKO1993]

Client or integration

Codex App

Provider or upstream service

Xiaomi MiMo

OpenCodex version

2.12.0

Endpoint or capability

/v1/chat/completions · streaming tool calls · reasoning_effort

Current behaviour

On OpenCodex 2.12.0, Codex App cannot complete even a plain-text turn through a custom Xiaomi MiMo provider using the official OpenAI-compatible Chat endpoint.

Two failures are reproducible:

1. The generated Codex catalog advertises low, medium, high, xhigh, max, and ultra for xiaomi-mimo/mimo-v2.5. Selecting max sends that value upstream, but MiMo rejects it because the endpoint only accepts none, low, medium, or high.
2. After switching the same thread to medium, the request streams for several seconds and then OpenCodex terminates it with upstream response contained invalid tool calls.

No assistant message is delivered to Codex App. This reproduces with the plain prompt: 晚上好，你用的什么模型 ("Good evening, which model are you?").

Expected behaviour

A plain-text Codex App turn through xiaomi-mimo/mimo-v2.5 should complete with a visible assistant response.

The catalog must not advertise reasoning efforts that the selected Xiaomi endpoint rejects. If the endpoint supports only up to high, higher Codex effort labels should either be omitted or safely clamped according to an explicit provider contract.

If MiMo emits a non-conforming tool_calls streaming frame, OpenCodex should preserve the fail-closed behavior but provide enough redacted diagnostics to identify the incompatible nested shape, and apply a provider-specific normalization only when it is semantically safe.

Minimal redacted request or reproduction

Redacted provider configuration:


{
  "providers": {
    "xiaomi-mimo": {
      "adapter": "openai-chat",
      "baseUrl": "https://api.xiaomimimo.com/v1",
      "authMode": "key",
      "defaultModel": "mimo-v2.5",
      "liveModels": true,
      "disabled": false
    }
  }
}


Steps:

1. Start OpenCodex 2.12.0 on macOS and sync the catalog into Codex App.
2. Select `xiaomi-mimo/mimo-v2.5`.
3. Set reasoning effort to `max` and send: `晚上好，你用的什么模型`.
4. Observe the upstream 400 validation error.
5. Roll back the failed turn, set effort to `medium`, and send the same prompt.
6. Observe that the stream ends with `upstream response contained invalid tool calls`.

Codex App version observed: `0.147.0-alpha.6.5`.
No credentials, account identifiers, or request bodies containing secrets are included.

Actual response or error

With `reasoning_effort=max`:


Provider error 400: prefill failed: Input should be 'none', 'low', 'medium' or 'high'; input: 'max'


With `reasoning_effort=medium`:


stream disconnected before completion: Provider stream error: upstream response contained invalid tool calls


The exact malformed upstream `delta.tool_calls` shape is not persisted in the Codex session log, so this report does not claim whether it was a non-array value, a null element, or another invalid nested shape.

Upstream documentation

Xiaomi MiMo OpenAI-compatible Chat API:
https://platform.xiaomimimo.com/docs/en-US/api/chat/openai-api

OpenCodex issue #1325 documents the new fail-closed nested tool_calls validation and explicitly notes that no live provider evidence was available at filing time:
#1325

Suggested mapping or implementation notes

• Add or reuse a registry-owned contract for the official public Xiaomi endpoint https://api.xiaomimimo.com/v1.
• Advertise only low, medium, and high, or map xhigh/max/ultra to high, matching the existing MiMo token-plan compatibility contract where appropriate.
• Capture the invalid nested field category in redacted provider diagnostics without recording tool arguments or credentials.
• Add a live-route or deterministic adapter regression case for MiMo streaming tool-call frames.
• Do not silently drop a claimed tool call; normalize only a documented benign provider shape.

Additional context and attachments

Regression evidence:

• The same custom provider and xiaomi-mimo/mimo-v2.5 completed Codex App turns successfully on OpenCodex 2.10.1.
• The current failure was reproduced repeatedly on 2.12.0 with both max and medium.
• No existing issue matched the repository search: mimo "invalid tool calls".

Related:

• [Bug] Nested field shapes bypass the #1219 frame guard and crash both adapter paths #1325: nested OpenAI Chat tool_calls shapes now fail closed.
• [Bug] Xiaomi MiMo token-plan rejects Responses custom tools (400 responses_feature_not_supported) — works fully via openai-chat adapter; add preset/guidance #1158: MiMo token-plan preset on the Chat wire. This report uses the official public OpenAI-compatible endpoint through an existing custom provider, not the token-plan preset.

Checks

• I searched existing provider and compatibility issues.
• The request and response were redacted.
• The expected behaviour is based on an upstream specification or a concrete client requirement.

[Ingwannu]

Confirmed on current dev (849ab5e35) that the reasoning half is a real registry gap. The official public OpenAI-compatible destination https://api.xiaomimimo.com/v1 has no registry-owned Chat contract, so a provider named xiaomi-mimo remains generic and can advertise/send the default max/ultra tiers even though the upstream error proves this route accepts only none, low, medium, or high.

I am taking the bounded fix first:

• add a fixed-destination xiaomi-mimo Chat preset for the official public endpoint;
• expose only low, medium, and high for mimo-v2.5;
• clamp direct xhigh/max/ultra requests to high;
• preserve any same-named provider that points at a different destination, so an existing custom key is never retargeted;
• cover the catalog ladder, wire mapping, destination ownership boundary, registry parity, and provider documentation.

I am not normalizing the tool_calls failure from the error string alone. The current parser is intentionally fail-closed, and treating an unknown malformed value as benign could silently drop or mis-bind a tool call. Please provide one redacted failing delta.tool_calls frame, or at minimum the nested category (non-array tool_calls, null/non-object member, invalid/missing index, invalid function, etc.). Tool arguments and all credentials can remain removed. Once the actual shape is known, it can be handled in a separate provider-specific regression without weakening the shared validator.

I will publish the proven ladder fix as a draft PR to dev after focused tests, typecheck, privacy scan, and the relevant docs build. This issue should remain open for the second failure until we have the frame evidence or a live MiMo canary.

[Ingwannu]

Draft PR #1485 is now open against dev at exact head 945d1718a:

#1485

It implements only the proven reasoning-ladder correction for Xiaomi's official public Chat endpoint: the picker advertises low/medium/high, direct xhigh/max/ultra requests clamp to high, and a same-named custom provider at another destination keeps its original URL and key boundary.

The PR also records the canonical-preset evidence required by repository policy: Xiaomi's official Chat reference, service agreement and privacy policy, the named operating entities, the first-party/non-aggregator boundary, the 2026-08-11 verification date, and @Ingwannu as the OpenCodex maintenance owner.

Local validation completed: focused provider tests 41/41, workspace rail 6/6, typecheck, privacy scan, and the 265-page docs build. The full suite produced 11,047 passes and two unrelated environment/load failures; both failed files passed together in a clean focused rerun, 82/82. Exact-head GitHub CI is now running.

The malformed delta.tool_calls half deliberately remains open. Please attach one redacted failing frame or its nested failure category before we add provider-specific normalization; the draft does not weaken the shared fail-closed validator.

[MAOKO1993]

Thanks for the confirmation and draft PR.

I checked the retained records for the exact failing turns. The historical evidence confirms repeated failures, but it does not preserve the malformed delta.tool_calls frame, so I cannot honestly classify the nested shape yet.

Redacted retained evidence (OpenCodex 2.12.0, xiaomi-mimo/mimo-v2.5, requested/effective effort medium):

• ocx-msosgfxx-tc: HTTP 400 terminal after 6106 ms
• ocx-msosp4fj-9: HTTP 400 terminal after 4391 ms
• ocx-msosphu4-e: HTTP 400 terminal after 890 ms

All three record: Provider stream error: upstream response contained invalid tool calls.

usage.jsonl retains only the terminal classification and request metadata. The Codex session JSONL retains only the propagated error. Provider/raw-SSE debugging was not enabled during those turns, so neither file contains the original delta.tool_calls value. I therefore cannot claim non-array, null/non-object member, missing/invalid index, or invalid function from the historical evidence.

Please confirm the preferred current safe capture path (for example, the supported provider-debug command or flag) that records the offending frame while allowing tool arguments and credentials to be removed. I can then reproduce once and attach a redacted structural frame. A structural diagnostic that logs only the value type, array/member shape, index, and function key presence would also provide the required evidence without exposing arguments.

[MAOKO1993]

Follow-up after upgrading/restarting and reproducing again.

The actual running binary reports:

opencodex 2.12.0

A fresh Codex App task on 2026-08-12 failed after 21.624 seconds with:

stream disconnected before completion: Provider stream error: upstream response contained invalid tool calls

The proxy made six Xiaomi MiMo attempts between 09:54:06 and 09:54:24 CST, all using xiaomi-mimo/mimo-v2.5 through openai-chat, with requested/effective reasoning_effort=medium:

• ocx-mspfrhu4-1 — 3006 ms
• ocx-mspfrkcd-3 — 1199 ms
• ocx-mspfrlm7-4 — 915 ms
• ocx-mspfrn0i-5 — 2402 ms
• ocx-mspfrq6m-6 — 3394 ms
• ocx-mspfrv9e-7 — 699 ms

Every attempt terminated with HTTP 400 / invalid_request_error and the same proxy classification: upstream response contained invalid tool calls.

I also checked the fresh usage.jsonl, service.log, and the Codex task record. Even after this upgrade/reproduction, none of them records the offending upstream delta.tool_calls value or its structural failure category. Therefore I still cannot truthfully classify it as non-array tool_calls, a null/non-object member, an invalid/missing index, or an invalid function object.

This fresh reproduction confirms that the second failure remains present on the released 2.12.0 binary, but the current retained diagnostics are insufficient to provide the redacted frame requested above. Please point me to the supported provider/raw-SSE diagnostic command or flag, if one exists. Otherwise, a redacted structural diagnostic at the fail-closed validation point (value type, array/member type, index validity, and function object/key presence only; no arguments or credentials) appears necessary to collect the provider-specific evidence safely.

[Ingwannu]

The supported diagnostic path is provider debug, but you are correct that the current generic frame-drop breadcrumb does not retain the structural reason for this specific delta.tool_calls rejection.

You can enable and follow the existing redacted provider log with:

ocx debug provider on
ocx debug provider logs -f

After one reproduction, disable it again with:

ocx debug provider off

The current implementation intentionally redacts payload contents and records only generic provider diagnostics. It will not reveal API keys or raw tool arguments, but today it may still report only upstream response contained invalid tool calls, so another reproduction without a structural diagnostic may not add useful evidence.

I therefore treat the fresh 2.12.0 reproduction as confirmation that the second defect remains real, while its exact upstream shape is still unclassified. I will not guess at a permissive parser fix. The safe next code change is a bounded diagnostic at the fail-closed validator that records only a reason code and structural facts (for example: tool_calls value type, member type, integer index validity, and whether function.name/function.arguments have valid types), never the argument value, request body, bearer, or account data. That diagnostic should land separately from the reasoning-ladder PR #1485; the malformed-frame behavior remains open here until the captured reason supports an exact compatibility mapping.

[Ingwannu]

Draft PR #1530 now adds the missing bounded diagnostic on current dev at exact head fdb26c61ac0afba702788cc03a11f409c5c82fc9.

It does not relax the parser or claim a Xiaomi-specific wire mapping. With provider debug enabled, an existing fail-closed rejection now records only:

• mode: stream or response;
• a finite structural reason code;
• the array member index when relevant;
• the JavaScript value type.

It never serializes the tool-call ID, function name, arguments, request body, bearer, or account data, and diagnostics remain disabled by default. Focused adapter/debug tests pass 66/66; typecheck, privacy scan, and diff check pass. The PR remains draft pending exact-head CI and independent review.

Once a build containing #1530 is available, one redacted reproduction with ocx debug provider on / ocx debug provider logs -f should provide the evidence needed for an exact compatibility fix here.