## 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
```text
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