review agent failed mid-review: ran out of tool-call budget at 200 ca

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

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.

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.