Reliability Mode and fallbacks

How Aimogen Pro Reliability Mode handles provider failures with ordered fallback models, capability-aware skipping, model cooldowns and a provider circuit breaker.

Reliability Mode, added in 2.8.7, turns the plugin fallback handling from "retry, then pick a random alternative" into an ordered, capability-aware failover system.

It is off by default. Enabling it changes behaviour, so existing sites are not affected by an update.

Enable it#

Aimogen Pro › Settings › Advanced AI Settings

A sensible fallback list#

Order matters. Put the closest substitute first, and make sure at least one entry is on a different provider so a provider-wide outage is survivable:

gpt-5-mini
claude-sonnet-5
gemini-3.5-flash
llama-3.3-70b-versatile

Only models from providers you have actually configured are usable. The plugin checks that a provider has credentials before failing over to it.

What happens on a failure#

1. The error is classified into one of nine categories, by matching the provider error text.
2. Non-retryable categories stop immediately. safety and context are not retried on another model, because a blocked prompt will be blocked again and an oversized prompt will still be oversized.
3. The failing model is put on cooldown for the configured number of minutes, unless the category is one that key rotation should handle instead.
4. The next compatible fallback is selected.
5. The request is retried on that model, up to Maximum Fallback Attempts switches.

Error categories#

An unmatched error is classified unknown and is not cooled down — the plugin does not penalise a model for an error it cannot interpret.

Capability-aware skipping#

A fallback is only used if it can actually do the job. The plugin compares the candidate against the request context: if the original call needed vision, tool calling or streaming, candidates without that capability are skipped rather than tried and failed.

This is why the ordered list can be long without being wasteful — irrelevant entries are passed over.

Cross-provider failover#

Fallback Provider Scope has two values:

Use same_provider when you have a contractual or compliance reason to keep data with one vendor — for example an Azure deployment chosen for data residency. Use cross_provider otherwise: a provider outage is the single most common cause of a failed run, and staying on that provider will not help.

Model cooldowns#

When a model fails with a cooldown-eligible category, it is skipped for Failure Cooldown (Minutes). The cooldown is stored as a transient keyed on the model name.

This prevents the pattern where a bulk run of fifty posts hits the same rate limit fifty times.

The provider circuit breaker#

Repeated failures escalate from the model to the whole provider.

The rule in 2.8.8: when a provider accumulates two failures of category network or provider within the cooldown window, the entire provider is put on cooldown for the same duration. Every model belonging to it is then skipped until the cooldown expires.

rate_limit also counts toward the provider breaker, but only when key rotation is off or no healthy key remains for that provider. A rate-limited key while other keys are healthy is a credential problem, not an outage.

Credential, quota and model errors stay model-scoped rather than provider-scoped, because an installation can hold several keys and model access varies per account.

Interaction with the retry count#

Reliability Mode raises the effective retry budget for the current request only:

effective_retries = max( your max_retry setting, min( fallback_count, max_attempts ) )

Your saved How Many Times To Retry API Calls In Case Of API Failure value is never overwritten. The adjustment applies to the in-memory settings copy for that one request.

Behaviour when Reliability Mode is off#

The Ordered Fallback AI Model List still works, but with the older behaviour: a fallback is chosen at random from the list rather than in order, and there is no capability checking, no cooldown and no circuit breaker.

If you have a fallback list configured, turning Reliability Mode on is a strict improvement.

Monitoring#

System & Logs › System Info includes Reliability Mode status and recent recovery details, added in 2.8.7. It reports which models or providers are currently on cooldown and why, without ever printing a raw API key.

System & Logs › Activity Logs shows the original error that triggered a failover.

The aimogen_reliability_failover action fires on each switch, so you can log or alert on it:

add_action( 'aimogen_reliability_failover', function ( $from_model, $to_model, $category ) {
    error_log( sprintf(
        'Aimogen failed over from %s to %s (%s)',
        $from_model, $to_model, $category
    ) );
}, 10, 3 );

Recommended production configuration#

Enable AI Reliability Mode:   on
Fallback Provider Scope:      cross_provider
Maximum Fallback Attempts:    3
Failure Cooldown (Minutes):   10
Smart API-Key Rotation:       on

Ordered Fallback AI Model List:
  <your primary model>
  <a sibling from the same provider>
  <a comparable model from a second provider>

Related#

• Smart API-key rotation
• Errors, retries and timeouts
• API and provider errors