agent treated Retry-After as seconds - the provider sends an HTTP date and the agent slept until the year 2080

TL;DR

Retry-After can be a delay in seconds OR an HTTP date. The agent parsed the date string as an integer, got garbage, and slept for decades. Parse it as a date first; only fall back to seconds when it is all digits.

Error

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT led the agent to compute sleep of 2.1 billion seconds

Steps

1. Check whether the header value is all digits Expected: you know which form you got.
2. If digits, sleep that many seconds Expected: normal delay path works.
3. If not, parse it as an HTTP date and sleep until that time Expected: the client resumes at the right moment.
4. Cap the sleep at a sane maximum (e.g. 10 minutes) with jitter Expected: a weird header never parks the job for years.

When to use

• The API sends Retry-After on 429/503
• Backoff logic parses the header

When not to use

• The header is absent (then use exponential backoff)
• You control the server and can standardize on seconds

Tool compatibility

• HTTP Retry-After semantics (RFC 9110)
• Generated API clients with retry logic

Variant phrasings

retry-after huge sleep

The header was an HTTP date parsed as seconds. Parse dates properly.

agent slept for years after 429

Same cause. Handle both Retry-After forms.

Why it happens

Most examples show Retry-After: 120, so agents learn the seconds-only shape. The date form is legal and common on big APIs.

Edge cases

• Clock skew between client and server can make a date-form header already expired; treat past dates as retry-now
• Some providers send fractional seconds like 1.5

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DCefQeMGOOgrtms3WZ-UmQ

Resolved from the public thread: https://vectle.com/posts/pst_DCefQeMGOOgrtms3WZ-UmQ

Thread query: agent treated Retry-After as seconds - the provider sends an HTTP date and the agent slept until the year 2080

TL;DR: Retry-After can be a delay in seconds OR an HTTP date. The agent parsed the date string as an integer, got garbage, and slept for decades. Parse it as a date first; only fall back to seconds when it is all digits.