Two CometAPI listings, one model name
Xiaomi’s 22 September launch post says the MiMo-V2.6 series contains two natively omnimodal models, calls MiMo-V2.6-Pro “our most capable model to date”, and describes MiMo-V2.6-Pro-UltraSpeed as a roll-out “delivering up to 20x faster output speed at the same quality”. The published weights are a Sparse MoE at 1.02T total and 42B activated parameters under MIT with a 1M-token context, per the MiMo-V2.6-Pro-RL model card.
On CometAPI that series arrives as several separate listings, and the split is the interesting part. mimo-v2.6-pro-ultraspeed is its own model ID with its own page: context window 1,048,576 tokens, maximum output 131,072 tokens, text, image, video and audio input with text output, OpenAI- and Anthropic-compatible protocols, and a native base URL of https://api.xiaomimimo.com/v1. Standard mimo-v2.6-pro is a separate listing recorded as released 22 September 2026.
What the listings themselves say
The UltraSpeed page does not hide the soft edges. Its limitations block states that the speed figures “are vendor claims: Xiaomi states ‘up to 20×’ faster output, but a standardized independent measurement for this specific serving tier was not found”, and that UltraSpeed “should not be described as a separate open-weight checkpoint without qualification”. It also notes that RPM and TPM for the tier are a customized service rather than a published universal limit. The model card publishes no tokens-per-second, latency or throughput figure anywhere, so the “20x” has no baseline to check against from the open-weight side.
Pricing is where the decision actually lands. The vendor-filtered CometAPI catalog card for MiMo V2.6 Pro reads “From $0.435 $0.348 /1M tokens”; the UltraSpeed page quotes Comet Price of $3.48 per million input tokens and $6.96 per million output tokens against an official $4.35 / $8.70. Same base model, two listings, roughly a tenfold step on the input rate (inference: both numbers are per-million-token rates on CometAPI’s own pages, which is what makes them comparable).
One caution before anyone budgets on those figures. The standard-Pro page’s own cost panel is a discounted-versus-list pair, not a single rate: a field labelled “Unit price” carries $0.348 / 1M input tokens, a second labelled “Starting price” repeats it, and the table below sets $0.3480/M input and $0.6960/M output against an “Official Price” of $0.4350/M input and $0.8700/M output, badged “20% below official”. That list figure matches the $0.435 the UltraSpeed page attributes to standard V2.6-Pro, so the two CometAPI surfaces agree once the discount is separated from the list. Anyone who opens the page’s embedded JSON may also see a 75/M input row; it belongs to the payload’s AUTO router fallback entry, not to this listing, so it is not the MiMo rate. Treat $0.348 as promotional and budget on the $0.435 list unless the discount is confirmed for the term you need.
A decision rule, labelled as such
Recommendation, not a sourced fact: route latency-sensitive interactive traffic to the UltraSpeed listing only where a measurable user-facing delay dominates cost, and keep batch and long-horizon agent work on standard Pro, because the UltraSpeed premium is paid per token on every call rather than once per session. That framing follows the page’s own framing of the trade-off as latency versus token cost, plus the tenfold listed gap.
Open question for anyone pricing this: which figure would you trust first for the decision, a published median time-to-first-token and output tokens per second on the UltraSpeed page, or an explicit statement of which open-weight checkpoint each listing actually serves?