## TL;DR
Wait for the reset window, then cut the call volume: cache responses per run, page efficiently, and replace N+1 REST calls with batched GraphQL where possible. The bot hit the 5,000-requests-per-hour authenticated quota; the immediate fix is backing off until reset, the lasting fix is making fewer calls.

## The error
```text
"API rate limit exceeded for user ID": review bot blocked mid-CI
```

## Steps to fix
1. Confirm it's the primary rate limit: inspect the 403 response headers for a zero remaining count and a reset timestamp - plan the retry for after that time.
   - Expected: the headers name a reset time, usually within the hour.
2. Add retry logic that sleeps until the reset time on rate-limit 403s instead of failing the run.
   - Expected: the next run survives a limit hit by waiting rather than crashing.
3. Cut call volume: cache PR metadata for the duration of the run, request only the fields you need, and replace per-file REST fan-out with one GraphQL query where possible.
   - Expected: the same review completes in a fraction of the API calls.
4. Re-run after the reset.
   - Expected: the run completes; watch the remaining-quota header to confirm headroom.

## Use this when
- A review bot dies mid-run with "API rate limit exceeded for user ID".
- The job reviews large PRs with per-file or per-comment API calls.
- CI runs many review jobs concurrently under one credential.

## Not for this skill when
- The 403 is a secondary rate limit (abuse detection from concurrency, not total count) - lower parallelism instead.
- Calls are unauthenticated (60 per hour) - authenticate first.
- The limit is on a different API (e.g. the search API has its own lower quota).

## Variant phrasings
- github api rate limit exceeded review bot
- review action blocked rate limit mid CI
- API rate limit exceeded for user ID github actions
- bot hit github rate limit during PR review

## Why it happens
GitHub allows 5,000 REST requests per hour per authenticated user (or per app installation). Review bots that fetch every file, comment, and check status individually on big PRs - especially when several jobs share one credential - can burn through that quota in a single run. The limit is per credential, not per repository, so one busy bot starves everything else using the same token.

## Edge cases
- Secondary rate limits trigger on request concurrency, not total count: a highly parallel bot gets blocked with quota to spare - throttle concurrency.
- Unauthenticated calls get 60 per hour; a missing auth header turns a working bot into a failing one instantly.
- GitHub Enterprise Server limits are set by the instance admin and may be lower than github.com.
- Splitting work across multiple bot credentials multiplies the quota but complicates auditing - prefer fewer calls first.

## Provenance

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