GitHub adds option to count draft pull requests toward repository PR limits

GitHub closes a draft pull request loophole

GitHub has shipped an optional repository setting that lets maintainers count draft pull requests toward a repository's pull request creation limits, according to a post on dev.to. The change targets a workaround that emerged after GitHub introduced pull request limits in June 2026, which dev.to reports were designed to reduce the volume of low-quality contributions.

The original limits did not apply to draft pull requests, and contributors quickly took advantage of that gap. As dev.to describes it, users opened large numbers of draft PRs to sidestep the restrictions. Although drafts are marked as work in progress and not ready for review, each one still generated notifications, triggered CI/CD pipeline runs, and added to review backlogs that maintainers had to triage.

The cost of unready drafts

The dev.to post frames the problem as more than a minor annoyance. CI/CD pipelines kept busy running checks on incomplete changes slow down feedback for legitimate work and inflate compute costs. Notification channels filled with items that could not be acted upon, forcing context switching on maintainers and delaying reviews of pull requests that were actually ready. For teams tracking delivery timelines, dev.to argues this noise translated directly into unpredictable schedules and diluted productivity.

Where the setting lives

The new control is an opt-in toggle rather than a default behavior. According to dev.to, maintainers can find it under repository settings, then Moderation, then Interaction Limits, then Pull request limits, where a toggle labelled "Count draft pull requests toward the limit" includes drafts in the count once enabled.

The optional design is deliberate. Many projects treat draft pull requests as a core part of their workflow, using them to gather early feedback while work is still in progress. Making the setting opt-in allows repositories that value that practice to keep it, while projects struggling with draft-based abuse can close the gap.

The feature is also exposed programmatically. Dev.to reports that the REST API endpoint for pull request creation caps, described as covering getting and patching the interaction limit for pull creation, includes an include_drafts boolean field. That field lets organisations apply consistent moderation policies across many repositories or wire the setting into existing governance and automation tooling.

Documentation lagged behind the feature

One wrinkle noted in the dev.to post: GitHub's documentation initially did not reflect the change. A community member, foma-agent, reportedly pointed out in the discussion that the official how-to guides continued to state that draft PRs do not count toward limits even after the setting appeared in the UI and in the API. Dev.to uses this as a reminder that platform documentation can trail feature releases, and that changelogs and community discussions are often the more current sources of truth when GitHub ships something new.

Why it matters

Pull request limits only matter at scale, and GitHub hosts millions of repositories, so even a narrow moderation setting like this one can affect contribution workflows across a large share of the open-source ecosystem. For maintainers of busy projects, the ability to count drafts closes a practical loophole: it removes the incentive to flood a repository with half-finished work that consumes CI minutes, generates notification spam, and buries reviewable changes.

The opt-in approach matters just as much as the feature itself. Draft PRs are a legitimate tool for early collaboration, and a blanket restriction would have punished teams that use them well. By making the behavior configurable per repository, GitHub leaves the policy decision to maintainers rather than imposing one workflow on everyone.

The API detail also broadens the impact beyond individual repositories. With the include_drafts field available programmatically, platform teams can standardise moderation settings across an organisation's repositories instead of toggling each one by hand. And the documentation lag the post highlights is its own lesson for anyone building on GitHub: verify behavior against the API and changelogs rather than assuming published guides are current.

It is worth noting this story comes from a single dev.to post, so specifics such as the June 2026 introduction date and the exact settings path reflect that source's account.