> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Review rate limits
> How CodeRabbit counts review events, how per-developer allowances refill, what happens when a review is rate-limited, and how to spend fewer reviews.
CodeRabbit enforces review limits **per developer** over rolling time windows. This page explains what draws down that allowance, how it refills, what CodeRabbit does when it runs out, and the patterns that exhaust it fastest. For the limits themselves on each plan, see [Rate limits](/management/plans#rate-limits) on the Plans and pricing page.
See exactly which pull requests and developers spent your organization's reviews over the past 7 or 30 days, and which of the patterns below is costing you the most.
## What counts as a review event
CodeRabbit counts one review event every time it evaluates a pull request, and each event that runs within your included allowance draws one review from your plan's hourly limit. What surprises most teams is how many everyday actions produce a separate review event.
The table below assumes CodeRabbit's default [automatic review controls](/configuration/auto-review): automatic reviews enabled, an incremental review on every push, and a pause after five reviewed commits. These are defaults you can tune!
| Action | Included reviews used |
| ------------------------------------------------------------ | -------------------------- |
| Pull request opened | 1 |
| `commit` → `commit` → `commit` → `push` | 1 |
| `commit` → `push` → `commit` → `push` → `commit` → `push` | 3 |
| Editing a file in the GitHub web UI | 1 |
| GitHub's **Update branch** or **Resolve conflicts** button | 1 |
| `@coderabbitai review` or `@coderabbitai full review` | 1 each |
| Force-push, rebase, reopen, or draft marked ready for review | 1 |
| Push that was rate-limited | 0 |
| Review that continued with credits | 0, billed as usage instead |
Editing a file through the GitHub web UI is a commit and a push in one action, so it produces a review event just like a push from your terminal. Fixing three typos in the web editor across three files spends three reviews. GitHub's **Update branch** and **Resolve conflicts** buttons behave the same way: both write a new commit to your branch, so each one triggers another review event.
The rule underneath the table is that CodeRabbit reviews pushes, not commits. Three commits pushed together are one review event; the same three commits pushed one at a time are three. This is the single largest source of unexpected consumption, and it is entirely under your control.
With the defaults changed, the counts change with them. Setting [`auto_incremental_review`](/configuration/auto-review#auto_incremental_review) to `false` means only the opening push is reviewed automatically; lowering [`auto_pause_after_reviewed_commits`](/configuration/auto-review#auto_pause_after_reviewed_commits) pauses incremental reviews sooner on active branches; and label, title, or username filters can keep a pull request from being reviewed automatically at all. See [Automatic reviews](#automatic-reviews) for the controls worth reaching for first.
Some actions never draw down the allowance: commits you have not pushed, pushes to a branch with no open pull request, pull requests excluded by [automatic review controls](/configuration/auto-review), and chat messages, which have their own separate limit.
An eligible over-limit review that continues through the [usage-based add-on](/management/usage-based-addon) is billed as usage instead and does not draw down the included allowance. To check your own PR review limit without starting a new review, comment `@coderabbitai rate limit` or ask a clear question like `@coderabbitai reviews remaining?`.
## How the allowance refills
Each limit is a rolling allowance rather than a one-time quota: additional reviews become available as earlier reviews age out of the window instead of resetting all at once at the top of the hour. For example, Essentials includes 5 PR reviews per hour, which can be used at once; further reviews become available as the earliest ones age out of the rolling window.
For sustained high-volume PR review activity, review availability may adjust under the Fair Usage Limits Policy.
## Fair Usage Limits Policy
CodeRabbit's PR review limits are designed for modern development workflows where humans, coding agents, and automation may all request reviews. Each PR review uses compute. Fair usage limits keep review capacity reliable and economically sustainable for all customers.
During typical usage, reviews become available at the normal plan rate. When one developer identity reaches the 95th percentile or higher of recent CodeRabbit PR review usage, CodeRabbit uses that developer's recent PR review activity in a rolling window to gradually space out additional reviews. Depending on the activity, the applicable window can be the past 24 hours or the past 7 days.
Reducing or pausing review activity lets recent usage come down over time, which can restore faster review availability. The [Review Usage](/management/review-usage-dashboard) dashboard shows the adaptive limit CodeRabbit last observed for each developer and how it changed over the past 7 or 30 days.
The per-hour review availability shown below is the **refill rate**: the number of included reviews that become available per hour for a developer seat in an organization. The current refill rate depends on recent activity in the applicable rolling window.
| Recent PR review activity | Refill rate |
| -------------------------------- | ----------------------------------- |
| 0-29 reviews in the last 7 days | 5 reviews/hour |
| 30-39 reviews in the last 7 days | 4 reviews/hour |
| 40-49 reviews in the last 7 days | 3 reviews/hour |
| 50-59 reviews in the last 7 days | 2 reviews/hour |
| 60+ reviews in the last 7 days | 1 review/hour, one review at a time |
Team's standard refill rate is capped at 8 reviews per hour. Grandfathered Team organizations and Advanced organizations can receive up to 10.
| Recent PR review activity | Refill rate |
| -------------------------------- | ----------------------------------- |
| 0-29 reviews in the last 7 days | 10 reviews/hour |
| 30-39 reviews in the last 7 days | 8 reviews/hour |
| 40-49 reviews in the last 7 days | 6 reviews/hour |
| 50-59 reviews in the last 7 days | 5 reviews/hour |
| 60-69 reviews in the last 7 days | 4 reviews/hour |
| 70-79 reviews in the last 7 days | 3 reviews/hour |
| 80-89 reviews in the last 7 days | 2 reviews/hour |
| 90+ reviews in the last 7 days | 1 review/hour, one review at a time |
Enterprise developers do not have an adaptive limit.
## When a review is rate-limited
When a push is rate-limited, CodeRabbit posts a rate-limit comment on the pull request and a passing check titled **"Review rate limited"** — the check passes by design so it never blocks merging on protected branches. The comment is the authoritative signal that no review ran. A previously approved PR keeps its approval.
After an accepted review, CodeRabbit can show the plan's rolling-hour capacity and the number of included reviews that remain. When adaptive limits apply, CodeRabbit can show the number of reviews currently available and the applied hourly refill rate.
When the included allowance is exhausted, CodeRabbit can show the number of included reviews used. When complete adaptive-limit data is available, the guidance can also show the completed included-review count, the applicable 24-hour or 7-day window, and the applied hourly refill rate. If adaptive activity data is incomplete, the guidance shows only the known exhausted included-review count without inferring a window or refill rate.
CodeRabbit CLI and IDE Extension local-review guidance includes the same concrete rate-limit criteria shown in PR comments.
Comment `@coderabbitai rate limit` to see the criteria for your remaining capacity, then `@coderabbitai review` to trigger a review once capacity is restored.
A blocked push does not consume a review or delay when your next review becomes available. Capacity is limited by earlier reviews in the rolling window, not by the current push. When no PR reviews are available, CodeRabbit pauses new reviews until more reviews become available or eligible over-limit reviews continue through the usage-based add-on.
### How to continue with credits
If your team is actively using AI pipelines and expects sustained high-volume review activity, buy on-demand credits and enable the [usage-based add-on](/management/usage-based-addon#enable-the-add-on). Eligible over-limit PR reviews can then continue without waiting for the next included review to become available. A valid payment method is required before activation.
## Common anti-patterns
Four anti-patterns account for most unexpected rate limiting. The [Review Usage](/management/review-usage-dashboard) dashboard shows which of them applies to your organization.
### Superseded reviews
CodeRabbit reviews the head of the branch. When a new push lands while a review is still running, that review is superseded and its result never reaches the pull request — but the review event has already been counted and the allowance has already been spent.
A review takes longer than five minutes on most projects. Pushing inside that window is therefore not a faster review; it is a review discarded and paid for. A `commit-push-commit-push-commit-push` sequence over ten minutes spends three reviews and produces feedback from one.
Review Usage marks these clusters in its **Since previous** column. When a pull request shows three or more events with five minutes or less between each, the dashboard flags the cluster and notes that a single review on the final push could have replaced them.
The dashboard detects these clusters from timing alone. It does not compare the commits, so it cannot tell a genuine sequence of distinct changes from the same work pushed repeatedly. Treat the flag as a prompt to look, not a verdict.
To spend one review instead of several:
* Batch commits locally and push once when the branch is ready for feedback. Five commits pushed one by one trigger five incremental reviews, spending an entire hourly Essentials allowance in a few minutes.
* Set [`reviews.auto_review.auto_pause_after_reviewed_commits`](/configuration/auto-review#auto_pause_after_reviewed_commits) to `1` or `2` so CodeRabbit pauses automatic incremental reviews on active branches, then request a review with `@coderabbitai review` when you want one.
### Reviewing work-in-progress branches
A branch under active development draws a review on every push while the authors are still mid-change: the code is in transition, the feedback describes a state that no longer exists by the time anyone opens it, and often nobody opens it at all. The allowance is spent on reviews that were never read, and the review that mattered — the one on the finished branch — is the one that gets rate-limited.
The signal is a pull request with a long run of review events and almost no resolved review comments. Review Usage shows the events; the pull request itself shows whether anyone engaged with them.
To hold reviews back until someone is ready to read one:
* Open the pull request as a draft while you work. CodeRabbit skips draft PRs unless [`drafts`](/configuration/auto-review#drafts) is `true`, and marking the PR ready for review triggers the first review.
* Comment [`@coderabbitai pause`](/guides/commands#pause-and-resume-automatic-code-reviews) on a pull request that is already open, then `@coderabbitai resume` or `@coderabbitai review` when the branch is ready for feedback. For a branch that will not be read for a while, [`@coderabbitai ignore`](/guides/commands#disable-automatic-code-reviews) in the pull request description stops automatic reviews until you remove the line.
* Mark in-progress branches with a title keyword listed in [`ignore_title_keywords`](/configuration/auto-review#ignore_title_keywords), and drop the keyword when the PR is ready.
### One identity for every pull request
Review limits apply per developer identity, not per organization. Each developer gets their own hourly allowance and their own adaptive limit, and one developer's activity never reduces the capacity available to the rest of the team.
This becomes a trap when automation opens the pull requests. If a CI bot, a shared service account, or a single coding-agent account authors every pull request in the organization, then every review in the organization lands on that one identity. A team of twenty can push a single identity into the top activity bucket within days — 90 or more reviews in seven days on Team, 60 or more on Essentials, where the refill rate falls to one review per hour — while nineteen human seats sit at their full allowance, unused.
Team usage in Review Usage makes this visible immediately: **Users affected** reads `1 of 1` or `1 of 20`, and one row in **Review Usage by User** holds nearly all of the review events and rate-limit impact.
Adding seats does not help here. Capacity follows the identity that opens the pull request, so an organization whose reviews all run under one account has the review capacity of one developer regardless of how many seats it has bought.
If your pipeline is agentic or bot-driven, either attribute pull requests to the developer the work belongs to, so review capacity spreads across your seats the way it is meant to, or enable the [usage-based add-on](/management/usage-based-addon) so high-volume automation continues past the included limit on a billing path built for it.
### Automatic reviews
Reduce unnecessary automatic reviews so the allowance goes to branches that need feedback:
* Use [label-based opt-in](/configuration/auto-review#labels) so CodeRabbit reviews only PRs marked ready for review.
* Use [title-based exclusions](/configuration/auto-review#ignore_title_keywords) for WIP, generated, or automation-heavy PRs.
* Turn off automatic reviews for noisy repositories and request reviews manually when the PR is ready.
## What's next
See which pull requests and developers spent your organization's reviews over the past 7 or 30 days
Let eligible over-limit reviews continue on a pay-as-you-go path instead of waiting for capacity
Pause incremental reviews, opt in by label, and exclude work-in-progress branches so reviews run when you want them