# Pull request limits for CPython repo

**URL:** <https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564>\
**Category:** Core Development\
**Tags:** github, workflow\
**Created:** [October 20, 2026, 9:19am UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564 "2026-10-20T09:19:36Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\
**Post date:** [October 20, 2026, 9:19am UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/1 "2026-10-20T09:19:37Z")

</div>

We’ve set a [limit for the maximum number of PRs](https://github.blog/changelog/2026-06-17-limit-open-pull-requests-for-users-without-write-access/) you can open at [python/cpython](https://github.com/python/cpython) to 3, [including drafts](https://github.blog/changelog/2026-10-08-draft-pull-requests-count-toward-pull-request-limits/).

- This _does not_ affect members of the core or triage teams.

- If you have more than 3 PRs already open, they stay open, but you won’t be able to open another before dropping below the limit.

We have done this following several recent incidents of bulk PR creation in a short amount of time, and we’re struggling to handle them. For example:

- Today: 21 CPython [PRs](https://github.com/python/cpython/pulls/limadog9) opened in a single two-hour burst across about 19 unrelated stdlib areas, as part of 177 template-written [PRs](https://github.com/pulls?q=is%3Apr+author%3Alimadog9) sent to 13 repos in three weeks. Account [banned](https://github.com/atuinsh/atuin/pull/4470) by one project.

- October: 19 CPython [PRs](https://github.com/python/cpython/pulls/esadomer) opened plus 13 companion [issues](https://github.com/python/cpython/issues/esadomer) in a 20-minute burst across about 22 unrelated stdlib modules.

- October: 7 CPython [issues](https://github.com/python/cpython/issues/sricursion) opened, then then 7 matching [PRs](https://github.com/python/cpython/pulls/sricursion) within a single minute across unrelated modules, all 14 still untouched by a reviewer, from an account with 60 [PRs](https://github.com/pulls?q=is%3Apr+author%3Asricursion) spread over 18 repos.

- September: 17 CPython [PRs](https://github.com/python/cpython/pulls/v0ropaev) opened over three days across unrelated modules, as part of 225 [PRs](https://github.com/pulls?q=is%3Apr+author%3Av0ropaev) across ~50 repos.

- September: A user whose profile boasts a “117 PRs merged upstream” badge, opened 6 CPython [PRs](https://github.com/python/cpython/pulls/sankalpsthakur) in two hours against unrelated modules, as part of 487 [PRs](https://github.com/pulls?q=is%3Apr+author%3Asankalpsthakur) across ~40 repos, about half of those closed unmerged since August.

Yes, these do look LLM generated, and no, we don’t want to be the first humans to read that code.

(We also get mass issue reports, but unfortunately GitHub has no configurable limit for this.)

A reminder from our [AI policy](https://devguide.python.org/getting-started/ai-tools/):

> Authors must review the work done by AI tooling in detail to ensure it actually makes sense before proposing it as a PR or filing it as an issue.
> 
> We expect PR authors and those filing issues to be able to explain their proposed changes in their own words.

And:

> Maintainers may close issues and PRs that are not useful or productive, without explanation, regardless of whether AI tools were used or not.
> 
> If a contributor repeatedly opens unproductive issues or PRs, they may be blocked from contributing to the project because it is disruptive and disrespectful of the maintainers time.

---

<div class="post-metadata">

**Author:** ![pekkaklarck](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pekkaklarck/32/7211_2.png) [@pekkaklarck](https://discuss.python.org/u/pekkaklarck)\
**Post date:** [October 20, 2026, 10:51am UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/2 "2026-10-20T10:51:37Z")

</div>

This is certainly a good decision. That said, at least in this latest case all PRs don’t seem to be slop. I noticed that [one of them](https://github.com/python/cpython/pull/159855) fixes an issue [I had submitted](https://github.com/python/cpython/issues/131064), and based on a quick look on a mobile screen the fix looks good.

---

<div class="post-metadata">

**Author:** ![hugovk](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/hugovk/32/14505_2.png) [@hugovk](https://discuss.python.org/u/hugovk)\
**Post date:** [October 20, 2026, 11:12am UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/3 "2026-10-20T11:12:45Z")

</div>

Yeah, some PRs by these particular contributors have already been merged. But the main thing is we can’t deal with this volume.

And thanks for reviewing that PR, it helps.

(Let’s avoid the term slop as there’s no settled definition: for some it means all LLM-generated content, for others only low-quality content.)

---

<div class="post-metadata">

**Author:** ![deadlovelll](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/deadlovelll/32/36848_2.png) [@deadlovelll](https://discuss.python.org/u/deadlovelll)\
**Post date:** [October 20, 2026, 5:11pm UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/4 "2026-10-20T17:11:33Z")

</div>

What about regular contributors (outside the triage / core team)? With a cap of 3 they can’t send new fixes, or even backports

---

<div class="post-metadata">

**Author:** ![cjames23](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/cjames23/32/32376_2.png) [@cjames23](https://discuss.python.org/u/cjames23)\
**Post date:** [October 20, 2026, 7:14pm UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/5 "2026-10-20T19:14:55Z")

</div>

Is there a mechanism to short term override when doing backports that require conflict resolution? I have 3 open right now just with having to have done manual backports to handle conflicts which was done so that the Core team didn’t have to do it.

I do agree with the general direction though as I also get waves of PRs from LLMs that are hard to keep up with.

---

<div class="post-metadata">

**Author:** ![zware](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zware/32/58_2.png) [@zware](https://discuss.python.org/u/zware)\
**Post date:** [October 20, 2026, 7:49pm UTC](https://discuss.python.org/t/pull-request-limits-for-cpython-repo/109564/6 "2026-10-20T19:49:55Z")

</div>

Things are still new, so nothing is set in stone. I get the feeling that we’re going to be pretty free with the exclusion list for known contributors, so I wouldn’t worry about it too much. Do mention to your reviewer if you’re having issues with the limit.

There are also further tweaks to the system apparently [in development](https://github.blog/open-source/maintainers/how-pull-request-limits-are-cutting-down-the-noise/) at GitHub that should hopefully improve things as well.
