hermes - 💡(How to fix) Fix bug: OpenRouter model ID accounts/fireworks/models/deepseek-v4-pro invalidated — Hermes loops on 400 instead of fast-fallback

Summary

The OpenRouter model ID accounts/fireworks/models/deepseek-v4-pro stopped working today (2026-06-05) — OpenRouter returns HTTP 400: "is not a valid model ID". This was the primary model for my Hermes instance across all config sections (primary, auxiliaries, delegation, fallbacks).

Impact

• All sessions dead-loop on "Non-retryable client error: HTTP 400"
• Some sessions auto-fell-back to deepseek/deepseek-v4-pro (DeepSeek's own API via OpenRouter), but not consistently
• Cron/background workers do NOT appear to benefit from the same auto-fallback — stuck workers kept retrying the dead model ID

Root Cause (external)

Fireworks detected serving-path correctness issues (reasoning trace corruption) in DeepSeek V4 Pro within 48 hours of launch and pulled/renamed the model on OpenRouter. The model ID accounts/fireworks/models/deepseek-v4-pro was invalidated.

See: https://fireworks.ai/blog/deepseek-v4-pro-validating-frontier-models-for-production

What would help on the Hermes side

1. Smarter fallback — when a model returns 400 "not a valid model ID", Hermes should immediately skip to next fallback rather than retrying 3x (non-retryable by definition)
2. Cron/worker fallback parity — background workers should get the same fallback logic as interactive sessions
3. Model catalog awareness — if the model catalog refreshes and a configured model is no longer listed, surface a warning rather than silently looping

Workaround

Switched to DeepInfra hosting deepseek-ai/DeepSeek-V4-Pro directly (model.provider empty, model.base_url https://api.deepinfra.com/v1). Working fine.