CodeRabbit Fair Usage Policy: What It Means for Rate Limits and Your Bill

Everything below is taken from CodeRabbit's public pricing page and its rate-limit documentation as of October 2026. The bands have changed before and will change again — check the vendor docs before you plan around them.

The short version

CodeRabbit does not cap the total number of pull requests or repositories you can review. What it caps is the rate: each plan includes a per-developer hourly review allowance, and that allowance is "subject to Fair Usage Policy". In practice the fair usage policy is a second, slower-moving limit layered on top of the hourly one. The more PR reviews a single developer has used over the last seven days, the slower their hourly allowance refills.

If you have read our CodeRabbit pricing breakdown, you know the headline numbers: 5, 8, 10 and 12 PR reviews per developer per hour on Essentials, Team, Advanced and Enterprise. Those numbers are the ceiling. Fair usage decides how often you actually get to touch it.

How the fair usage bands work

CodeRabbit's rate-limit docs describe the policy as adaptive refill rates. The allowance is a rolling one rather than a fixed quota, and the seven-day activity count is kept separately for each developer in an organization. As that count climbs, the hourly refill rate steps down:

A few details in the docs matter more than the table. Automatic incremental reviews after new pushes count against the allowance, so one pull request with five rounds of fixes can use five reviews. The bands apply to PR reviews only; CodeRabbit says the policy does not change trial, CLI, IDE or self-hosted limits. And existing Enterprise agreements, including fixed 12-per-hour contracts, stay as they are unless renegotiated.

What happens when you hit the limit

When a push is rate limited, CodeRabbit posts a rate-limit comment on the pull request and adds a passing check titled "Review rate limited". You can then wait for capacity to come back and re-request a review with @coderabbitai review, or check where you stand with @coderabbitai rate limit.

That passing check is worth noticing. If your branch protection treats CodeRabbit as a gate, a rate-limited PR does not block the merge — it can go in without the review you think it had. Teams that rely on AI review as a required step should check how their merge rules read that status.

The other option is to pay. On Essentials, Team and Advanced, usage-based reviews let eligible over-limit reviews continue instead of stopping. The pricing page lists this at $0.25 per reviewed file, with Automatic, On demand or Off settings and a monthly spending cap. Paid continuations do not add to the seven-day counter, so they do not push you further down the bands. During a trial, eligible PR overages are free.

Who actually runs into this

For a developer opening two or three PRs a day, none of this is visible. Thirty reviews in a week on Essentials is six a day, incremental reviews included, and most humans stay under that. Three patterns push teams past it.

• Bursty PR days. Release crunches and cleanup sprints concentrate reviews into a few days. The seven-day counter remembers Monday's burst on Thursday, so a busy start to the week slows the end of it.
• AI coding agents. An agent that opens a dozen PRs a day under one developer's identity, each revised a few times, can reach 60 reviews in two days. After that, that developer is reviewed once an hour on Essentials. We cover the review side of this in code review for coding agents.
• Monorepos and large changes. Big PRs are where per-file overage pricing bites: a 40-file change reviewed past the limit is $10 at $0.25 a file. Docs also list a per-review file cap (150 files on Essentials, 300 on the higher plans). See AI code review for monorepos for the wider problem.

How to estimate whether you will hit it

You need one number per developer, not per team, because the counter is per developer.

1. Count reviews, not PRs. For each active author, take PRs opened in the last few weeks and multiply by the average number of pushes per PR. That is roughly the number of reviews CodeRabbit would run.
2. Take the busiest seven days for your heaviest author, not the monthly average. The bands react to peaks.
3. Compare against your plan's first band — 30, 40, 50 or 60 reviews. Anyone above it will see a slower refill; anyone near the floor will see one review an hour.
4. Price the overflow. Reviews you expect to run beyond the limit, times the average files per PR, times $0.25. That is the extra line on top of your seat bill.

Seats are a separate question. CodeRabbit bills for developers who create pull requests, and a seat is assigned automatically when someone opens a PR in an installed repository. Pushing commits to an existing PR does not assign one.

How PURA handles the same problem

PURA has no hourly throttle and no rolling per-developer band. Plans are flat monthly fees metered on reviews, with unlimited contributors, repos and teams: Starter at $39/month for 100 reviews, Scale at $99 for 400, and Pro at $199 for 1,000. Drafts, PRs that match no review agent, and budget-exhausted PRs do not count against the allowance. There is no overage either — when an allowance runs out, PURA pauses rather than adding a line to your invoice.

The honest trade-off is that inference is not bundled. PURA is BYOK: reviews run on your own OpenAI, Anthropic or Google keys, and you pay the provider directly with zero markup. That is why the other half of the product is hard budget caps — daily, weekly and monthly, per developer, repository, team and provider. When a cap is hit, reviews pause instead of overspending. So an agent-heavy week is limited by a number you set in advance, not by a refill rate you discover on the PR.

Neither model is free of limits. CodeRabbit limits how fast each developer can be reviewed; PURA limits how much you have chosen to spend. If your traffic is steady and your team is small, CodeRabbit's bands may never show up. If one engineer plus three agents produce most of your PRs, a per-developer rate limit is the wrong shape. For the wider field, see CodeRabbit alternatives.