Blog / model configuration
Hermes Agent Fallback Providers: Survive an Outage
A fallback provider is a second model endpoint Hermes Agent uses when the primary fails, rate limits, or times out. Configure at least one fallback, decide which errors should trigger it, and test the switch deliberately instead of discovering it during an incident.
- 01
Pick a fallback with a different failure domain
Choose a provider that is unlikely to fail for the same reason as the primary. Two models behind the same upstream are not a real fallback.
- 02
Store the fallback credential separately
Give the fallback its own key so a problem with the primary key cannot affect it, and so usage stays attributable.
- 03
Define which errors trigger the switch
Decide whether rate limits, timeouts, authentication failures, and server errors all fall through, or only a subset.
- 04
Deploy and confirm both providers are reachable
Verify the primary answers normally before you test the fallback. Both paths must work independently.
- 05
Force a failure and watch the switch
Temporarily revoke the primary key or point it at an invalid value, send a request, and confirm the assistant still answers.
- 06
Alert on fallback activation
A fallback that quietly runs for days is an outage you have not noticed. Alert when the secondary provider starts serving traffic.
Four-step path
How do you configure fallback providers?
Five checkpoints: pick the fallback, add its credential, define the triggers, deploy, then force a failure to prove the switch works.
- Step 01
Pick a fallback with a different failure domain
Choose a provider that is unlikely to fail for the same reason as the primary. Two models behind the same upstream are not a real fallback.
- Step 02
Store the fallback credential separately
Give the fallback its own key so a problem with the primary key cannot affect it, and so usage stays attributable.
- Step 03
Define which errors trigger the switch
Decide whether rate limits, timeouts, authentication failures, and server errors all fall through, or only a subset.
- Step 04
Deploy and confirm both providers are reachable
Verify the primary answers normally before you test the fallback. Both paths must work independently.
- Step 05
Force a failure and watch the switch
Temporarily revoke the primary key or point it at an invalid value, send a request, and confirm the assistant still answers.
- Step 06
Alert on fallback activation
A fallback that quietly runs for days is an outage you have not noticed. Alert when the secondary provider starts serving traffic.
Why does a fallback matter more than a faster primary?
Availability is usually what users notice. A slightly weaker model that keeps answering is better than a stronger model that returns errors during a provider incident.
- Provider outages and rate limits are outside your control.
- A bad key or exhausted quota looks identical to an outage to users.
- Fallbacks keep scheduled jobs and background tasks running.
- The switch is cheap to configure compared with the incident it prevents.
Which failures should trigger a fallback?
Rate limits, timeouts, authentication failures, and provider-side server errors are the standard triggers. Content-level refusals usually should not switch providers.
- Rate limit and quota exhaustion: fall through.
- Network timeouts and connection resets: fall through.
- Invalid or revoked credentials: fall through, then alert loudly.
- A model that answered but refused the task: do not silently switch.
How do you keep quality acceptable on the fallback?
Choose a fallback that is close in capability for the tasks it will serve, and accept that a degraded provider may produce different phrasing. Consistency of behaviour matters more than identical wording.
If the fallback model is materially weaker, restrict what it may do. A fallback that answers questions but cannot take actions is a reasonable safety compromise.
How do you test a fallback without waiting for an outage?
Deliberately break the primary in a controlled way. Revoke a test key, point the primary at an invalid endpoint, or block outbound traffic to one host, then confirm the assistant still replies.
Schedule this test rather than trusting the configuration. Fallback paths that have never executed are the ones that fail when they are finally needed.
What does a fallback cost?
Normally nothing, because it only runs when the primary fails. Costs appear only if the fallback serves a large share of traffic, which is itself a signal worth investigating.
Track the share of requests served by each provider over time. A rising fallback share means the primary is degrading and needs attention.
Which primary sources support this page?
Product behavior is checked against the current deployment flow. These external links provide the upstream project or channel documentation used for setup details.
Direct answers
Frequently asked questions
How many fallback providers should I configure?
One working fallback covers most incidents. Add a second only if your availability requirement is high enough to justify the extra credentials and testing.
Does a fallback change the answers users see?
Wording may differ because a different model is answering. Keep the system prompt and tools identical so behaviour stays as close as possible.
Can I use the same provider twice?
Yes, but two models behind the same upstream share a failure domain, so an outage still takes both down.
How do I know the fallback was used?
Check the runtime logs for the provider that served each request, and alert when the secondary provider starts handling traffic.
Key takeaways
- A fallback provider is a second model endpoint Hermes Agent uses when the primary fails, rate limits, or times out. Configure at least one fallback, decide which errors should trigger it, and test the switch deliberately instead of discovering it during an incident.
- Start with one model, one channel, and one controlled test conversation.
- Use managed hosting when deployment speed matters more than operating the server yourself.
Continue the setup
Related Hermes Agent guides
Blog guide
Hermes Agent Provider Routing Across Multiple Models
Route Hermes Agent across multiple model providers by task, cost, and latency. Covers rule design, verification steps, and the failure modes to avoid.
Read nextBlog guide
How to Choose a Model for Hermes Agent
Choose the right Hermes Agent model for support, briefings, operations, and channel workflows across GPT, Claude, Gemini, DeepSeek, Kimi, and GLM.
Read nextBlog guide
How to Set Up Model API Keys for Hermes Agent
Set up Hermes Agent model API keys, choose a provider, validate model access, protect credentials, and prove fallback behavior with smoke tests.
Read nextBlog guide
Run Hermes Agent on Local Models (Ollama and More)
Point Hermes Agent at local models served by Ollama or any OpenAI-compatible endpoint. Covers sizing, context limits, tool calling, and hybrid setups.
Read next