[Gi99lin]

Summary

Fixes Xiaomi MiMo provider failing to connect — both adding API keys and sending requests were broken due to outdated model IDs and incorrect regional endpoint defaults.

Root Cause

Two issues combined to completely break the provider:

1. Outdated model IDs — The registry listed mimo-v2-pro, mimo-v2-omni, mimo-v2-tts, but Xiaomi released the V2.5 series (mimo-v2.5-pro, mimo-v2.5, mimo-v2.5-tts, etc.). The generic OpenAI validation sends a test chat request with the first registered model — using an obsolete model ID caused validation failure.

2. Wrong default regional endpoint — Token Plan keys (tp-*) only work on their assigned regional cluster. The default token-plan-ams endpoint doesn't work for all TP keys. Changed to token-plan-sgp which has wider availability.

3. No custom validation — Xiaomi was using the generic validateOpenAILikeProvider which first tries GET /models (works but gives false negatives on wrong region), then falls through to /chat/completions with an obsolete model. Added dedicated SPECIALTY_VALIDATORS entry.

Changes

open-sse/config/providerRegistry.ts

• Added V2.5 models: mimo-v2.5-pro, mimo-v2.5, mimo-v2.5-tts, mimo-v2.5-tts-voiceclone, mimo-v2.5-tts-voicedesign
• Kept V2 legacy models for backward compatibility

src/lib/providers/validation.ts

• Added xiaomi-mimo to SPECIALTY_VALIDATORS — validates via /chat/completions using the user's configured baseUrl (critical for Token Plan regional endpoints)

src/app/(dashboard)/dashboard/providers/[id]/page.tsx

• Changed default base URL from token-plan-ams to token-plan-sgp

tests/unit/xiaomi-mimo-provider.test.ts

• Updated assertions for new V2.5 model list and SGP URLs

Verification

• ✅ Tested with live Token Plan key (tp-*) on SGP endpoint
• ✅ GET /v1/models returns all 8 models (V2 + V2.5)
• ✅ POST /v1/chat/completions with mimo-v2.5-pro returns 200
• ✅ Confirmed Anthropic API (/messages) returns 404 on Token Plan — OpenAI format is the only option
• ✅ 20+ production requests processed successfully after deployment
• ✅ All 4 unit tests pass
• ✅ chat-openai-compat-providers integration test passes

[gemini-code-assist]

Code Review

This pull request updates the Xiaomi MiMo provider by adding several v2.5 models to the registry and changing the default regional base URL from Amsterdam to Singapore. It also introduces a custom API key validator. Feedback was provided regarding the validator's logic: it currently uses a hardcoded model ID instead of allowing a user-specified one and is too permissive with HTTP status codes, potentially marking failed requests (like 404 or 5xx) as valid.

[gemini-code-assist]

The specialty validator for xiaomi-mimo has two issues:

1. It uses a hardcoded model ID mimo-v2.5-pro, ignoring any user-provided validationModelId in providerSpecificData. This can cause validation to fail if the user only has access to specific models.
2. The validity check is too permissive. It returns valid: true for any status code other than 401 or 403, including 404 (wrong URL) or 5xx (server error). It should only consider the key valid if the response indicates that authentication was successful (e.g., 200, 400, 422, or 429).

    "xiaomi-mimo": async ({ apiKey, providerSpecificData }: any) => {
      try {
        const baseUrl = normalizeBaseUrl(
          providerSpecificData?.baseUrl || "https://api.xiaomimimo.com/v1"
        );
        const chatUrl = baseUrl.replace(/\/chat\/completions$/, "") + "/chat/completions";
        const testModelId = providerSpecificData?.validationModelId || "mimo-v2.5-pro";
        const res = await validationWrite(chatUrl, {
          method: "POST",
          headers: buildBearerHeaders(apiKey, providerSpecificData),
          body: JSON.stringify({
            model: testModelId,
            messages: [{ role: "user", content: "test" }],
            max_tokens: 1,
          }),
        });
        if (res.status === 401 || res.status === 403) {
          return { valid: false, error: "Invalid API key" };
        }
        if (res.ok || res.status === 400 || res.status === 422 || res.status === 429) {
          return { valid: true, error: null };
        }
        if (res.status >= 500) {
          return { valid: false, error: "Provider unavailable (" + res.status + ")" };
        }
        return { valid: false, error: "Validation failed: " + res.status };
      } catch (error: any) {
        return toValidationErrorResult(error);
      }
    },

[diegosouzapw]

Thanks @Gi99lin for this great contribution! 🎉 It's now officially merged into the release/v3.7.6 branch and will be part of the next release. We deeply appreciate your effort!