Fallback providers: keep working when your main model fails

What Fallback providers is for

If your primary model provider rate-limits you, has an outage or rejects your key, Hermes can switch to a backup provider mid-turn instead of failing. You list backups under fallback_providers in config.yaml, each with a provider and model, or manage the list interactively with hermes fallback. On a switch, Hermes keeps the conversation history and tool context, and the next user message goes back to the primary. Auxiliary tasks and subagents can have their own fallback chains. This matters most for scheduled and unattended jobs, where a single provider hiccup would otherwise mean a missed run.

What you need

• Credentials for at least one additional provider besides your primary
• A Hermes version with the fallback_providers setting (the older fallback_model key is still honored)

Set it up

1. 1

   Run hermes fallback to add backups with the same picker as hermes model, or use hermes fallback add

2. 2

   Or add a fallback_providers list to config.yaml with provider and model for each entry (custom endpoints also take base_url and optionally key_env)

3. 3

   Optionally set fallback.min_switch_reset_seconds so short rate-limit resets wait instead of switching

Check it works

• Run hermes fallback list to see the configured chain
• Confirm the chain is saved under the top-level fallback_providers list in config.yaml

Limits and failure points

• Fallback is turn-scoped: it activates at most once per turn, and each new message returns to the primary
• Switching loses the prompt cache, so the next request re-reads full history at full price
• Cron jobs pinned to their own provider or model never fall back, and unrecognized quota messages may not trigger a switch

Spotted something wrong or out of date? Tell us on X at @HermesWatcher↗ (opens in a new tab) and we will fix it.