GitHub added a small, unglamorous setting on 6 August: organization owners can cap how many open pull requests a single user without write access is allowed to have at one time.
It reads like housekeeping. It arrives in the middle of the year that open-source maintainers spent drowning in machine-generated contributions, and in that context it is the most on-the-nose feature GitHub has shipped in a while.
What it does
The limit applies to users without write access — outside contributors, in other words, not your own team. A contributor who hits the cap has to close or merge an existing pull request before they can open a new one.
You set it once, in Organization Settings > Moderation Tools > Interaction Limits, and it applies consistently across the organization. GitHub's own framing is about applying a policy at scale and cutting the administrative overhead for maintainers looking after many repositories — which is the honest description of the problem it solves.
Why this matters now
Opening a pull request used to cost the contributor something: reading the codebase, understanding the conventions, writing the change. That cost is what kept volume in proportion to effort, and maintainer review capacity was calibrated to it.
Agents removed the cost on one side of that exchange and left it untouched on the other. A single person can now generate more plausible-looking pull requests in an afternoon than a maintainer can review in a week, and plausible is the operative word — a machine-written PR that is wrong takes longer to reject than an obviously bad one, because you have to read it properly to find out.
A cap does not judge quality, which is exactly why it works. It just puts a ceiling on how much of a maintainer's attention any one contributor can claim at once, without anybody having to make a call about intent.
Where it does not help
This is a moderation tool, not a quality filter, and it is worth being clear about its edges.
- It does not touch users with write access, so it does nothing about volume from inside your own team
- It caps concurrent open PRs, not total submissions — a contributor who closes and reopens can keep going
- It says nothing about whether a contribution is any good; a single excellent PR and a single junk one count the same
Picking a number
GitHub does not prescribe one, and the right cap depends on how your project actually receives contributions. A reasonable starting point is to look at your real contributors: how many open PRs does a genuinely engaged outside contributor typically have? Set the limit comfortably above that and you constrain the flood without inconveniencing the people you want.
Then watch. If the number never binds, it costs nothing. If it binds constantly, you have learned something about your inbound volume that is worth knowing.