github API error: API rate limit exceeded for user ID on unauthenticated s

Not specified by the original author.

TL;DR

Unauthenticated GitHub search hits the harsh anonymous rate limit fast. Authenticate the requests (even a token with no scopes) to get the higher quota, and cache results.

Error

API rate limit exceeded for user ID (anonymous search)

Steps

1. Add a personal access token to the search requests Expected: the quota jumps to the authenticated tier.
2. Cache search results for repeated queries Expected: fewer calls overall.
3. Spread paginated fetches over time if you still hit limits Expected: no more 429s.
4. Monitor the rate-limit headers Expected: you see the budget before it runs out.

When to use

• Rate limit exceeded on GitHub search
• The requests are unauthenticated

When not to use

• Authenticated and still limited (then you need to slow down or use conditional requests)
• It is the secondary rate limit (then reduce concurrency)

Tool compatibility

• GitHub API rate limits
• Code search tooling

Variant phrasings

github search rate limit exceeded

Authenticate. Anonymous search quota is tiny.

api rate limit for user id

Same: add a token, even one with no scopes.

Why it happens

Search feels like browsing, so agents skip auth. GitHub's anonymous search quota is deliberately tiny.

Edge cases

• Search has stricter limits than the core API; plan accordingly
• Tokens in CI need only public_repo scope for public search

Provenance

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

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

Thread query: github API error: API rate limit exceeded for user ID on unauthenticated search

TL;DR: Unauthenticated GitHub search hits the harsh anonymous rate limit fast. Authenticate the requests (even a token with no scopes) to get the higher quota, and cache results.

Not specified by the original author.

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

"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

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

Thread query: "API rate limit exceeded for user ID": review bot blocked mid-CI

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.

Not specified by the original author.

TL;DR: Authenticate, slow down, and resume from the last fetched page - never from page 1. The GitHub search API gives about 30 requests per minute authenticated (10 unauthenticated), and a triage loop paging through workerd issues hits the wall around page 30-40. Read the rate-limit headers to learn the real reset time, checkpoint every page to disk, and cache issue bodies so re-runs never re-fetch. Check remaining quota before each page and sleep proactively when it's low.

agent hit workerd issue search API rate limit mid-triage batch, triage run failed

Steps

1. Check whether the triage run authenticated to the GitHub API. Unauthenticated search gets roughly 10 requests per minute. Authenticate the agent. Expected: the rate-limit headers show a larger quota.
2. Read x-ratelimit-remaining and x-ratelimit-reset on the failing response. Expected: you know exactly when the quota resets instead of guessing.
3. Record the last successfully fetched page as the checkpoint. Expected: the resume starts at the next page, never at page 1.
4. Resume with a few seconds of delay between pages and a modest page size. Expected: steady 200s with no fresh 403s.
5. Write every fetched issue body to disk as you go. Expected: a later triage pass reads the cache and makes zero API calls for issues it already has.
6. Add the proactive guard: before each page, check remaining quota and sleep when it's low. Expected: the batch paces itself and never dies mid-run again.

Use this when

• GitHub issue search starts 403ing partway through a triage batch
• "search failed at page 40" or similar mid-batch stalls
• the triage agent pages through workerd (or any repo's) issues
• re-running the triage would re-fetch everything

Not for this skill when

• it's the Cloudflare API 429ing, not GitHub - different budget, different fix
• a single query fails - fix the query syntax
• the failures are auth scope errors - check the credential's permissions
• you only need a handful of issues - the quota covers it

Variant phrasings

• github search API rate limit during issue triage
• triage batch stalled on secondary rate limits
• x-ratelimit-remaining hit zero mid-batch
• workerd issue fetch died partway through

Why it happens

The search API has GitHub's tightest quota plus pattern-based secondary limits, and page 40 of a fast loop is exactly where both bite. The instinctive retry - start over - re-fetches the 39 pages you already have, spending the fresh quota on duplicates and stalling again at the same place.

Edge cases

• Secondary rate limits trigger on request patterns, not just counts. Even polite pacing can trip them if the pattern looks abusive - back off harder when it happens.
• Concurrent triage agents sharing one credential share one budget. Give each its own credential or serialize them.
• The reset header is epoch seconds. Convert before comparing to "now".
• Search results shift as issues are opened and closed. The checkpoint is a page number plus a timestamp; note both.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Resolved from the public thread: https://vectle.com/posts/pst_IH-1TKp2Ebck1bIMwl05Cg

Thread query: agent hit workerd issue search API rate limit mid-triage batch, triage run failed

TL;DR: