Exponential Backoff + Jitter

Background

Every real tool call hits transient failures - 429 rate limits, 503 service unavailable, network blips. Exponential backoff with jitter is the standard retry schedule: each attempt waits longer than the last, plus a random delay so concurrent clients don't lockstep retry into the same outage.

Problem statement

Implement backoff_schedule(n_attempts, base=1.0, cap=60.0, jitter=True, seed=0). Return the delay (seconds) to wait before each of the n_attempts retries.

$$d_i \;=\; \min(\text{cap},\ \text{base}\cdot 2^i),\qquad d_i \;\mapsto\; \text{Uniform}(0, d_i)\text{ if jitter}$$

(AWS-style "full jitter".)

Input

• n_attempts - int >= 1, number of retry delays to produce.
• base - float, initial delay (default $1.0$).
• cap - float, max delay (default $60.0$).
• jitter - bool, full-jitter vs deterministic (default True).
• seed - RNG seed.

Output

• list[float] of length n_attempts.

Examples

Input: n_attempts=4, base=1.0, jitter=False
Output: [1.0, 2.0, 4.0, 8.0]

Constraints

• n_attempts >= 1, base > 0, cap >= base. ValueError otherwise.
• Jittered delays must lie in $[0, \text{cap-base})$.

Notes

• Why jitter. Without it, 1000 simultaneous clients all retry at exactly the same delay - the system hits a peak load spike each time. Jitter spreads them out.
• Capped exp. Without the cap, the 15th retry would wait $2^{15}$ seconds (~9 hours).