Multi-Provider Failover

Failover is the advanced routing layer for users who rely on more than one provider route.

Its job is simple: if the preferred route cannot or should not handle the next request, Abolitus can try another route according to your policy.

What Failover Actually Controls

Failover sits on top of your active route plus your configured fallback route list.

In plain terms:

• you choose a primary route,
• you define additional routes that are allowed to take over,
• and Abolitus builds an ordered execution chain from that policy.

This is the difference between "I have multiple providers" and "I have a continuity strategy."

Why Use Failover

Use failover when you want protection against:

• provider outages,
• rate limits,
• cost spikes,
• missing capabilities on the current route,
• or route mismatch for a specific task.

Without failover, a route failure is usually just a hard stop.

With failover, it becomes a controlled downgrade path.

Important Scope Note

Failover settings are device-local.

That is because they depend on the actual provider routes configured on that device.

If another device has different providers available, the fallback chain may be different there too.

This is one more reason not to assume that synced creative preferences automatically imply identical runtime behavior everywhere.

Strategy Types

Manual

Use your explicit provider order.

This is best when you already know exactly which route should be second, third, and fourth.

Balanced

Balanced aims for a more even compromise across available candidates.

This is useful when you do not want to optimize for one factor alone.

Capability

Capability prefers routes that better match the requested feature set.

This is the right strategy when advanced controls matter more than raw familiarity.

Adaptive

Adaptive reacts more aggressively to live conditions and provider health rather than acting like a static checklist.

This is useful when reliability matters more than keeping a rigid order.

Preference Flags

Failover can also be shaped by preferences such as:

• prefer local,
• prefer lower cost,
• require reasoning support,
• require logit-bias support.

These are important because not every route is equally capable.

If a route does not satisfy a hard requirement, it should not be trusted just because it exists in your library.

What Capability-Aware Failover Solves

Capability-aware fallback is especially helpful when you depend on advanced controls.

For example, a route that lacks reasoning support or logit bias may be an unacceptable fallback for one workflow but perfectly fine for another.

That means failover is not only about uptime. It is also about preserving the minimum viable quality bar for the scene.

Health and Runtime Conditions

Some failover strategies can take route health into account rather than blindly obeying a static list forever.

That matters because the best fallback on paper is not always the best fallback right now.

If one provider is unstable, lagging, or error-prone, a health-aware strategy can keep the chain usable instead of repeatedly walking into the same failure.

When Failover Helps Most

You rely on a cloud model but need continuity

If the preferred cloud route is unavailable, failover can keep the scene moving instead of forcing a hard stop.

You want to save money when the stronger route is unnecessary

Fallback logic can help easier workloads land on cheaper candidates.

You care about specific advanced controls

If a scene depends on a capability such as reasoning or logit bias, failover can filter out routes that do not satisfy that requirement.

Caveat: Same Scene, Different Route, Different Feel

Failover protects continuity, but it cannot guarantee identical style.

If a conversation jumps from one model family to another, you may notice differences in:

• tone,
• verbosity,
• obedience,
• refusal behavior,
• and character voice texture.

That is normal.

Continuity is not sameness.

Best Practices

Put the most trustworthy route first

Failover is not an excuse to avoid choosing a good primary route.

Keep the fallback list short and intentional

Too many routes can make behavior harder to predict and harder to debug.

Use hard capability requirements when the scene depends on them

If a workflow truly needs reasoning or logit bias, say so explicitly instead of hoping every route can fake it.

Re-check style after a failover event

If the scene survives but suddenly feels different, the fallback may be functioning correctly while still needing a human judgment call.

Related Pages

• Read Multi-Provider Routing for the broader route-library strategy.
• Read Prompt Wrappers and Jailbreaks if the issue is refusal style rather than route availability.
• Read Billing and Premium if one of your fallback decisions is driven by cost.