feat: add Xiaomi MiMo provider support

[HUQIANTAO]

Summary

• Add first-class Xiaomi MiMo provider support with dedicated API integration via token-plan endpoint (https://token-plan-cn.xiaomimimo.com/v1)
• Support two MiMo models: mimo-v2.5-pro (reasoning flagship) and mimo-v2.5 (omni)
• Implement MiMo-specific thinking toggle (thinking: { type: "enabled"/"disabled" }) instead of DeepSeek-style reasoning_effort
• Enable /models command for Xiaomi provider to fetch available models from the API
• Add provider-specific model picker UI with MiMo models and simplified thinking effort (off/high)

Changes

Provider registration:

• crates/config/src/lib.rs — ProviderKind::Xiaomi variant, default model/base_url constants, parse/as_str
• crates/tui/src/config.rs — ApiProvider::Xiaomi variant, provider_capability (thinking enabled), all match arms
• crates/cli/src/lib.rs — ProviderArg::Xiaomi, provider list, env var mapping

Model picker & validation:

• crates/tui/src/tui/model_picker.rs — Provider-specific model lists (PICKER_MODELS_XIAOMI) and thinking effort lists (PICKER_EFFORTS_MIMO with only off/high)
• crates/tui/src/config.rs — normalize_model_name_for_provider accepts MiMo model names for Xiaomi provider

API integration:

• crates/tui/src/client.rs — apply_reasoning_effort sends thinking: { type: "disabled" } for off, thinking: { type: "enabled" } for high/max
• crates/tui/src/client/chat.rs — requires_reasoning_content() includes mimo prefix for reasoning token replay
• crates/tui/src/tui/ui.rs — Allow /models command for Xiaomi provider

Model registry:

• crates/agent/src/lib.rs — ModelInfo entries for mimo-v2.5-pro and mimo-v2.5 with aliases

Config & docs:

• config.example.toml — [providers.xiaomi] section with token-plan URL and model examples
• .env.example — MIMO_API_KEY, MIMO_BASE_URL, MIMO_MODEL documentation

Test plan

• cargo fmt --all -- --check passes
• cargo clippy --workspace --all-targets --all-features --locked -- -D warnings passes
• cargo test --workspace --all-features --locked passes (4 pre-existing failures unrelated to this change)
• Manual TUI test: /provider → Xiaomi MiMo, /model → mimo-v2.5-pro, send a message
• Manual TUI test: /model → switch thinking effort off/high, verify API accepts the request
• Manual TUI test: /models → verify model list is fetched from Xiaomi API
• Manual TUI test: restart app → verify Xiaomi provider and MiMo model are persisted

Greptile Summary

This PR adds first-class Xiaomi MiMo provider support, wiring ProviderKind::Xiaomi / ApiProvider::Xiaomi through the full stack: config/secrets/CLI registration, TUI provider and model pickers, apply_reasoning_effort (MiMo-specific thinking: {type: "enabled"/"disabled"} toggle), reasoning-content replay for multi-turn tool calls, and all match exhaustiveness sites.

• Adds mimo-v2.5-pro and mimo-v2.5 to the model registry with aliases and full thinking support; picker shows a dedicated three-row model list (auto / pro / omni) and a two-row effort list (off / high).
• Introduces MIMO_API_KEY, MIMO_BASE_URL, MIMO_MODEL env vars, [providers.xiaomi] TOML section, codewhale auth set --provider xiaomi, and /models command support for the Xiaomi endpoint.
• docs/PROVIDERS.md documents that the MiMo API uses max_completion_tokens instead of max_tokens, but both the non-streaming (create_message_chat) and streaming (handle_chat_completion_stream) request-body constructors in chat.rs always emit \"max_tokens\" — no provider-specific field rename is implemented.

Confidence Score: 4/5

The provider integration is structurally complete and correct; one API field name discrepancy between the documentation and the implementation should be resolved before merging.

The docs/PROVIDERS.md entry added in this same PR explicitly states that the MiMo API uses max_completion_tokens instead of max_tokens. Both the non-streaming and streaming request paths in chat.rs always send "max_tokens" with no Xiaomi-specific branch to rename the field. If the MiMo API does not honor max_tokens, every API call will silently ignore the configured token limit and fall back to the server's default. All other integration points (thinking toggle, reasoning-content replay, model picker, config/secrets handling) look correct and well-tested.

crates/tui/src/client/chat.rs (lines 83 and 153) — both the non-streaming and streaming request-body constructors need a Xiaomi-specific branch to emit max_completion_tokens instead of max_tokens.

Important Files Changed

Filename	Overview
crates/tui/src/client/chat.rs	Adds MiMo reasoning-content replay and thinking-effort wiring; both non-streaming and streaming paths send max_tokens even though PROVIDERS.md documents MiMo uses max_completion_tokens.
crates/tui/src/client.rs	Adds Xiaomi-specific apply_reasoning_effort arms for off/high/max, sending thinking: { type: "disabled"/"enabled" } without reasoning_effort. Unit tests cover all four effort cases.
crates/tui/src/config.rs	Adds ApiProvider::Xiaomi throughout; model completion returns [mimo-v2.5-pro, mimo-v2.5]; provider_capability sets 1M context/128K output; provider_passes_model_through includes Xiaomi.
crates/tui/src/tui/model_picker.rs	Refactors picker to provider-specific model and effort lists; PICKER_MODELS_XIAOMI has auto/mimo-v2.5-pro/mimo-v2.5; PICKER_EFFORTS_MIMO has Off/High; pass-through providers retain the 'auto' row.
crates/config/src/lib.rs	Adds ProviderKind::Xiaomi with aliases, default constants, ProvidersToml field, and env-var handling (MIMO_API_KEY, MIMO_BASE_URL).
crates/agent/src/lib.rs	Registers mimo-v2.5-pro and mimo-v2.5 ModelInfo entries with aliases; both have supports_reasoning=true and supports_tools=true.
crates/tui/src/tui/ui.rs	Allows /models for Xiaomi by excluding it from the pass-through provider guard; adds Xiaomi to provider-picker api_key and auth_mode update paths.
docs/PROVIDERS.md	Adds xiaomi row documenting max_completion_tokens usage — this documented behavior is not implemented in chat.rs where max_tokens is always sent.

Sequence Diagram

sequenceDiagram
    participant User
    participant TUI
    participant Config as Config/Picker
    participant Client as DeepSeekClient
    participant MiMo as Xiaomi MiMo API

    User->>TUI: /provider xiaomi
    TUI->>Config: ApiProvider::Xiaomi → provider_capability()
    Config-->>TUI: "1M ctx, 128K out, thinking_supported=true"

    User->>TUI: /model mimo-v2.5-pro (effort: high)
    TUI->>Config: normalize_model_name_for_provider(Xiaomi, mimo-v2.5-pro)
    Config-->>TUI: mimo-v2.5-pro (pass-through)

    User->>TUI: send message
    TUI->>Client: "MessageRequest{model, max_tokens, reasoning_effort=high}"
    Client->>Client: "apply_reasoning_effort → body[thinking] = {type:enabled}"
    Note over Client: body[max_tokens] sent — docs say max_completion_tokens
    Client->>MiMo: "POST /v1/chat/completions {model, max_tokens, thinking:{type:enabled}}"
    MiMo-->>Client: stream with reasoning_content deltas
    Client->>Client: should_replay_reasoning_content(mimo-v2.5-pro, high) → true
    Client-->>TUI: assistant message + reasoning tokens
    TUI-->>User: display response

Loading

Comments Outside Diff (1)

1. crates/tui/src/client/chat.rs, line 83 (link)

   max_tokens field not renamed for Xiaomi MiMo

   The PR's own docs/PROVIDERS.md entry for xiaomi explicitly documents that the MiMo API uses max_completion_tokens instead of max_tokens. However, the request body here (and the identical line in the streaming path at line 153) always sends "max_tokens". There is no provider-specific translation anywhere in the codebase.

   If the MiMo API ignores max_tokens (as the documentation implies), every non-streaming and streaming request will silently discard the configured token limit and fall back to whatever server-side default Xiaomi applies. The same fix is needed at the corresponding line in handle_chat_completion_stream.

   

_{Reviews (5): Last reviewed commit: "fix(mimo): address review feedback on Xi..." | Re-trigger Greptile}

[gemini-code-assist]

Code Review

This pull request adds support for the Xiaomi MiMo Token Plan provider, integrating its models (mimo-v2.5-pro, mimo-v2.5, and mimo-v2-flash) into the configuration, CLI, and interactive TUI. The review feedback highlights three key issues: a regression in the model picker that removes the "auto" option for other pass-through providers, an issue where switching to Xiaomi with a "Max" reasoning effort silently disables thinking, and an overly restrictive model name normalization bypass that prevents the use of "auto" or custom models.

[gemini-code-assist]

For other pass-through providers, setting provider_models to &[] removes the "auto" ("select per turn") option from the model picker, which is a regression from the previous behavior where vec!["auto"] was shown. We should return &[("auto", "select per turn")] for other pass-through providers to preserve this option.

Suggested change

	let provider_models: &'static [(&'static str, &'static str)] = match app.api_provider {
	crate::config::ApiProvider::Xiaomi => PICKER_MODELS_XIAOMI,
	p if crate::config::provider_passes_model_through(p) => &[],
	_ => PICKER_MODELS,
	};
	let provider_models: &'static [(&'static str, &'static str)] = match app.api_provider {
	crate::config::ApiProvider::Xiaomi => PICKER_MODELS_XIAOMI,
	p if crate::config::provider_passes_model_through(p) => &[("auto", "select per turn")],
	_ => PICKER_MODELS,
	};

