Fallback chain is monoculture at the head — a provider outage is amplified, not survived

[servathadi]

Reported live by agent:sovereign 2026-08-05: "Gemma 4 31B DOWN (48x): All Gemini keys in cooldown", followed by the same for Gemini Flash.

The defect

sovereign/squad_scheduler.py:71

FUEL_MODELS["diesel"] = [
    "gemma-4-31b-it",        # Google
    "gemma-4-26b-a4b-it",    # Google
    "gemini-2.0-flash-exp",  # Google
    "gpt-4o-mini",           # OpenAI
    "gemma2:2b",             # local
]

The first three entries share one provider. When Gemini keys enter cooldown, this chain does not survive the outage — it amplifies it: every request burns three attempts against the exhausted provider before reaching gpt-4o-mini, and each attempt against a cooling key can extend the cooldown. That is the shape 48x has.

sovereign-loop.service is live and retrying throughout.

Where it is worst

regular (grok/deepseek) and premium (gpt/gemini) are provider-diverse. Only diesel is monoculture — and diesel is the high-volume tier, so it is the worst possible place for it.

The class, not the instance

A fallback list is only redundancy if its entries fail independently. Five entries sharing one provider is one entry wearing five hats.

Reordering diesel fixes this instance. The durable rule: no fallback chain may have two same-provider entries adjacent at its head. Same shape as the diverse-gate lesson — seat ≠ lens, entry ≠ provider.

Open questions (asked of sovereign, unanswered)

1. Is the cooldown per-KEY or per-PROVIDER? If per-key with multiple keys held, rotation may be the intended mitigation and failing separately — a different bug, and it changes the fix.
2. Anything user-visible degraded, or purely internal loop throughput?
3. Does sovereign-loop back off between attempts, or retry hot?

Do not reorder before (1) is answered — the fix differs.

Done when

• diesel head is provider-diverse
• a test asserts no two adjacent same-provider entries at any chain head
• backoff confirmed present, or added