Feature request: Automatic subagent fallback across the model pool on provider errors (402/429)

Feature request: Automatic subagent fallback across the model pool on provider errors (402/429)

Context

Kimi Code CLI resolves subagent models from the [secondary_model] section of ~/.kimi-code/config.toml. On 2026-08-29, 4 coder subagent launches died at mission start with provider account/quota errors and no fallback:

Each failure killed the agent without a message naming which alias/provider had been resolved. Root cause observed the same day: [secondary_model].default_model followed neither the user's /model selection nor the main default_model — the main session had been switched to zhipuai-coding-plan/glm-5.3-flash, while the subagent UI still showed "DeepSeek V4 Flash".

Problem or Gap

1. No fallback chain: a 402/429 from the resolved provider kills the subagent instead of trying the next model in [secondary_model.models].
2. Opaque failure: the error message names neither the configured alias nor the resolved provider, making diagnosis a manual config inspection.
3. Config drift: [secondary_model].default_model is decoupled from the main model selection and silently goes stale.

Proposal

1. Automatic fallback chain: on a 402/429 from the resolved provider, retry on the next available model in [secondary_model.models], with a visible UI trace, e.g. agent-3: deepseek-v4-flash unavailable (402) → falling back to glm-5.3-flash.
2. secondary_model.follow_main_model = true: optional flag making the subagent default model follow the main session model (the one set via /model).
3. Explicit failure naming: when no fallback is possible, the subagent failure message names the alias AND the resolved provider for each attempt.

Impact

• Resilience: provider account/quota outages no longer kill subagents at mission start.
• Diagnosability: failures name what was attempted and what failed.
• Config sanity: subagent model selection follows the user's actual model choice instead of a stale config entry.

Acceptance criteria

1. A 402/429 on the resolved model triggers a fallback to the next pool model without user intervention; the subagent starts on the replacement model.
2. The fallback leaves a visible UI trace naming the rejected model (with error code) and the replacement.
3. With follow_main_model = true, subagents start on the current main-session model after /model is changed.
4. If the whole pool is exhausted, the failure message lists alias + provider + error for each attempt.

Start at the subagent model resolution path driven by ~/.kimi-code/config.toml's [secondary_model] section and trace provider-error handling for 402/429. Compare that path with /model changes; done means fallback attempts, visible traces, follow_main_model behavior, and exhausted-pool messages satisfy the four acceptance criteria.