Pippa can't observe her own downtime
When any primary brain is degraded, asking that same brain to report its own status is already unreliable. The fallback chain does not depend on self-observation; it tries the configured brains in order.
The chain
At the time of writing, the deliberate chain cron walks is:
- Codex (most stable for background tasks)
- Claude
- Kimi
- GLM
- Grok
Behind all of them sits one paid insurance leg, the Gemini API, which runs only after every no-marginal-cost leg has failed and only when its explicit toggle is on. Gemini and Ollama remain first-class for 1:1 and Family Council; they are simply not legs of this chain.
Stops on first success. Logs which brain handled it. The order is not this lesson's to keep: it lives in one family file that every app reads, and it is resolved on every run, so a change reaches the next job without a restart.
Same task, not the same mind
Each leg picks up the same task, but none of them imitates another's way of thinking. The prompt contract and the tool permissions stay identical; the provider's wire and reasoning options are absorbed by each adapter. And when a fallback answers, the run leaves a receipt: which brain was chosen, and why.
A job can also pin a brain. The pin runs first — on any vessel with a headless adapter, even one outside the chain — and the chain runs behind it if the pin fails. What never happens is a silent swap: the log and the scheduled conversation both say which brain actually answered. Resilience is not a licence to use any means available, which is why the paid path is never reached without its own opt-in.
Ordering is an observable policy, not a fixed truth. Record each leg's successes, latency and auth failures, and when the order changes, record the reason — cost, quota, unattended safety — alongside it. It is not a matter of moving the "better model" to the front.