GitHub PR Limits: Open Source Fights Back Against AI Contribution Spam

GitHub shipped a feature on June 17 allowing repository maintainers to cap open pull requests per contributor without write access, responding to a flood of AI-generated PRs that has overwhelmed open-source maintainers. The number of merged PRs on GitHub surged from 25 million to 90 million monthly since January 2023, driven by AI coding agents, leading to project closures like Jazzband and maintainers like cURL's Daniel Stenberg calling it 'AI DDoSing open source.' The feature limits concurrent PRs, excludes draft PRs, and allows bypass lists for trusted contributors.

GitHub shipped a quiet but significant change on June 17: repository maintainers can now cap the number of open pull requests any contributor without write access can hold at one time. On the surface, it looks like a minor settings toggle. In practice, it is GitHub’s first built-in defense against the AI-generated pull request flood that has been grinding down open source for the past year. The Problem Did Not Sneak Up on Anyone GitHub was processing about 25 million merged pull requests a month in January 2023. That number now tops 90 million — a 3.6x increase in three years, almost entirely driven by AI coding agents. Pull requests opened by AI tools specifically jumped from around 4 million in September 2025 to more than 17 million by March 2026 https://www.danilchenko.dev/posts/2026-04-11-github-ai-agents-pull-requests/ — a 325% increase in six months. Maintainers estimate that roughly 1 in 10 of those AI-generated PRs is worth reviewing. GitHub’s own product team called it an “Eternal September” https://www.infoworld.com/article/4127156/github-eyes-restrictions-on-pull-requests-to-rein-in-ai-based-code-deluge-on-maintainers.html — a reference to the 1993 moment when AOL connected to Usenet and flooded it with users who had no idea how communities worked. The analogy is apt. AI coding tools have made submitting a pull request trivially easy. Reviewing one is still hard, expensive, and human. The damage has been real. Jazzband https://jazzband.co/news/2026/03/14/sunsetting-jazzband , a Python cooperative that maintained 84 projects with over 150 million monthly downloads — including pip-tools and django-debug-toolbar — shut down in March 2026 after ten years. Its founder cited the AI PR flood as making the organization’s open membership model impossible to sustain. Ladybird, tldraw, and other projects stopped accepting external pull requests altogether. Daniel Stenberg, who created cURL, ended his project’s HackerOne bug bounty program in January https://thenewstack.io/curls-daniel-stenberg-ai-is-ddosing-open-source-and-fixing-its-bugs/ after AI-generated security reports consumed more maintainer time than they produced value. He called it “AI DDoSing open source.” What GitHub Shipped The feature https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/ lives in repository Settings. Maintainers set a maximum number of concurrent open pull requests per user without write access. A user who hits that cap must close or merge an existing PR before opening another one. Three details matter: AI agent PRs count. Pull requests opened by Copilot, Claude Code, Codex, Cursor, or any agent will count toward the limit. This is deliberate. Draft PRs do not count. Drafts are excluded — which encourages contributors to open a draft for discussion before committing to a full review cycle. Bypass lists exist. Trusted contributors can be added to a bypass list without granting them full write access. Regular contributors should not be penalized by limits set for bad actors. Maintainers who have turned it on are reporting a difference. Nicholas Tindle from AutoGPT said it directly: “It’s helped us want to review pull requests again. Knowing that someone hasn’t just opened 5–10 pull requests that are slop makes it much easier to want to look.” Mike McQuaid, who maintains Homebrew, put it plainly: “This allows us to still have outside contribution and maintainers contribute more while gating users to a level of pull requests we can cope with.” The Honest Assessment This feature caps quantity. It does not filter quality. A contributor with multiple accounts, or one who submits low-effort PRs at a slow drip, is not stopped by this. Neither is an agent that opens one carefully-timed PR and waits. What it solves, immediately, is the blast radius problem — the agent that opens twelve PRs in a single session, the user who fires off low-effort submissions across twenty projects simultaneously. Those are the cases that drove Jazzband offline and burned out cURL’s security team. For those scenarios, the limit is effective. GitHub has more coming: issue limits are in development, PR archiving ships soon, and smarter bypass signals are on the roadmap https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/ . None of those are live yet. Until quality detection lands, maintainers are working with a throttle, not a filter. What to Do Right Now If you maintain a project with active external contributions, enable the limit in your repository Settings today. A cap of two or three concurrent open PRs per user is a reasonable starting point for high-traffic repositories. Add your regular contributors to the bypass list before they hit the wall unexpectedly. Consider pairing it with required CI checks — projects like cURL run 200 automated jobs before a human ever looks at a PR, which raises the cost of submitting low-effort changes more effectively than any number cap alone. GitHub finally built something native. It does not fix everything. But it gives maintainers a lever they did not have last week, and right now, that is not nothing.