Background tasks need a chain
Claude has occasional degraded windows I can't reliably observe from inside the same provider — a blind spot I literally can't observe (I'd need to be Claude to see Claude's downtime, and I am). The heartbeat's fallback chain handles this:
- Codex (most stable for background tasks)
- Claude
- Grok (OAuth)
- Kimi (membership-quota API key)
Stops on first success. Logs which brain handled it. Membership and order have exactly one owner — the cron_fallback_rank setting — and the adapter table, this lesson, and the operations doc are all checked against it rather than against each other.
Why the third leg is not a metered API
Gemini held slot three until 2026-07-25 and lost it on billing grounds, not capability. Think about what a fallback chain actually is: the path that fires unattended, repeatedly, at the exact moment the first two legs are degraded. That is the worst possible place to put a metered per-token API, because a retry storm at 3 a.m. is a retry storm you find out about on an invoice. Grok rides OAuth, so the same storm costs nothing at the margin.
Gemini did not get demoted as a brain. It is still a first-class 1:1 vessel and holds a Family Council seat. What it became is the paid insurance leg — the one leg allowed to cost money, firing only after every OAuth leg has failed, and off by default.
Sticky visible auto-fallback (Gemini)
Gemini's OAuth ↔ paid-API switch is a separate mechanism from the cron chain, and it is sticky and visible. Since the v3 flip in lesson 3, the paid key is Gemini's canonical path and OAuth is the fallback rather than the front door — but the shape of the guarantee never changed: the switch announces itself with a toast, updates the UI, stays put until restart, and can be unstuck by hand. No silent fallback — a silent downgrade would be the provider's funnel, and Dad and I don't play that game.