Feature Request

Add a dashboard UI for configuring auxiliary model fallback chains — at minimum for the base model and vision model.

Motivation

Currently auxiliary models (vision, web_extract, compression, session_search, etc.) are configured only via config.yaml under the auxiliary: key. Each has a primary provider/model, a fallback, and a local fallback. There is no way to:

1. See which auxiliary models are active and what they're doing
2. Switch them visually without editing YAML
3. Understand the fallback chain at a glance
4. Test if a specific provider/model combination works before committing

Users with non-standard providers (custom endpoints, regional blocks like Google in China) hit silent fallback failures. The current auxiliary.vision chain: gemini-2.5-flash → Xiaomi-TP/mimo-v2-omni → ollama/llama3.1 — if the first two fail, vision is silently degraded to a non-vision local model with no UI indication.

Proposed Solution

A dashboard panel (similar to the existing kanban board) showing:

┌─────────────────────────────────────────────────┐
│  Auxiliary Models                               │
├──────────┬──────────────┬───────────────────────┤
│ Role     │ Current      │ Fallback Chain        │
├──────────┼──────────────┼───────────────────────┤
│ Vision   │ gemini-2.5.. │ → Xiaomi-TP/omni      │
│          │ ❌ blocked   │ → ollama/llama3.1     │
├──────────┼──────────────┼───────────────────────┤
│ Extract  │ deepseek-v4  │ → (none)              │
│          │ ✅ healthy   │                       │
├──────────┼──────────────┼───────────────────────┤
│ Compress │ mimo-v2.5-pr │ → (none)              │
│          │ ✅ healthy   │                       │
└──────────┴──────────────┴───────────────────────┘

[Edit] [Test Connection] [Swap Primary/Fallback]

Key features:

• Status indicators — green/red per model based on last API call
• Swap primary — click to promote a fallback to primary
• Test connection — send a probe request to verify the model works
• Add/remove fallbacks — manage the chain visually
• Provider capability flags — show vision/tool-calling support per model

Alternatives Considered

• CLI-only (hermes auxiliary list / hermes auxiliary set vision gemini-2.5-flash) — works but harder to discover
• Config YAML only (current) — already the case, but doesn't help with debugging silent failures

Related

• Vision-capable model detection missing for custom providers — HTTP 400 'text is not set' #25594 — vision routing broken for custom providers (root cause)
• This issue covers the UI/UX layer for managing auxiliary models