GitHub Now Lets Maintainers Cap Pull Requests From Non-Collaborators

Opening a pull request used to cost something: reading the code, understanding the issue, writing a patch. AI coding assistants collapsed that cost close to zero, and the volume numbers show it. GitHub’s own data puts site-wide merged pull requests at 25 million per month in January 2023 and 90 million per month by March 2026, a 3.6x increase in a little over three years. On June 17, GitHub shipped a direct response: a setting that lets maintainers cap how many pull requests a non-collaborator can have open at once.

The number behind the decision

That 3.6x growth isn’t evenly distributed good news. Some of it is genuinely more people contributing to open source for the first time, which GitHub’s Q1 2026 data also shows accelerating worldwide. But maintainers have been describing a specific, separate phenomenon for over a year: a rising share of pull requests that are low-effort, sometimes visibly AI-generated without review, that don’t follow project conventions, and that get abandoned the moment a maintainer asks a clarifying question. GitHub’s own framing for the June change is explicit that this is a response to contribution volume outpacing maintainer capacity to review it, not just a celebration of growth.

This isn’t an isolated story. Curl paused its entire bug bounty program for a month in mid-2026 after its maintainer reported spending 10 to 15 hours a week triaging AI-generated vulnerability reports describing bugs that didn’t exist. That was a security-report queue; this is a code-contribution queue. Different pipeline, same underlying failure mode: a submission channel with near-zero cost for the submitter and real cost for the reviewer.

What the cap actually does

The mechanics are narrow and specific, which is worth walking through because “PR cap” undersells how targeted it is.

• It applies only to users without write access. Collaborators and maintainers aren’t capped by this setting; it’s aimed at the open, anonymous contribution surface.
• The cap is a number of simultaneously open PRs, set per repository by an admin. Once a non-collaborator hits it, they have to close or merge one of their open PRs before opening another.
• Draft PRs don’t count. A contributor can keep exploratory work open as a draft without burning their allotment on ready-for-review submissions.
• Trusted contributors can be exempted via a bypass list, without needing to hand them full write access. This is the part that keeps the feature from penalizing someone who reliably submits good PRs but hasn’t been formally added as a maintainer.

About two weeks later, GitHub extended the same underlying idea to issues, letting repository admins restrict who can open new issues at all rather than just capping volume. Together, the two settings give maintainers a lever they didn’t have before: control over contribution volume that’s separate from the all-or-nothing choice of opening a repo to everyone or locking it down to collaborators only.

What it doesn’t fix

A cap is a rate limit, not a filter. It bounds how many pull requests one non-collaborator account can occupy in the queue at a time; it says nothing about whether any individual PR is worth reviewing. A contributor who opens exactly one low-quality, AI-generated PR at a time, closes it when rejected, and opens another, never hits the cap and never gets slowed down by it. The setting solves the specific failure mode of one account flooding a queue with a dozen simultaneous low-effort PRs. It doesn’t solve the broader triage burden of each individual PR still needing a human to read it and decide.

That’s not a knock on the feature so much as an honest read of its scope. Maintainers who need actual quality screening, not just volume throttling, are still layering on third-party review bots, contribution guidelines enforced by CI checks, or, in curl’s case, temporarily shutting a channel entirely. The PR cap is a reasonable first move against a real and measurable problem. It’s not the last one any maintainer running a busy repository is going to need.

If your team maintains open source projects or accepts external contributions on internal repos, this is worth reviewing now rather than after a triage queue backs up: decide your cap number, build your trusted-contributor list before you need it, and treat the setting as one layer in a review process, not a replacement for one.