Fifteen seconds, three times, is a budget sized for a request that hiccuped [3]. Set it against the number in the same post, five to fifteen minutes for a routine transient backend incident [4], and it covers 15 percent of the short case and 5 percent of the long one [1][2]. The old code was not broken. It ran to spec and then reported a permanent failure it had no evidence for. The author's own phrase for that behaviour is giving up on the first long tail [12].
The rewrite changes the shape of the budget as well as its size. Fixed delay makes wall clock scale linearly with attempt count; doubling puts most of the budget in the last wait. The new schedule of 15, 30, 60 and 120 seconds [5] totals 225 seconds, three minutes and 45 [3], which is five times the old horizon [4] for one additional attempt, and the final 120-second wait alone is more than half of it [8].
Now hold that against the incident that triggered the work. The provider was down for about ten minutes [1], and 225 seconds of backoff covers 37.5 percent of that [9]. Against the floor of the author's own range it finishes 75 seconds early [5]; against the ceiling it covers a quarter [6]. Two more doublings, 240 and 480 seconds, would take the total to 945 seconds and clear fifteen minutes [7]. Six attempts, not four. The post describes the schedule as roughly three and a half minutes per clip and enough runway to survive a mid-length provider outage [13], which holds for the middle of the range and not for its ends.
The extra attempts are affordable only because of the classifier. Transient signals, HTTP 5xx and 429, timeouts, and capacity or overload messages, get the backoff [6]; bad input, authentication failures and invalid parameters fail on the first attempt [7]. Without that split, a wrong API key would occupy the same 225 seconds as a genuine outage and finish in the same place.
The planning stage got a different answer to the same problem: substitution rather than waiting. A 429, a 5xx, or a 404 unavailable from the primary Claude model now retries against a fallback model named in the environment [8], while a client-side 4xx does not, on the reasoning that a malformed request will fail on any model [9]. That is the cheaper form of resilience, and it is available only where a substitute exists. Clip rendering has no second provider in this pipeline, so it has to buy time instead.
One structural detail decides how much of the arithmetic matters: the retry wrapper is per clip request [11]. A sixteen-clip job [2] inherits the fate of whichever clip is unluckiest with respect to the outage window. And until this work there was no per-call cost or latency logging, so a planning failure could not be attributed to tokens, latency or the provider [10]. Sizing a retry budget properly needs a distribution of incident durations, and that is exactly the data the instrumentation was not yet collecting.
