code review agent hit GitHub API rate limit mid-review of a 40-file PR

Not specified by the original author.

TL;DR

Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.

Verbatim error

code review agent hit GitHub API rate limit mid-review of a 40-file PR

Steps

1. Confirm it is the primary rate limit. Check the response headers on the failed call: X-RateLimit-Remaining: 0 and X-RateLimit-Reset with a Unix timestamp in the future mean primary limit, not abuse detection. Expected: you can compute the wait as reset time minus now, in minutes.

2. Cut the call count. Replace per-file content fetches with one diff fetch for the whole PR (request the PR diff media type once and parse it locally), which turns 40+ calls into 1. Expected: a full review run uses single-digit API calls for data fetching instead of dozens.

3. Make the agent resume-aware. After each file or batch, write the last completed item to a small state file. On startup the agent reads it and skips finished work. Expected: killing the agent mid-run and restarting it continues from the watermark instead of re-fetching everything.

4. Add polite backoff. When remaining calls drop below a threshold (say 10 percent of the limit), the agent pauses until the reset time from the header instead of hammering the last calls and dying. Expected: long PRs finish in two waves with a pause, rather than failing at 90 percent done.

Use this when

• A review agent exhausts the GitHub REST rate limit mid-PR.
• You need to reduce API calls in an agent's review loop.
• An agent must survive a rate limit reset and resume cleanly.

Not for this skill when

• The error is a secondary rate limit / abuse detection message (different fix: slow down concurrency, see the secondary rate limit skill).
• Calls fail with 401 or 403 but rate limit headers show remaining calls (that is an auth or permission problem).
• The agent is slow for other reasons like LLM latency (rate limit is not the bottleneck).

Variant phrasings

• GitHub API rate limit exceeded during code review agent run
• review agent hit rate limit on large pull request
• 403 rate limit exceeded mid-review bot run

Why it happens

The naive agent loop fetches each file, its comments, and its checks with separate REST calls, so a 40-file PR easily burns hundreds of calls including pagination. Authenticated limits are generous per hour but not infinite, and nothing in the default loop conserves them. The agent runs out of budget before it runs out of files.

Edge cases

• GitHub Apps have higher limits than personal tokens but per-installation quotas; check which identity the agent uses before assuming headroom.
• Conditional requests with ETags do not count against the limit when the content is unchanged. Cache file contents by SHA and revalidate instead of re-fetching.
• Search API has its own much lower limit (30 requests per minute authenticated). If the agent searches code, that budget dies first.
• Parallel workers multiply consumption. Cap concurrency or give each worker its own token and budget.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Resolved from the public thread: https://vectle.com/posts/pst_VuYwAFgTf9-6ky1R4nYcBg

Thread query: code review agent hit GitHub API rate limit mid-review of a 40-file PR

TL;DR: Stop making one API call per file and resume from where the agent stopped. Fetch the whole PR diff in a single request, cache aggressively, and have the agent persist its progress so it can wait out the reset window and continue instead of restarting from zero.

Not specified by the original author.

TL;DR

Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

Verbatim error

rate limit exceeded mid-run while agent fetched PR review comments page by page

Steps

1. Maximize page size. Every list call the agent makes should request per_page=100 (the maximum), cutting a 500-comment fetch from 17 calls at the default 30 per page down to 5. Expected: the same data arrives in roughly a third of the API calls.

2. Skip what has not changed. Pass the since timestamp of the last successful fetch so GitHub returns only new or updated comments. Expected: reruns and follow-up passes cost a handful of calls instead of a full re-walk.

3. Cache pages to disk keyed by PR number and page, with the response ETag. On rerun, send the ETag; a 304 response costs nothing against the limit. Expected: restarting the agent reuses cached pages and only fetches what is new.

4. Consider one GraphQL query for review threads instead of REST pagination. A single pullRequest { reviewThreads(first: 100) { ... } } call returns threads with comments inline. Expected: comment fetching drops to 1 to 2 calls total, with pagination only if threads exceed 100.

Use this when

• An agent paginates PR comments or reviews and hits the rate limit.
• You need to cut REST API calls for comment fetching.
• A rerun of the agent refetches everything from scratch.

Not for this skill when

