1
# Setting the numbers
2
3
Start from the task shape, then tune from real runs. These defaults are deliberately
4
tight. A budget nobody ever hits is not doing any work.
5
6
| Task shape | Tool calls | Wall clock | Notes |
7
|---|---|---|---|
8
| Answer a question about a repo | 10 | 120s | Mostly reads. More than this means the search is wrong. |
9
| Fix a well-specified bug | 40 | 900s | Read, edit, test, iterate once or twice. |
10
| Open-ended investigation | 80 | 1800s | Wide search phase. Checkpoint hard. |
11
| Bulk mechanical edit | 25 plus 2 per file | 60s plus 10s per file | Scale with the work, not a flat cap. |
12
| Autonomous or unattended | 60 | 600s | Tighter than attended: no one will notice a loop. |
13
14
## Tuning from real runs
15
16
1. Log actual usage on every run, not just on failures.
17
2. Set the budget near the 90th percentile of successful runs, plus a little.
18
3. If more than about 5% of runs hit the ceiling, the budget is too tight or the task
19
   is underspecified. Find out which before raising it.
20
4. If no run has come near the ceiling in a month, lower it. You are not protected by
21
   a limit you never approach.
22
23
## What not to do
24
25
- Do not raise a budget because a run hit it. Find out why first. Nine times in ten it
26
  is a loop, and a bigger budget just makes a longer loop.
27
- Do not make budgets per-tool. Agents route around a per-tool cap by using a
28
  different tool. Cap the total.
29
- Do not exempt "just one more check." That is the loop talking.
30