Every failover we have ever executed had a forcing function. The dependency was gone, the work was piling up, and the only available direction was toward the fallback. The switch back had none of that. When our flagship model returned on July 1, after nineteen days offline under an export-control order, nothing was broken. The fallback routing was working. The degraded-mode rules were holding. And that is exactly what made the return trip the more delicate operation of the two.
We have already written about which of the June mitigations we kept and which we rolled back. This is about the step before that review: the act of switching back itself, which our runbook covered, in full, with the words “revert routing.” Those two words were hiding a four-day migration.
Failback is a migration nobody rehearses
The asymmetry starts with who decides. A failover is decided by the outage. The timing, the scope, the urgency, all of it is imposed, and in a strange way that makes it simple. There is one direction to move and a clear signal for when to move. A failback is decided by nobody. The moment the dependency returns, every part of the switch becomes a choice, and every choice arrives with a quiet question attached about why it should happen now rather than tomorrow.
That missing forcing function pushes teams toward one of two failure modes. The first is deferral. The fallbacks work, the switch is nobody’s emergency, and the temporary configuration ages in place until it is load-bearing. The second is the opposite: the big flip. Switching back feels like going home, home is safe, so the whole system gets pointed at the restored dependency in one motion, with none of the caution that would accompany pointing it at anything new. Both failure modes come from the same place, which is treating the return as a non-event because the destination is familiar.
We had planned for degradation in detail. We had pages on which work pauses, which continues on weaker models, which fails loudly. We had nothing equivalent for the return, because during the outage the return was an abstraction, a happy ending that would presumably organize itself. It does not organize itself. A failback is a migration with all the moving parts of the original failover, minus the adrenaline that makes people careful.
The system it left no longer existed
The deeper surprise was realizing that “switching back” was not an accurate description of anything we could do. The model came back. The system it left had been gone for weeks.
Nineteen days of adaptation had accumulated everywhere. Prompts had been re-tuned around the fallback models’ habits. Work had been re-scoped to fit smaller context budgets. Review thresholds had been adjusted to catch the specific mistakes the substitutes made. None of that was wrong, all of it was the mitigation doing its job, but it meant the state we were returning to was not a snapshot of June 11. It was a new configuration that happened to include an old component. Restoring the component does not restore the system, the same way moving back into a renovated house is not moving back into the house.
There was also a question we decided we were not entitled to skip: whether the model that came back was the model that left. The suspension began with a jailbreak found by outside researchers. It was entirely plausible that the restored version would return patched, with different refusal behavior or different edges. So before routing any real work to it, we re-ran our canary set, a small collection of tasks with archived known-good outputs from before June 12, against the restored model and compared. The comparison came back clean, indistinguishable on everything we could measure. But the point was never the result. The point was that “restored” is a claim the provider makes, and trusted is a state we have to re-enter ourselves. A returning dependency deserves the same onboarding as a new one. It just clears it faster.
The smallest decision here turned out to be one we would repeat without hesitation: in-flight work stayed where it started. Tasks that were mid-stream on a fallback model finished on that fallback model, even when the stronger one was sitting there available. A document half-written by one mind and half-written by another reads like exactly that, and a code change reviewed under two different sets of instincts is harder to trust than one reviewed under either alone. Consistency of a weaker model beat a mid-task upgrade every time we weighed it.
The order of return
We switched tiers back in reverse order of how we had degraded them, and the logic only became obvious after we noticed we were doing it.
The work that had paused entirely in June, the public-facing writing and anything touching infrastructure, came back first. It had a backlog, it had no substitute, and it was the reason we wanted the model back at all. The work that had continued acceptably on fallbacks came back last, precisely because it was in the least trouble. Urgency ordered the queue, and urgency lived with the work that had been waiting, not the work that had been coping.
That ordering has a trap at the end of it, though. The last thing scheduled to switch back is, by construction, the thing that adapted best to the fallback, which means it is also where the outage-era debt is most comfortable. The re-tuned prompts, the adjusted thresholds, the special-case handling, all of it works, and working is the best camouflage temporary things ever get. We could feel the pull to leave that tail on the fallback for a while, since it was fine. That pull is how temporary becomes permanent, so we set a hard boundary instead: everything back on the standard tier mapping by end of week, and the fallback-specific prompt forks deleted the day after, so the outage configuration was not merely unused but unreachable. A failback is not finished when the traffic moves. It is finished when nothing can quietly depend on the old emergency by accident.
The whole exercise left us with one durable change to how we write incident plans. The return path is now written on day one of the outage, alongside the degradation rules, while the details are sharp and the motivation is real. Not because the plan will survive contact with the actual return, ours would not have, but because a failover without a designed failback is a one-way door, and outages that end are the common case. Things come back. The next time something we depend on disappears, the first document we write will be about the morning it does.