Reasonable Review Limits
Resolved 💬 8 comments Opened Dec 4, 2025 by richardgetz Closed Feb 8, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What feature would you like to see?
Codex reviews in GitHub went from insanely valuable to useless pretty quickly. Our team dove head first into codex usage. We now see "You have reached your Codex usage limits for code reviews." on most of our reviews. Would love to see some additional thought on how this works for teams. Could we pool reviews across all team members for when some are opening PRs at a faster rate? Automated reviews are extremely important in the era of automated code generation. Look forward to the thoughtful approach here.
Additional information
_No response_
8 Comments
If running in the cloud is the spend, how about self-hosted runner options?
Which ChatGPT plan are you using for your team members? Do you have a Team (aka Business) plan, or is each team member using individual consumer plans like Plus or Pro?
Our team is on a Business plan. I also personally have a Pro plan.
Yes, I agree that automated code reviews have become really important. The models have gotten so good at code reviews in such a short time. Personally, I no longer feel comfortable checking in code that hasn't gone through a codex review!
If your team makes heavy use of code reviews and members of your team are exceeding their base subscription usage limits, you have the option of purchasing additional credits for your Business plan. My understanding is that these additional credits comprise a pool that can be applied to any member of the team.
Here's a link to our pricing documentation, which is admittedly a bit anemic. We're working to improve this documentation so it is clearer about how usage limits work, how much usage individuals and teams can expect in a given week or month, how to stretch usage further, and how to purchase additional usage credits.
We're also continuing to work on lowering costs over time — for example, by making new models more efficient at reasoning tasks like code reviews. The "gpt-5.1-codex-max" model that we released just a few weeks ago is more efficient than its predecessors and therefore allows for more code reviews within a given token budget.
It's helpful for us to understand where our current pricing and usage models are creating undue friction for users. Please continue to post suggestions here. Some ideas may be impractical for us to implement from a business or technical perspective, but even those ideas are valuable to surface because they may spark other ideas.
Credits are nice in a pinch, but the regular cadence of purchasing credits instead of something that "just works" is a bit cumbersome. Have to raise cost per user to get there? I get that. Making us have to manage credits for our team when this is meant to decrease friction, not increase it, seems off. Are credits automatically shared across all team members? If they aren't, we can see the issue we run into on a case by case basis that doesn't scale across organizations well. If they are, pooling existing capacity across all team members, without needing to manage credits, would be extremely helpful as reviews generally ebb and flow across teams. Not looking for this to be solved in this thread, but wanted to clarify we see the friction on our side already. I can't imagine this is the end state even in the near term. For us it would result in rethinking the agentic tools and services we utilize. I appreciate your detail and following up, thanks!
Good feedback — thanks!
Depending on your team's needs and the size of your organization, you might want to consider moving from a Business plan to an Enterprise plan. The latter provides additional flexibility.
Same but Pro plan:
45-225 local messages or 10-60 cloud tasks every 5 hours-- https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan#h_d93a168dde
I really don't understand why these "cloud tasks" are so much more expensive and I was quite surprised that I hit a limit so fast. From my end I see a few thumbs up on prs and maybe 2 comments and next thing I know I've apparently hit my weekly limit. I was quite shocked.
<img width="1164" height="1221" alt="Image" src="https://github.com/user-attachments/assets/ba22799b-ad4a-41eb-9967-496bbccb52a6" />
<img width="1231" height="813" alt="Image" src="https://github.com/user-attachments/assets/a30177b9-bdcb-4698-b22d-10cefc9d5451" />
Maybe something isn't as efficient as it could be on the runner side if it is adding a lot to costs? I'd also be fine with self hosting a runner
There maybe should be a 5 hour limit on reviews too? Just so we aren't suddenly surprised and cut off for a week?
Another concrete data point from a team using Codex in a repo-native PR review loop.
When the GitHub review connector exhausts review quota, it posts the "You have reached your Codex usage limits for code reviews..." message as a PR review artifact/comment. That feedback is useful, but the current presentation creates automation noise:
Feature request: expose review-quota exhaustion as a first-class non-review status instead of a normal PR comment/review artifact.
Examples that would help:
Important nuance: this is not a request to weaken review limits. The ask is just to make the exhausted state less noisy and easier for humans and repo automation to classify correctly.