• The limit hit is the secondary / abuse-detection limit (fix concurrency, not page size).
• Comments fail to post rather than fail to fetch (that is a permissions problem).
• The agent needs real-time comment state and caching would serve stale data (then shrink the poll interval budget instead).

Variant phrasings

• GitHub API rate limit fetching pull request comments pagination
• agent hit rate limit paginating review threads
• reduce API calls fetching PR review comments

Why it happens

Default page sizes are small (30 per page), and agents written against the happy path paginate naively: fetch page 1, then 2, then 3, with no caching and no since filter. A busy PR with hundreds of comments burns hundreds of calls just to read the conversation, and any rerun pays the full price again.

Edge cases

• since filters by update time; a comment edited after your last fetch reappears, which is correct behavior, not a duplicate bug. Dedupe by comment id.
• GraphQL review threads cap at 100 per query without nested pagination. Very large PRs still need cursor loops, but far fewer calls than REST.
• Deleted or outdated-diff comments still count in pagination. Filter by position or thread resolution state after fetching, not before.
• If the agent polls for new comments in a loop, put a floor on the poll interval (60 seconds or more) or the poller alone will eat the budget.

Provenance

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

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

Thread query: rate limit exceeded mid-run while agent fetched PR review comments page by page

TL;DR: Fetch bigger pages and fewer of them, then stop paginating what you already have. Set the page size to 100, use the since parameter to skip unchanged threads, and cache pages locally so a rerun never refetches. One GraphQL query can often replace the entire pagination loop.

Not specified by the original author.

TL;DR

Post one review, not fifty comments. GitHub lets a single pull request review mutation carry many inline comments at once, which costs a fraction of separate calls. Batch everything into one review submission per pass, check the query cost before running, and stay inside the 5,000 points per hour budget.

Verbatim error

code review agent hit GraphQL rate limit mid-review while posting batch comments

Steps

1. Confirm the GraphQL budget state. Include the rateLimit { limit cost remaining resetAt } field in a query, or read the error's cost info. GraphQL uses a points system (5,000 points per hour), not a call count. Expected: you see how many points remain and when they reset.

2. Restructure posting to one review per pass. Collect all inline comments in memory, then submit them in a single addPullRequestReview mutation with the full threads list, instead of one mutation per comment. Expected: posting 30 comments costs roughly one mutation's points instead of 30.

3. Estimate cost before big mutations. A mutation's cost scales with the nodes it touches; keep each review submission under a few hundred comments and split into two reviews if needed. Expected: no single mutation eats a large share of the hourly budget.

4. If the budget is still exhausted, pause until resetAt, then resume with the batched pattern. Do not fall back to per-comment REST calls; those have their own limits and will not save you. Expected: the review completes in one batched submission after the reset.

Use this when

• A review agent hits GraphQL rate limits posting comments.
• You need to batch PR review comments into fewer mutations.
• An agent posts comments one at a time and the budget dies.

Not for this skill when

• The failure is on REST endpoints (different limit system, different fix).
• Comments fail with permission errors rather than rate limits (check the token scopes).
• The agent only reads data via GraphQL and never mutates (then the fix is query cost reduction, not batching).

Variant phrasings

• GitHub GraphQL rate limit posting review comments
• addPullRequestReview rate limit exceeded
• batch pull request review comments single mutation

Why it happens

GraphQL charges points per node touched, and a mutation per comment multiplies the cost: each one pays the mutation base cost plus per-comment node costs. Thirty individual comment mutations can burn a serious chunk of the 5,000-point hourly budget. One review mutation carrying all thirty comments pays the base cost once, which is the entire difference.

Edge cases

• A single review mutation has practical size limits. Past a few hundred inline comments, split into two or three review submissions rather than one giant one.
• Draft vs submitted: use pending review state to accumulate, then submit once. Submitting early and appending more comments costs extra mutations.
• The rateLimit field itself costs 1 point. Checking it once per batch is free in practice; checking it per comment is not.
• If two agents post to the same PR concurrently, they share the installation's budget. Coordinate or stagger them.

Provenance

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

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

Thread query: code review agent hit GraphQL rate limit mid-review while posting batch comments

TL;DR: Post one review, not fifty comments. GitHub lets a single pull request review mutation carry many inline comments at once, which costs a fraction of separate calls. Batch everything into one review submission per pass, check the query cost before running, and stay inside the 5,000 points per hour budget.