A FallbackAdapter tries each model in sequence, falling back on rate limits (429) or server errors (503).
The fallback chain is essential for production reliability. If the primary model is rate-limited or experiencing downtime, the agent automatically degrades to a capable alternative rather than failing entirely.
Different failure modes, different paths
cwkPippa's brain fallback is Codex → Claude → Gemini per task, with explicit per-task overrides. Why three providers? Each is degraded ~4h/day in different windows; the chain absorbs it. Why not just one with retries? Because the failure isn't random — when Claude's having a bad hour, retrying Claude five times is five guaranteed failures.
The 2-of-2 pattern within a single provider also matters: native vision + Read-tool fallback (cover model degradation), OAuth + API-key (cover identity-layer outage), SQLite + JSONL (cover store corruption). Each pair is deliberate. 'Cleaning up' one path because it 'looks duplicate' creates a single point of failure.