Summary
Add onboarding sub-choices for Xiaomi MiMo Token Plan regional endpoints (China, Singapore, Europe) with both OpenAI-compatible and Anthropic-compatible protocols, following the existing Z.AI (http://z.ai/) regional onboarding pattern.
Problem to solve
The Xiaomi MiMo provider currently hardcodes a single endpoint (https://api.xiaomimimo.com/v1) for all users, regardless of their plan type or geographic location. This means:
-
Token Plan users are blocked. Xiaomi's Token Plan is a separate billing model from the standard API balance. Users who purchase Token Plan credits have their own dedicated endpoints (token-plan-{cn,sgp,ams}.xiaomimimo.com), but OpenClaw routes all traffic through the API balance endpoint — which does not recognize or consume Token Plan credits. These users cannot use their purchased quota through OpenClaw at all.
-
No regional routing. All requests hit the same endpoint regardless of where the user is located. Users in Europe or Southeast Asia experience unnecessary latency because traffic is not routed to the nearest cluster.
-
No Anthropic compatibility option. Xiaomi's Token Plan clusters also expose Anthropic-compatible protocol endpoints (/anthropic), which could enable Claude-style tool calling and message formats. There is currently no way to select these.
The current onboarding experience offers only xiaomi-api-key, which always configures the same base URL:
Base URL: https://api.xiaomimimo.com/v1
API type: openai-completions
Proposed solution
Add explicit onboarding sub-choices for the Xiaomi MiMo Token Plan, mirroring the pattern already established by the Z.AI (http://z.ai/) provider (which offers zai-coding-global, zai-coding-cn, zai-global, zai-cn).
Token Plan endpoint map:
OpenAI Compatibility Protocol:
Anthropic Compatibility Protocol:
Suggested onboarding choices:
Existing — no change needed
openclaw onboard --auth-choice xiaomi-api-key
Token Plan — OpenAI-compatible
openclaw onboard --auth-choice xiaomi-token-plan-cn
openclaw onboard --auth-choice xiaomi-token-plan-sgp
openclaw onboard --auth-choice xiaomi-token-plan-ams
Token Plan — Anthropic-compatible
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-cn
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-sgp
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-ams
Precedent: The Z.AI (http://z.ai/) provider already implements this exact pattern with regional and plan-based onboarding choices. The same UX and code structure could be reused for Xiaomi. See: https://docs.openclaw.ai/providers/zai
Alternatives considered
Manual models.providers override: Users can manually set baseUrl in their openclaw.json config to point to a Token Plan endpoint. This is the current workaround. However, it requires the user to know the exact endpoint URLs, edit raw JSON config, and maintain it manually across updates. It also bypasses the onboarding flow entirely, which defeats the purpose of having a guided setup experience.
Auto-detect from API key prefix: Similar to how Z.AI (http://z.ai/)'s zai-api-key choice auto-detects the endpoint from the key, Xiaomi could theoretically detect whether a key belongs to the API balance or Token Plan and route accordingly. This was discarded because Xiaomi does not currently differentiate key prefixes between plan types — the same key format is used across all endpoints, and the plan type is determined by which endpoint you hit, not by the key itself.
Impact
Affected users: All OpenClaw users who have purchased Xiaomi MiMo Token Plan credits (China, Singapore, Europe clusters). Also affects any user outside China experiencing higher-than-necessary latency on the default endpoint.
Severity: Blocks workflow. Token Plan users cannot use their purchased quota through OpenClaw at all — the default endpoint simply does not recognize Token Plan billing. They are forced to either switch to API balance (paying twice) or abandon OpenClaw for Xiaomi entirely.
Frequency: Always. Every request from a Token Plan user fails to consume their credits because it hits the wrong endpoint. This is not intermittent — it is a permanent mismatch until manually worked around.
Consequences:
• Users pay for Token Plan credits they cannot use through OpenClaw
• Manual JSON config editing required as a workaround (error-prone, not documented)
• Users in Europe/Southeast Asia face avoidable latency on every single request
• The Anthropic-compatible Token Plan endpoints are completely inaccessible
• Users may switch to alternative tools that support Token Plan natively
Evidence/examples
No response
Additional information
No response
Summary
Add onboarding sub-choices for Xiaomi MiMo Token Plan regional endpoints (China, Singapore, Europe) with both OpenAI-compatible and Anthropic-compatible protocols, following the existing Z.AI (http://z.ai/) regional onboarding pattern.
Problem to solve
The Xiaomi MiMo provider currently hardcodes a single endpoint (https://api.xiaomimimo.com/v1) for all users, regardless of their plan type or geographic location. This means:
Token Plan users are blocked. Xiaomi's Token Plan is a separate billing model from the standard API balance. Users who purchase Token Plan credits have their own dedicated endpoints (token-plan-{cn,sgp,ams}.xiaomimimo.com), but OpenClaw routes all traffic through the API balance endpoint — which does not recognize or consume Token Plan credits. These users cannot use their purchased quota through OpenClaw at all.
No regional routing. All requests hit the same endpoint regardless of where the user is located. Users in Europe or Southeast Asia experience unnecessary latency because traffic is not routed to the nearest cluster.
No Anthropic compatibility option. Xiaomi's Token Plan clusters also expose Anthropic-compatible protocol endpoints (/anthropic), which could enable Claude-style tool calling and message formats. There is currently no way to select these.
The current onboarding experience offers only xiaomi-api-key, which always configures the same base URL:
Base URL: https://api.xiaomimimo.com/v1
API type: openai-completions
Proposed solution
Add explicit onboarding sub-choices for the Xiaomi MiMo Token Plan, mirroring the pattern already established by the Z.AI (http://z.ai/) provider (which offers zai-coding-global, zai-coding-cn, zai-global, zai-cn).
Token Plan endpoint map:
OpenAI Compatibility Protocol:
Anthropic Compatibility Protocol:
Suggested onboarding choices:
Existing — no change needed
openclaw onboard --auth-choice xiaomi-api-key
Token Plan — OpenAI-compatible
openclaw onboard --auth-choice xiaomi-token-plan-cn
openclaw onboard --auth-choice xiaomi-token-plan-sgp
openclaw onboard --auth-choice xiaomi-token-plan-ams
Token Plan — Anthropic-compatible
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-cn
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-sgp
openclaw onboard --auth-choice xiaomi-token-plan-anthropic-ams
Precedent: The Z.AI (http://z.ai/) provider already implements this exact pattern with regional and plan-based onboarding choices. The same UX and code structure could be reused for Xiaomi. See: https://docs.openclaw.ai/providers/zai
Alternatives considered
Manual models.providers override: Users can manually set baseUrl in their openclaw.json config to point to a Token Plan endpoint. This is the current workaround. However, it requires the user to know the exact endpoint URLs, edit raw JSON config, and maintain it manually across updates. It also bypasses the onboarding flow entirely, which defeats the purpose of having a guided setup experience.
Auto-detect from API key prefix: Similar to how Z.AI (http://z.ai/)'s zai-api-key choice auto-detects the endpoint from the key, Xiaomi could theoretically detect whether a key belongs to the API balance or Token Plan and route accordingly. This was discarded because Xiaomi does not currently differentiate key prefixes between plan types — the same key format is used across all endpoints, and the plan type is determined by which endpoint you hit, not by the key itself.
Impact
Affected users: All OpenClaw users who have purchased Xiaomi MiMo Token Plan credits (China, Singapore, Europe clusters). Also affects any user outside China experiencing higher-than-necessary latency on the default endpoint.
Severity: Blocks workflow. Token Plan users cannot use their purchased quota through OpenClaw at all — the default endpoint simply does not recognize Token Plan billing. They are forced to either switch to API balance (paying twice) or abandon OpenClaw for Xiaomi entirely.
Frequency: Always. Every request from a Token Plan user fails to consume their credits because it hits the wrong endpoint. This is not intermittent — it is a permanent mismatch until manually worked around.
Consequences:
• Users pay for Token Plan credits they cannot use through OpenClaw
• Manual JSON config editing required as a workaround (error-prone, not documented)
• Users in Europe/Southeast Asia face avoidable latency on every single request
• The Anthropic-compatible Token Plan endpoints are completely inaccessible
• Users may switch to alternative tools that support Token Plan natively
Evidence/examples
No response
Additional information
No response