Align provider IDs/model catalog with models.dev (google/moonshotai/minimax)

Problem

Spacebot currently mixes internal provider IDs and hardcoded model defaults that do not fully align with models.dev.

Main mismatches:

• Provider naming drift:
  • gemini (Spacebot) vs google (models.dev)
  • moonshot (Spacebot) vs moonshotai / moonshotai-cn (models.dev)
  • minimax / minimax-cn need to map cleanly to models.dev IDs and catalogs
• Some hardcoded models are stale/invalid (example: moonshot/moonshot-v1-8k)
• Gemini model coverage is behind current models.dev catalog

Goal

Make models.dev the source of truth for provider IDs/model IDs, and align Spacebot naming + defaults accordingly.

Primary intent:

1. Replace/normalize provider naming to models.dev-compatible IDs
2. Update Gemini provider naming to google and use current models from models.dev
3. Keep explicit hardcoded handling only where models.dev cannot express requirements (voice transcription compatibility)

Proposed Changes

1) Provider ID alignment

• Introduce canonical provider IDs matching models.dev:
  • google (instead of gemini)
  • moonshotai and moonshotai-cn (instead of moonshot)
  • minimax and minimax-cn (explicitly aligned to models.dev IDs)
• Add backwards-compatible aliases for existing config/routing values:
  • gemini -> google
  • moonshot -> moonshotai
• Ensure alias normalization happens in:
  • config loading
  • model routing resolution
  • /api/models provider filtering

2) Gemini catalog freshness

• Switch direct mapping from models.dev google to Spacebot provider google (not gemini).
• Update routing defaults for Google models to current stable models.dev entries (avoid stale preview pinning unless explicitly intended).
• Remove obsolete Gemini hardcoded assumptions where models.dev already provides data.

3) Moonshot/Minimax cleanup

• Remove stale hardcoded model moonshot/moonshot-v1-8k.
• Use models.dev-backed Moonshot and MiniMax model lists for UI/API model listing.
• Keep minimax-cn/moonshotai-cn available when configured.

4) Transcription exception (intentional hardcode)

• Keep voice_transcription compatibility as a hardcoded allowlist, because models.dev has no explicit transcription capability field.
• Continue filtering transcription-capable models via:
  • input_audio from models.dev
  • AND Spacebot allowlist for known working transcription routes

Acceptance Criteria

• Provider IDs in routing/model APIs align with models.dev naming (google, moonshotai, moonshotai-cn, minimax, minimax-cn).
• Legacy IDs (gemini, moonshot) continue to work via alias normalization.
• /api/models returns Google/Moonshot/Minimax models from models.dev using aligned IDs.
• Stale hardcoded Moonshot model (moonshot-v1-8k) is removed.
• Routing defaults no longer reference known-invalid model IDs.
• Voice transcription filtering remains hardcoded + documented as an exception.
• Docs updated in existing files (README.md, routing/config docs) to reflect renamed provider IDs and alias behavior.

Suggested Implementation Touchpoints

• src/api/models.rs
  • direct_provider_mapping()
  • extra_models()
  • provider filter/normalization logic
• src/llm/routing.rs
  • provider prefixes/defaults
• src/config.rs
  • provider key registration + alias normalization
• src/llm/providers.rs / manager/provider resolution paths
  • canonical provider ID handling

Note for Maintainers

@jamiepine can you weigh in on this direction? If you’re okay with this provider-ID alignment and alias strategy, we can start implementation.

Start in src/api/models.rs by tracing direct_provider_mapping(), extra_models(), and provider filtering, then follow provider resolution through src/config.rs, src/llm/routing.rs, and src/llm/providers.rs. Compare current provider and model IDs with the stated models.dev mappings and inspect README.md and routing/config documentation. Done means canonical IDs, legacy aliases, current catalog-backed models, and the documented transcription exception are covered without the stale Moonshot model.