[gemini-code-assist]

If the user has ReasoningEffort::Max selected (which is common for DeepSeek), switching to Xiaomi MiMo will result in normalized being Max. Since PICKER_EFFORTS_MIMO does not contain Max, the position search will fail and default to 0 (ReasoningEffort::Off), silently disabling thinking. We should map ReasoningEffort::Max to ReasoningEffort::High when is_xiaomi is true.

        let selected_effort_idx = provider_efforts
            .iter()
            .position(|e| {
                if is_xiaomi && normalized == ReasoningEffort::Max {
                    *e == ReasoningEffort::High
                } else {
                    *e == normalized
                }
            })
            .unwrap_or(0);

[gemini-code-assist]

Restricting the bypass to only models starting with "mimo" prevents the use of "auto" (the special TUI-level model name for auto-selection) or any custom/fine-tuned models that do not follow the "mimo" prefix. Since Xiaomi is a pass-through provider, we should allow any valid model name format.

    if matches!(provider, ApiProvider::Xiaomi) {
        if trimmed
            .chars()
            .all(|ch| ch.is_ascii_alphanumeric() || matches!(ch, '-' | '_' | '.' | ':'))
        { 
            return Some(trimmed.to_string());
        }
        return None;
    }

[Hmbown]

Independent review:

Comprehensive provider wiring across all 9 layers (config, secrets, CLI, TUI engine, picker, client, chat replay, agent registry, docs). Match arms are exhaustive — Rust compile-time enforcement will catch any future regressions. The MiMo-specific picker carve-out (PICKER_EFFORTS_MIMO with only off/high) and the thinking: { type } translation across all three effort tiers (off/high/max) are correct per the documented MiMo contract. README trilingual updates are present.

