Summary

After upgrading to Hermes Agent v0.10.0 (2026.4.16), /model switching regressed in two related ways:

1. minimax-cn switches are blocked during validation even though the actual inference endpoints work.
2. user-defined providers under config.yaml -> providers: (for example volcengine-plan) can still be reported as Unknown provider on the direct /model <name> --provider <slug> path, and even when the provider resolves, live /models listings can override the operator-provided model IDs from config.

This makes it difficult or impossible to switch models in session (including gateway / chat surfaces like Feishu) even when the models are valid and callable.

Environment

• Hermes Agent v0.10.0 (2026.4.16)
• local repo was on commit 73d0b083510367adec42746e90c41ace16c0afb2
• config uses:
  • built-in minimax-cn
  • user-defined providers.volcengine-plan

Problem 1: minimax-cn validation rejects valid model switches

Repro

/model MiniMax-M2.7-highspeed --provider minimax-cn
/model MiniMax-M2.7 --provider minimax-cn

Actual

Could not reach the MiniMax (China) API to validate `MiniMax-M2.7-highspeed`. If the service isn't down, this model may not be valid.

What I verified locally

The provider itself is reachable and inference works:

• https://api.minimaxi.com/anthropic/v1/messages returns 200 for MiniMax-M2.7-highspeed
• https://api.minimaxi.com/v1/chat/completions also returns 200

But model listing probes fail:

• https://api.minimaxi.com/v1/models -> 404
• https://api.minimaxi.com/anthropic/models -> 404

From local source inspection:

• hermes_cli/providers.py defines minimax-cn as anthropic_messages
• hermes_cli/doctor.py still probes https://api.minimaxi.com/v1/models
• hermes_cli/models.py::validate_requested_model() rejects the switch if fetch_api_models() cannot validate the model

So the failure is specifically in the pre-switch validation path, not in actual MiniMax CN inference.

Problem 2: direct /model --provider <user-provider> can fail even when config.providers is correct

Repro

config.yaml contains a valid user-defined provider:

model:
  provider: volcengine-plan

providers:
  volcengine-plan:
    name: volcengine-plan
    base_url: https://ark.cn-beijing.volces.com/api/coding/v3
    api_key: ...
    default_model: doubao-seed-2.0-code
    models:
      ark-code-latest: {}
      doubao-seed-code: {}
      glm-4.7: {}
      deepseek-v3.2: {}
      doubao-seed-2.0-code: {}
      doubao-seed-2.0-pro: {}
      doubao-seed-2.0-lite: {}
      kimi-k2.5: {}

Then run:

/model doubao-seed-2.0-code --provider volcengine-plan

Actual

Sometimes the direct command path reports:

Unknown provider 'volcengine-plan'. Check 'hermes model' for available providers, or define it in config.yaml under 'providers:'.

Important detail

The provider is actually present in config and is discoverable in picker/menu flows.

From local source inspection, the CLI direct command path appears to call switch_model() with user_providers=None / custom_providers=None, while the no-args picker flow loads config first and does pass them through. That makes it look like the provider exists in one flow but not the other.

Problem 3: live /models can override operator-provided model IDs for user-defined providers

For the same volcengine-plan provider above, the operator-provided model IDs in config.yaml are the intended IDs to use.

However, when Hermes probes the endpoint's live /models, it can return a different naming scheme (for example preview/date-suffixed IDs), and then /model warns that the configured model is not in the provider listing.

Example observed warning:

Note: doubao-seed-2.0-code was not found in this provider's model listing.
Similar models: doubao-seed-2-0-pro-260215, doubao-seed-2-0-code-preview-260215, doubao-seed-2-0-lite-260215

That means Hermes is trusting the live /models listing more than the explicit config.providers.<name>.models table, even for user-defined providers where the config should arguably be authoritative.

Expected behavior

1. minimax-cn should not reject valid switches purely because /models probing is unavailable or unsupported. If inference works, /model should allow the switch and warn rather than fail.
2. direct /model <name> --provider <slug> should resolve user-defined providers from config.providers consistently, just like picker/menu flows.
3. for user-defined providers that explicitly define a models: table in config, that table should take precedence over live /models listings for validation / suggestions.

Suggested fix direction

• allow minimax-cn switches when model-listing validation is unavailable, similar to the more permissive handling used for providers whose listing APIs are not authoritative
• ensure all /model code paths pass user_providers / custom_providers consistently into provider resolution
• prefer config.providers.<name>.models as the authoritative model catalog for user-defined providers, with live /models treated as advisory only

Happy to provide more local logs / repro details if helpful.