Is this the same as the reliability/fail-open page?

No — different concept, same neighborhood. /docs/reliability covers what happens when COGNOCIENT's own backend (the budget-check layer) is unreachable. Provider Failover, this page, covers what happens when your AI PROVIDER (OpenAI, Anthropic, etc.) is down, slow, or rate-limiting you. Independent failure modes, independent settings.

Why is this off by default?

Some teams have data-residency or vendor constraints that make silently retrying against a different provider unacceptable — a call that was supposed to stay within one provider's infrastructure could otherwise land somewhere else without anyone noticing. This must be an explicit opt-in, never a surprise.

How many times will it retry?

Once. If the fallback provider also fails, you get the original error back — not a second failure, and never a cascading retry chain.

Does this replace Degrade mode?

No, they solve different problems. Degrade mode switches to a CHEAPER model on the SAME provider when a budget threshold is crossed — it's a cost-reduction response. Provider Failover switches to an EQUIVALENT-tier model on a DIFFERENT provider when the primary is technically unreachable — it's an availability response. Cost isn't the trigger here; a provider outage is.

What triggers a failover attempt?

A timeout, an HTTP 429 (rate limited), or a 5xx from the primary provider. A 401 never triggers failover — that's your own key misconfigured, and failing over would hide the real fix instead of surfacing it.

How does automatic provider failover work?

Opt-in cross-provider retry when the primary AI provider times out, rate-limits, or errors — one retry hop, never a surprise, never on by default.

When your primary AI provider times out, rate-limits you, or returns a 5xx, Cognocient can retry the same call once against a different provider you've already connected — instead of just failing.

Off by default — opt-in only

Some teams have data-residency or vendor constraints that make cross-provider failover unacceptable. This never turns on by itself: enable it explicitly per account, and it only ever activates if you have at least 2 providers connected.

What triggers it

Condition	Fails over?
Timeout	Yes
HTTP 429 (rate limited)	Yes
5xx from the provider	Yes
HTTP 401 (bad key)	No — this is a configuration problem, not an outage; failing over would hide the fix

How it's different from Degrade mode

	Degrade mode	Provider Failover
Trigger	Budget threshold crossed	Timeout / 429 / 5xx
Target	Cheaper model, same provider	Equivalent-tier model, different provider
Goal	Reduce cost	Maintain availability

They can both be active on the same account without conflicting — a call can be cost-degraded on one request and availability-failed-over on another; they trigger on entirely different conditions.

Setup

Connect at least 2 providers (Settings → AI Providers).
Enable the toggle under Settings → AI Providers → Content Guardrails & Provider Failover — "Automatically retry on a different provider if one is down."

curl -X PATCH https://api.cognocient.com/api/account/failover \
  -H "Authorization: Bearer sk-cog-..." \
  -H "Content-Type: application/json" \
  -d '{"provider_failover_enabled": true}'

Response headers on a failed-over call

x-cog-failover: true
x-cog-failover-reason: 5xx
x-cog-original-provider: openai
x-cog-failover-provider: anthropic
x-cog-original-model: gpt-4o
x-cog-failover-model: claude-sonnet-4-6

Your application can read these to know a call was served by a different provider than requested — useful if response quality/format nuances matter for your use case.

What happens if the fallback also fails

You get the original error back, exactly as if failover weren't enabled — never a cascading retry, never a second distinct error.