Concerns:

• Zero new tests. Sister PR feat: add Xiaomi MiMo provider #2246 ships a reasoning_effort_uses_xiaomi_mimo_thinking_parameter_only unit test covering all effort tiers + a registry resolution test. Given the three-branch divergence in apply_reasoning_effort, this is the weakest link.
• Base URL differs from sister: this PR uses token-plan-cn.xiaomimimo.com/v1 (token-plan endpoint); feat: add Xiaomi MiMo provider #2246 uses api.xiaomimimo.com/v1. One is wrong or region-specific — needs a citation in the PR body.
• Greptile's && !is_xiaomi carve-out comment is valid; either add the inline rationale or drop Xiaomi from provider_passes_model_through.
• Misleading "same thinking format as DeepSeek" comment at client.rs:925 — DeepSeek also sends reasoning_effort, Xiaomi does not.

v0.8.48 (#2256) compatibility: No conflict — #2256 is unrelated (verification-gate work), does not add Xiaomi. Earlier intel was incorrect.
Sister PR #2246 relationship: Hard conflict — different enum name (Xiaomi vs XiaomiMimo), different base URL, different env var slugs, same files. Pick one; merging both is impossible. #2246 has tests + richer serde aliases; #2240 has the simpler picker UX and trilingual docs. Recommend cherry-picking tests + the XiaomiMimo naming from #2246 into this PR, or vice versa.

[Hmbown]

Correction to my earlier comment: I miscalled v0.8.48's Xiaomi state. Verified just now via git show origin/feature/v0.8.48-crate-consolidation:crates/config/src/lib.rs | grep -i xiaomi:

const DEFAULT_XIAOMI_MODEL: &str = "mimo-v2.5-pro";
const DEFAULT_XIAOMI_BASE_URL: &str = "https://token-plan-cn.xiaomimimo.com/v1";
ProviderKind::Xiaomi  (with serde alias "mimo")

So v0.8.48 (#2256) DOES add Xiaomi MiMo independently. That means three implementations of the same provider are now in flight:

• PR feat: add Xiaomi MiMo provider support #2240 (this) — Xiaomi, token-plan-cn.xiaomimimo.com/v1
• PR feat: add Xiaomi MiMo provider #2246 — XiaomiMimo, api.xiaomimimo.com/v1
• PR refactor: consolidate workspace crates — 14→11 (delete tui-core, merge hooks+agent) #2256 — Xiaomi (with mimo alias), token-plan-cn.xiaomimimo.com/v1 ← matches this PR

This PR's base URL aligns with v0.8.48's choice. PR #2246 disagrees. Whichever lands first wins the URL choice; the other two need to either align or document why a different endpoint is needed (region? auth shape?).

v0.8.48 (#2256) relationship: direct conflict — both add ProviderKind::Xiaomi. Same enum name, same base URL — should merge as a duplicate-add conflict that auto-resolves to identity, but the test/picker/auth wiring will need a manual 3-way merge.

[Hmbown]

Xiaomi MiMo cluster coordination — three implementations in flight:

• feat: add Xiaomi MiMo provider support #2240 (this) — Xiaomi, token-plan-cn.xiaomimimo.com/v1, CN endpoint
• feat: add Xiaomi MiMo provider #2246 (AdityaVG13) — XiaomiMimo, api.xiaomimimo.com/v1, public endpoint
• refactor: consolidate workspace crates — 14→11 (delete tui-core, merge hooks+agent) #2256 v0.8.48 — Xiaomi with mimo serde alias, token-plan-cn.xiaomimimo.com/v1 (matches this PR)

Your enum name + base URL choice already aligns with v0.8.48's independent implementation, which is a strong signal for this naming. The gap to close vs #2246: tests. #2246 ships reasoning_effort_uses_xiaomi_mimo_thinking_parameter_only covering all effort tiers; this PR has zero new tests.

Recommendation: pull #2246's test scaffolding here (or have it land after #2256, then have this PR rebase + add tests as a follow-up). The CN URL choice is right for the CN-region access pattern that motivated MiMo in the first place; #2246's public URL is the international fallback. Your wiring is solid.