mimo (token plan) registry entry declares no model-level capacity facts — V2.6 rows published without context window, output cap, or modalities #5695

Client or integration

Direct HTTP/API client

Area

Catalog / models

Summary

The mimo registry entry (Xiaomi MiMo token plan, src/providers/registry/entries-extended.ts) declares no modelContextWindows, no modelMaxOutputTokens, no modelInputModalities, and no jawcodeBundle, so the shared catalog publishes MiMo V2.6 rows with no context window, no output cap, and no input modalities. Per structure/catalog.md ("invalid values are omitted") the fields are simply absent from /v1/models rows, and downstream clients fall back to their own defaults — in my case a 262,144 default context window and text-only input for a 1M-context omni-modal model. I expected the same model-level capacity facts the xiaomi / xiaomi-mimo entries already advertise (1,048,576 / 131,072 / text+image).

The entry's comment says the omission is deliberate:

Token-plan roster per Xiaomi's token-plan model list (V2.6 Pro and Flash). No jawcodeBundle, so no plan-specific facts are claimed; usage estimates still come from the model-level vendor price fallback (the pay-as-you-go equivalent).

Respectfully, this guard is broader than the risk it protects against. Context window, output cap, and input modalities are model-level facts, not plan-specific ones — the pay-as-you-go vs token-plan difference is pricing/entitlement only. Xiaomi's token-plan onboarding states verbatim: "Same API format as pay-as-you-go — just swap the key and base URL" (https://platform.xiaomimimo.com/token-plan , https://mimo.mi.com/docs/quick-start/first-api-call). The model specs are identical regardless of which key/billing path serves them.

Official specs (all three V2.6 models identical) — https://mimo.mi.com/models/en-US/mimo-v2.6-pro , https://mimo.mi.com/models/en-US/mimo-v2.6-flash , https://mimo.mi.com/models/en-US/mimo-v2.6-pro-ultraspeed :

These match the values already used elsewhere in the repo (1_048_576 / 131_072 appear in COMMAND_CODE_MIMO_CONTEXT_WINDOWS and the opencode-go rows), so the same numbers should populate the mimo entry.

Suggested fix — add model-level facts to the mimo entry (keeping preserveCustomDestination semantics as-is), the same pattern the commandcode entry already uses ("The public model catalog reports ids/context windows only" → COMMAND_CODE_MIMO_CONTEXT_WINDOWS filled in by hand):

modelContextWindows: {
  "mimo-v2.6-pro": 1_048_576,
  "mimo-v2.6-flash": 1_048_576,
  "mimo-v2.5-pro": 1_048_576,
  "mimo-v2.5": 1_048_576,
},
modelMaxOutputTokens: {
  "mimo-v2.6-pro": 131_072,
  "mimo-v2.6-flash": 131_072,
  // verify per-model for V2.5 rows before landing
},

Related gaps (same root cause, separate fixes):

1. Modality metadata is short of the official spec everywhere. The generated metadata (src/generated/model-metadata.ts) marks V2.6 as text,image, and the opencode-go rows mark mimo-v2.6-pro/flash as text ("text-only until probed"). Per the spec pages above, all three V2.6 models accept text, image, video, audio. Note ModelMetadata["input"] is typed ("text" | "image" | "video")[] — audio cannot even be represented in the current schema.
2. MiMo token-plan mimo-v2.5-pro image requests bypass the vision sidecar and fail with 404 #1927's "Pro route rejects image input" should be re-verified against V2.6. That was measured on the token-plan host in the V2.5 era. V2.6 is officially omni-modal (the spec pages showcase video/audio-driven multi-agent workflows), so the gateway-level rejection may no longer apply. The existing noVisionModels: ["mimo-v2.5-pro"] provider-scoped classification is fine to keep until then — but V2.6 rows currently inherit no modality fact at all, which is the bug.

Reproduction

1. ocx start, then point a downstream client at the proxy with the mimo provider (token plan) and mimo-v2.6-pro.
2. GET /v1/models and inspect the mimo-v2.6-pro row (or the shared Codex-shaped catalog output).
3. Observe: the row carries no context window, no output cap, and no input modalities (in the Codex-shaped entry, only the reasoning ladder low/medium/high is present).
4. The client substitutes its own fallbacks — e.g. contextWindow falls back to the client default (262,144 in my client) and input defaults to ["text"].

Compare with xiaomi or xiaomi-mimo (pay-as-you-go) serving mimo-v2.6-pro: those entries carry jawcodeBundle: "xiaomi" and advertise 1,048,576 / 131,072 / text+image for the same model — two different capability advertisements for one model.

Version

2.64.0 / main @ 4cb43cb (registry read from current main)

Operating system

Windows 11 (client side); proxy-side issue is platform-independent — it is registry metadata

Provider and model

mimo (Xiaomi MiMo token plan, https://token-plan-cn.xiaomimimo.com/v1) / mimo-v2.6-pro, mimo-v2.6-flash (also affects mimo-v2.5-pro, mimo-v2.5)

Logs or error output

None — this is missing advertised metadata, not a runtime error. The absence is visible directly in the catalog row and in src/providers/registry/entries-extended.ts (the mimo entry has no modelContextWindows / modelMaxOutputTokens / modelInputModalities / jawcodeBundle, unlike the xiaomi and xiaomi-mimo entries).

Screenshots and supporting files

None. Upstream spec pages cited in Summary.

Redacted configuration

Not configuration-dependent — the registry entry itself lacks the fields. For reference, the consumer-side symptom on a mimo/mimo-v2.6-pro route served through the proxy: resolved as contextWindow: 262144 (client default) and input: [text], with only reasoningEfforts: {low, medium, high} matching the registry's ladder declaration.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.