Bug: mimo provider returns 404 after first turn; switching models mid-conversation doesn't recover

Environment

• Hermes Desktop (Electron)
• Provider: mimo-v2.5-pro (endpoint: https://token-plan-cn.xiaomimimo.com/v1)
• Model: mimo-v2.5-pro

Steps to Reproduce

1. Set mimo-v2.5-pro as the default model/provider in config.yaml.
2. Open Hermes Desktop, start a new conversation.
3. Send a message — first turn succeeds (model responds, may trigger tool calls).
4. Send a second message → API call failed after 3 retries: HTTP 404: 404 page not found.
5. Every subsequent message in the same conversation also returns 404.
6. User tries to switch to a different model (e.g. DeepSeek) mid-conversation → same 404 error persists.

Expected Behavior

• Subsequent turns should not fail if the first turn succeeded (same endpoint, same auth).
• When the user explicitly switches the model/provider, the new provider should be used immediately — the conversation should recover.

Actual Behavior

• After the first successful turn, all subsequent API calls fail with HTTP 404.
• Switching models mid-conversation has no effect — the error persists, suggesting the provider switch is not actually applied, or the request is still routed to the original failing endpoint.

Suspected Root Cause

1. mimo endpoint instability or rate-limiting: The xiaomimimo.com/v1 endpoint may return 404 after initial load (session-based routing, cold start, or auth token expiry).
2. Provider switch not applied to in-flight retries: After a 404, the retry logic (3 retries) may still be targeting the old provider even after the user selects a new one. The Desktop UI may update the model selector but not cancel/re-route the pending request chain.
3. Conversation-level provider pinning: The provider may be locked at conversation creation time and not re-evaluated on subsequent turns or user overrides.

Additional Context

• This is reproducible: the first turn almost always works, subsequent turns almost always 404.
• The same mimo config works intermittently via CLI (non-Desktop), suggesting the Desktop-specific request lifecycle or retry logic may differ.
• No fallback provider is configured (fallback_providers: []), so the 404 is a hard failure with no recovery path other than starting a new conversation.