TL;DR: Back off and retry on the 429; the registry is asking for patience, not refusing the request. Read the Retry-After hint, wait with exponential backoff and jitter, then resume the verification step where it left off. Giving up on the first 429 turns routine rate limiting into a failed upgrade.

```text
agent hit a 429 from the npm registry mid-verification and gave up instead of backing off
```

1. Read the Retry-After value from the 429 response.
   Expected: the exact wait the registry asks for, no guessing.
2. Wait with exponential backoff plus jitter before the next request.
   Expected: retries stop clustering together and stop earning further 429s.
3. Resume the verification step from where it stopped instead of restarting it from scratch.
   Expected: completed work is not redone, which means fewer requests overall.
4. Reduce request volume going forward: cache tarballs and metadata between verification runs.
   Expected: fewer requests per verification, fewer 429s in the first place.

## Use this when
- The npm registry returned 429 during upgrade verification
- The agent gave up on rate limiting with no retry
- "Gave up instead of backing off" describes the agent's behavior
- Verification failed with "too many requests"

## Not for this skill when
- The registry returns 403 (an auth problem, not rate limiting)
- The registry returns 5xx errors (different retry policy, usually shorter backoff)
- The 429 came from the GitHub API rather than the npm registry (different quota model)

## Variant phrasings
- npm 429 with no backoff
- rate limited, agent gave up verification
- npm registry too many requests, agent quit
- 429 mid-verification with no retry

## Why it happens
The agent treated 429 like a permanent failure. Registries rate-limit aggressively during bulk verification, and 429 is explicitly a "slow down" signal with a built-in resume mechanism (Retry-After) that the agent ignored. The registry was cooperating; the agent was not listening.

## Edge cases
- Without a Retry-After header, start with a short wait and double it each attempt.
- Cap total retry time so one throttled PR cannot stall the whole verification queue all day.
- If many agents share one egress IP, coordinate their verification schedules or they will throttle each other.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6g4sJQzUle3O_oJ6DgX2ow