# Throttling open PRs

When a repo runs on a short [interval](/docs/scheduling), 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](/docs/scheduling).
- 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](/docs/pr-watcher) 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.

## Related

- [Scheduling](/docs/scheduling) · [Scheduler priority](/docs/scheduler-priority)
- [PR watcher](/docs/pr-watcher) · [Auto-merge](/docs/auto-merge)