A Schedule That Survives 429s: Backoff and Jitter for Agent Automation

Implementing Full Jitter

There are several jitter schools, but the one I use in my indie automation is Full Jitter: pick the wait as a uniform random value within the exponential ceiling. The formula is simple — just wrap it in random.uniform(0, cap).

import random, time
 
def backoff_sleep(attempt: int, base: float = 1.0, cap: float = 30.0) -> float:
    # Grow the ceiling exponentially, then pick uniformly within it (Full Jitter)
    ceiling = min(cap, base * (2 ** attempt))
    delay = random.uniform(0, ceiling)
    time.sleep(delay)
    return delay

Setting a cap is the key. Forget it, and as attempts climb the wait balloons to minutes, eating into the next scheduled cycle. For overnight jobs I fix cap=30 seconds and refuse to wait longer.

Waiting isn't the whole story — respect what the server tells you, too. Many APIs return a Retry-After header alongside the 429. When it's present, prefer the server's instruction over your own math.

def next_delay(attempt: int, retry_after: float | None) -> float:
    if retry_after is not None:
        # Honor the server hint, add just a touch of jitter
        return retry_after + random.uniform(0, 1.0)
    ceiling = min(30.0, 1.0 * (2 ** attempt))
    return random.uniform(0, ceiling)

Hold both a retry cap and an overall deadline

Even with jitter spreading the timing, allowing infinite retries creates a different problem: you wait endlessly on a non-transient failure and the whole schedule slips backward. So I hold two caps.

One is the attempt count. For parallel jobs I cap it at six. The other is the job's overall deadline — a wall drawn in time: "give up if this job hasn't finished within ten minutes of starting." Count alone can over-persist when Retry-After is long, so the time wall earns its keep.

import time, random
 
def run_with_retry(call, max_attempts: int = 6, deadline_s: float = 600.0):
    start = time.monotonic()
    for attempt in range(max_attempts):
        try:
            return call()
        except RateLimitError as e:
            if time.monotonic() - start > deadline_s:
                raise  # the time wall; stop persisting, send to the dead letter
            time.sleep(next_delay(attempt, getattr(e, "retry_after", None)))
    raise RuntimeError("max attempts exceeded")

Throwing the abandoned job upward and diverting it to the dead letter pattern connects retry and divert cleanly. Deciding how long to persist actually raises the overall completion rate.

In parallel runs, scatter the "simultaneous launch"

It's worth scattering not just retry timing but the initial launch timing too. Running four sites, the change with the biggest payoff was dead simple: offset each site's job start time by tens of minutes. Antigravity 2.0 puts parallel agent execution front and center, so it's tempting to fire everything at once — but since they share a common quota, aligning launches makes you trip the limit on the very first call.

As a practical rule, I keep three things. First, don't get greedy with parallelism given the shared quota. Second, spread start times across off-peak hours so job peaks don't overlap. Third, always add jitter to retries and never use a fixed interval. Those three alone make 429 cascades far less likely.

Rate limits are an unavoidable counterpart, but how you move decides between "wiped out" and "a mild delay." Building one idea — deliberately scattering timing — into the design visibly changes the completion rate of agents running in parallel while you sleep. Start by swapping a single fixed-interval retry for Full Jitter. I hope it helps anyone stuck in the same 429 traffic jam.