GitHub Now Counts Draft Pull Requests Toward Open PR Limits

On October 8, 2026, GitHub expanded its pull request limit settings: they can now be configured to count draft PRs as well. The announcement in the GitHub Changelog is short, and the motive is stated plainly: maintainers see more and more low-quality contributions in their repositories and need better ways to handle them. The announcement gives no numbers, but the logic of the change is clear.

What exactly changed

Pull request limits let repository owners cap the number of PRs that can be open at the same time. Judging by the wording "you can now also include drafts," draft PRs were previously not counted toward these limits. For an author who wanted to get around the limit, that was a ready-made loophole: open placeholders as drafts and pile up as many as you like.

Now the hole can be closed, and only if a maintainer wants to. The setting is not forced on every project: each maintainer decides whether to count drafts the same way as regular PRs.

Where the noise comes from

The stream of weak contributions to open source has long been a problem in its own right. Some of these requests come from mass edits made for the sake of statistics or a "portfolio." Increasingly, they are generated by coding assistants and agents that can open a PR faster than a human can read its description. GitHub does not spell out the causes in the announcement, but the industry context is obvious: the cost of creating a PR has dropped almost to zero, while the cost of reviewing it has stayed the same and falls entirely on the maintainer.

In this scheme, a draft works as a buffer. An author or their script can keep dozens of placeholders open, and the maintainer still sees them in the list, gets notifications, and spends attention triaging them. Counting drafts toward the limit makes the rule fairer: an open request takes up a slot regardless of its status.

What is known about the parameters

• Publication date: October 8, 2026, GitHub Changelog section.
• Substance: draft pull requests can be included in the PR limit count.
• Type of setting: optional, controlled by maintainers.
• Stated goal: reduce the burden from low-quality contributions.
• Not disclosed in the announcement: specific thresholds, per-author counting rules, and how already-open drafts behave when the option is turned on.

Practical takeaways

Maintainers of popular repositories should check their current limit configuration and decide whether they need to count drafts. If a project uses drafts as a workspace for long-running features, a strict limit will also hit conscientious contributors. In that case, it makes sense to first write the rule down in CONTRIBUTING and explain how to work within the limit.

Contributors should close stale placeholders in advance and avoid keeping several parallel drafts open in someone else's repository. Teams that run agents to open PRs automatically need to build the limits into their logic: queuing, retries, and prioritization. Otherwise, the agent will hit the ceiling and silently lose its results.

The change is small and does not solve the quality problem: a limit restricts volume, not content. But as one layer of defense, alongside PR templates, required checks, and restrictions on who can submit, it works. It is best to check the exact counting mechanics against GitHub's documentation, since the announcement itself offers few details.