automaintainer/ docs
Dashboard →

Throttling open PRs

When a repo runs on a short interval, AM can open PRs faster than you review them — and sibling runs, blind to each other, sometimes propose overlapping work. AM has three layers that keep that in check: a cap on how many PRs pile up, and two dedup guards that reduce overlap among the ones that do open.

The open-PR cap

Each repo has a Max open PRs setting (repo settings → Scheduling). Once that many of AM's own open PRs (am/* branches) are awaiting review, the scheduler pauses opening new runs for that repo.

  • Default: 5. Sensible for most repos.
  • 0 = off — no cap; AM opens runs purely on the schedule.
  • Set it per repo: e.g. 5 on a small repo, 10 on a busy one, 0 on a repo you want to run unthrottled.

It auto-resumes: PR watching keeps verifying and draining the queue, so as your open PRs merge or close, spawning picks back up — you never have to toggle anything.

Max open PRs Effect
5 (default) Pause new runs once 5 AM PRs are open
10 Allow a deeper queue before pausing
0 No cap — schedule-driven only

Counting is AM-only: PRs from people or other tools don't count toward the cap, and the cap fails open — if AM can't reach the forge to count PRs, it proceeds rather than stalling your repo.

Reducing overlap (dedup)

The cap bounds how many PRs stack up; two further guards reduce overlap among them, so you don't get three PRs creating the same file:

  1. Claimed-files awareness (at spawn). Before agents start, AM injects the files already in flight in other open PRs as a "do not re-create these" constraint — so a new run steers toward different work.
  2. Collision guard (at publish). Just before opening a PR, AM checks whether any file this run adds is already created by another open PR. If so, it opens the PR as a draft with an overlaps #N note instead of a silently-conflicting PR — you decide which to keep or how to split.

A related check flags a mislabeled PR — e.g. a docs:-titled PR that also edits source code — with an advisory note, so each PR stays one concern.

When to change the cap

  • Lower it (or rely on the default) if reviews are your bottleneck — keeps the queue small and reviewable.
  • Raise it for a repo where you want more parallel exploration and can review in batches.
  • Turn it off (0) for a short-lived push where you want every scheduled slot to spawn, and you'll merge/close aggressively.