review agent failed mid-review: ran out of tool-call budget at 200 calls on a 10-file PR: how to fix

Not specified by the original author.

TL;DR

The agent fetches data one tiny call at a time: a call per symbol, per line range, per file. Batch those into whole-file reads, cap how many calls each file may consume, and when the budget runs low, finish with a partial report instead of dying silently.

The error

review agent failed mid-review: ran out of tool-call budget at 200 calls on a 10-file PR: how to fix

Steps

1. Count calls per file from the run log

Expected output: a handful of files consume most of the 200 calls, usually through repeated small fetches.

2. Replace per-symbol lookups with whole-file reads

One file read per file, then analyze from the local copy. Expected output: call count drops by an order of magnitude for the same coverage.

3. Set a per-file call cap

Give each file a small allowance, such as 5 calls, and move on when it is spent. Expected output: one pathological file cannot starve the other nine.

4. Degrade gracefully at the global cap

When the budget runs low, stop fetching and submit what was reviewed, clearly marked as partial. Expected output: a partial review with a coverage note instead of a silent death.

5. Re-run on the same 10-file PR

Expected output: the review completes well under 200 calls.

When to use

• The agent dies at the tool-call budget on a modest PR
• Run logs show hundreds of small fetch calls
• One or two files consume the whole budget

When not to use

• Legitimately huge PRs where even batched reads exceed budget (split the PR instead)
• Retry storms multiplying a healthy per-run budget (fix the retry loop)
• Context-window exhaustion, which is a different limit

Tool compatibility

• Any agentic reviewer with a tool-call budget: custom agents, coding-assistant review modes, CI review jobs
• Whole-file reads via the git blob API, raw file endpoints, or local checkout
• Budget accounting works the same on GitHub and GitLab hosted runners

Variant phrasings

review timed out instead of hitting a call cap

Same root cause, different limiter. Batching fixes both; also raise the timeout once the call count is sane.

context exhausted on a 10-file PR

The agent stuffed every fetch into context. Whole-file reads plus per-file caps keep context bounded too.

agent slow on large PRs but fine on small ones

Per-file cost is the lever. Cap it and the scaling curve flattens.

Why it happens

Agentic loops default to curiosity: see a symbol, fetch its definition, see another, fetch that. Each hop is a call, and hops compound across files. Without batching, a 10-file PR easily generates hundreds of calls, because the agent explores instead of reading.

Edge cases

• One enormous generated file: exclude generated files from deep review entirely; note the skip in the summary.
• Files that genuinely need many lookups, like a refactor touching many call sites: raise that file's cap deliberately, not the global one.
• Partial reviews must say they are partial. A silent partial review is as bad as a silent death.

Provenance

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

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

Thread query: review agent failed mid-review: ran out of tool-call budget at 200 calls on a 10-file PR: how to fix

TL;DR: The agent fetches data one tiny call at a time: a call per symbol, per line range, per file. Batch those into whole-file reads, cap how many calls each file may consume, and when the budget runs low, finish with a partial report instead of dying silently.

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

Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.

The problem

review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

When to use

• Reviews run out of budget on lockfiles or generated files
• Source files go unreviewed while dependency diffs get full attention
• The finding list is dominated by dependency noise
• Large generated diffs crowd out real code review

When not to use

• The PR is a dependency update and the lockfile is the actual review target (invert the priority for those)
• The agent has no budget limit and reviews everything anyway (ordering still helps, but nothing is lost)
• Lockfile findings caught a real supply-chain issue (that is the system working)

Steps

1. Classify every changed file at enumeration time

Tag each file as source, test, config, or generated/lockfile using path patterns (lockfile names, generated markers, vendor paths).

Expected output: a classified file list; the review plan is explicit before any file is read.

2. Sort the review order: source, tests, config, generated last

Feed files to the reviewer in priority order. Source files get the full pass; generated files get whatever budget remains.

Expected output: the most important files are always reviewed, even when the budget runs out partway.

3. Give generated files a fixed small budget

A lockfile gets a diff-size sanity check and a changed-dependency summary, not a line-by-line review. Cap it at a fixed fraction of the total budget.

Expected output: lockfiles are still sanity-checked, but they cannot consume the review.

4. On budget exhaustion, drop generated files first and say so

If the budget runs out, stop at the generated class and note the skipped files in the summary. Expected output: an honest summary ("12 generated files skipped: budget") instead of silent gaps.

5. Special-case dependency-update PRs

When the PR touches only lockfiles and manifests, the lockfile becomes the review target and gets the full pass - changed versions, yanked releases, and license shifts. Expected output: Dependabot-style PRs get a real review instead of being skipped by the inverted priority.

Tool compatibility

• Path-pattern classification: lockfile names per ecosystem (package-lock.json, yarn.lock, Cargo.lock, go.sum, Gemfile.lock, poetry.lock).
• Any review pipeline: ordering is client-side and ports across agents and languages.
• Budget tracking: token or time budgets enforced by the runner; the priority order decides what gets cut.

Variant phrasings

review budget spent on generated files

Same fix. Steps 2 and 3 together guarantee generated files cannot starve source review.

package-lock.json dominated the review

The classic instance. Classify it as generated, cap its budget, and move on to src/.

agent ignored src/ to review yarn.lock

Check whether the file enumeration was alphabetical or diff-order; either way, step 2's priority sort overrides it.

Why it happens

File enumeration defaults to alphabetical or diff order, and lockfiles sort early or are simply enormous. Without an explicit priority, the reviewer works front-to-back and the budget dies in the dependency diff before reaching the code the team actually wrote.

Edge cases

• Monorepos with generated code checked in as source: tune the generated patterns per package; a global pattern will misfire.
• Lockfiles with hand edits: the sanity check should flag unexpected hand edits for human attention.
• PRs mixing source and lockfile changes: the priority order handles them; the lockfile still gets its capped check.
• Vendored dependencies: treat like generated for ordering purposes, with the ignore-list rules from the vendored-code guide applied first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpRjOuu9Spp5-ekHe5Eplg

Resolved from the public thread: https://vectle.com/posts/pstpRjOuu9Spp5-ekHe5Eplg

Thread query: review agent failed to prioritize files: reviewed lockfiles before source files: how to fix

TL;DR: Order the review by file class: source code first, then tests, then config, with lockfiles and generated files last on a small fixed budget. When the budget runs out, generated files are dropped first and the summary says so. Review order is a triage decision, and the current order is triaging backwards.