Maintainers face a 3.6x increase in PR volume, often fueled by low-quality AI noise. These limits shift the prioritization burden to contributors, reducing burnout and helping high-quality work stand out in crowded queues.
More people are contributing to open source than ever, most of them trying to help. The challenge is keeping up with the volume. Creating a pull request has never been easier. Reviewing one still takes a human about as long as it ever did. When great contributions and low-quality noise land in the same queue, the ones that deserve attention are harder to find.
That’s why we’ve introduced pull request limits. It takes on the problem we hear most: too many incoming pull requests, too much low-quality noise, and too few ways to manage the flow.
A pull request limit sets the maximum number of pull requests a user without write access can have open at once in your repository. Hit the limit, and you must close or merge one before opening another. Pull requests opened by Copilot or another AI agent will counts toward your limit. Trusted contributors can be placed on a bypass list, where they are exempted from limits, but don’t gain full contributor access. Draft pull requests will not count towards your limit.
GitHub already has interaction limits, but those are temporary cooldowns. These new pull request limits are persistent and configurable—giving maintainers the control they told us they were missing.
A cap also changes how contributors behave. When anyone can open a pull request in seconds, a polished change and a rough draft look the same in the queue. But when only a few pull requests can be open at once, a contributor must be selective and prioritize which contributions they want to be reviewed. That first judgment call happens before the pull request reaches you, and a smaller pool makes good work easier to spot.
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. Going forward we expect it to help us manage our backlog and ensure the things people are working on are the things we need.
Nicholas Tindle, AutoGPT
This feature is great. We’ve had problems on Homebrew for a while with enthusiastic users submitting many pull requests that need near identical review. AI further accelerated it. 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.
Mike McQuaid, Homebrew
At OpenClaw we get a huge volume of pull requests from the community and had to build our own bots for fighting spam. We are super glad GitHub has been able to develop out-of-the-box solutions for maintainers now to manage this volume.
Vincent Koc, OpenClaw
These limits are especially crucial right now because of a change in the ecosystem. In January 2023, developers merged about 25 million pull requests a month across GitHub. Today that number tops 90 million—a roughly 3.6x increase. More people are building in the open than at any point in GitHub’s history.
Most contributions come in good faith, and even good-faith work can pile up faster than one volunteer can answer. In February, we wrote that open source was hitting its own Eternal September. A pull request limit gives maintainers some of that attention back, without closing the door on the next contributor.
Pull request limits are just the first step. The same feedback is pointed straight at what comes after: more flexible, more granular control over how contributions flow in.
Archiving pull requests (shipping soon): Repository admins will be able to archive pull requests, hiding low-quality or spammy pull requests out of the main pull request view. Archived pull requests stay accessible to admins, but can be filtered out of the default list. We chose archive over delete on purpose: some organizations can’t permanently delete pull requests for legal or compliance reasons, and many maintainers want to keep them for context.
Issue limits (in development): The controls you now have on pull requests will be applied to issues: per-repository caps on how many open issues a user without write access can have at once, with a bypass list, plus an option to restrict issue creation to collaborators.
Smarter bypass signals (up next): The goal is less manual trust management. Instead of curating a bypass list by hand, you could let contributors clear a limit automatically based on real signals: a previously merged pull request in the repo, account age, or organization membership. That frees maintainers from curating lists by hand and gives them more time to focus on the work itself.
Cross-repository controls (exploring): A per-repository cap helps with repeated activity in one project, but it does nothing when someone opens pull requests across hundreds of repositories at once. We’re exploring ways to catch contributors who spray pull requests across multiple repositories, whether through trust signals, rate limiting, or other cross-repository controls.
Open source runs on the people who show up every day. To everyone who reviews pull requests late at night, mentors a first-time contributor, triages a backlog, files issues, or tells us where our tools fall short: thank you. You shaped this feature, and your input is critical in helping us decide what comes next. We’ll keep building with you.
Try the pull request limit in your repository settings, and tell us where it helps and where it doesn’t.
See you in the pull request queue. 🧡
The post How pull request limits are cutting down the noise appeared first on The GitHub Blog.
Engineers often get distracted by AI gimmicks. This article highlights that productivity gains come from understanding the core agent harness and granting it autonomy in safe, sandboxed environments, allowing for faster prototyping and fewer manual interruptions.
This app shifts AI from a simple chat interface to a comprehensive workspace. By integrating context-aware agents, interactive UI previews, and automated PR management, it streamlines the entire development lifecycle from initial coding to final merge.
Continue reading on the original blog to support the author
Read full articleUnderstanding the trade-off between pre-built AI harnesses and raw API access helps engineers optimize for development speed versus custom control. It clarifies how to manage LLM costs and token efficiency while leveraging existing SDLC integrations.
