Qodo Developer plan: how do the 30 PRs/month limit work, and what happens when we exceed it?

For most teams starting with Qodo, the Developer plan is the fastest way to see how agentic code review fits into your workflow without committing to enterprise volume. The one thing you need to understand clearly is how the 30 PRs/month limit works: what counts as a PR, when usage is metered, and what happens when you go over that limit.

Quick Answer: On the Qodo Developer plan, your workspace includes review for up to 30 pull requests per calendar month. Every unique PR that Qodo pre-reviews (IDE and CLI are unlimited in this plan) is counted once toward that monthly total. If you exceed 30 PRs, Qodo simply stops running PR reviews for the rest of that month—your repos and data stay intact, and you can either upgrade for higher volume or wait until the next month when your quota resets.

Why This Matters

If you’re piloting Qodo in a real team—not a toy repo—you need predictable behavior when you hit limits. You don’t want surprise throttling in the middle of a critical release, and you don’t want to guess which actions “burn” your quota. Knowing exactly how the 30 PRs/month limit works lets you design a safe rollout: start with a subset of repos, keep AI review focused on the work that matters, and plan the moment you graduate from Developer to a higher-volume plan.

Key Benefits:

• Predictable usage: A simple, PR-based limit makes it easy to estimate whether the Developer plan fits your current throughput.
• Safe pilot scope: You can constrain Qodo to specific repos or teams so experimentation doesn’t accidentally consume your entire quota.
• Clean upgrade path: When you consistently exceed 30 PRs/month, it’s a clear signal to move to a plan that matches production-scale usage.

Core Concepts & Key Points

Concept	Definition	Why it's important
PR-based metering	Qodo Developer counts unique pull requests that receive an AI pre-review within a calendar month.	Makes it easy to map usage to your existing GitHub/GitLab/Bitbucket/Azure DevOps activity.
What counts as “1 PR”	A PR becomes billable when Qodo runs its agentic pre-review (issues, suggestions, tests, compliance checks) on that PR for the first time. Subsequent updates to the same PR do not count as additional PRs.	You can iterate, push more commits, and re-run checks on the same PR without worrying about extra quota.
Behavior after 30 PRs	Once you hit the 30 PRs/month limit, Qodo pauses new PR reviews for the remainder of the month. IDE and CLI review continue as configured, subject to plan rules.	Prevents surprise charges while keeping your workspace, rules, and history intact so you can upgrade or wait for reset.

How It Works (Step-by-Step)

Here’s how PR metering works on the Qodo Developer plan, end to end.

1. Connect your repositories

   • You connect your Git provider (e.g., GitHub, GitLab, Bitbucket, Azure DevOps) and select which repositories Qodo should monitor.
   • Qodo’s Context Engine indexes these repos so review agents can reason about multi-repo dependencies, shared modules, and organizational patterns.

2. Qodo starts pre-reviewing pull requests

   • Whenever a developer opens a pull request in a monitored repo, Qodo’s review agents can:
     • Scan the change for bugs, logic gaps, missing tests, risky changes, and cross-repo issues.
     • Run your living rules system (style, security, compliance, documentation standards).
     • Generate summaries, inline findings, suggested fixes, and test cases.
   • The first time Qodo performs this automated PR analysis for a given PR, that PR is counted as 1 PR against your 30 PRs/month quota.

3. Iterate on the same PR without extra cost

   • Developers can push more commits to the same PR, request re-analysis, and resolve issues using Qodo’s suggestions.
   • Qodo may re-run agentic workflows on the same PR multiple times as it evolves.
   • All of this still counts as one PR for metering purposes—as long as it’s the same PR ID in your Git system.

4. Monitoring your monthly usage

   • Inside Qodo, you’ll see how many PRs have been reviewed in the current month.
   • This gives you enough lead time to decide: stay within the Developer plan, restrict which repos are covered, or talk to us about moving to a higher-tier plan if you’re approaching the limit every month.

5. What happens when you hit 30 PRs

   • After the 30th PR has been pre-reviewed in a given calendar month:
     • Qodo stops running new PR reviews for additional pull requests.
     • Your existing PRs that were already analyzed keep their history and findings; you just won’t get fresh pre-reviews on new PRs until the quota resets or you upgrade.
   • Nothing is deleted: your workspace, repos, rules, and historical review data remain intact.

6. Reset at the start of the next month

   • At the beginning of a new calendar month, your PR counter resets to 0.
   • Qodo resumes pre-review for new PRs (up to 30) with your existing configuration, rules, and workflows.

7. Upgrading beyond 30 PRs/month

   • If you consistently hit or exceed 30 PRs/month, we typically see teams:
     • Expand Qodo beyond a single squad or pilot repo.
     • Turn on more agentic workflows (e.g., /compliance, /add_docs, cross-repo checks).
     • Move from “experiment” to “standard part of the SDLC.”
   • At that point, an upgraded plan gives you:
     • Higher (or unlimited) PR volume.
     • Extended governance features (enterprise SSO, compliance enforcement, air-gapped or single-tenant options).
     • Support for larger organizations handling thousands of PRs across many teams.

Note: Exact plan entitlements (IDE usage, CLI limits, deployment options) evolve over time. This article focuses specifically on how the 30 PRs/month behavior works; check the pricing page or talk to us directly for current plan details.

Common Mistakes to Avoid

• Turning Qodo on for all repos on day one:

  • If your org pushes hundreds of PRs per month, enabling Qodo across everything on the Developer plan will burn your 30-PR quota almost immediately.
  • How to avoid it: Start with one or two high-signal repos or a single team. Prove value on critical services first, then upgrade when you’re ready to roll out org-wide.

• Treating the quota as per-developer instead of per-workspace:

  • The 30 PRs/month limit applies to the entire Qodo workspace, not per user. Teams sometimes misread this and are surprised when a busy repo consumes the entire quota.
  • How to avoid it: Align your pilot scope to your expected team-level PR volume, not individual usage. If one service alone generates more than ~30 PRs/month, that’s already a signal you’ll outgrow the Developer plan quickly.

Real-World Example

A small platform team wants to test Qodo as a review layer before commit becomes the norm across the org. They:

1. Create a Qodo workspace on the Developer plan.
2. Connect only their core API repo, which averages 20–25 PRs/month.
3. Turn on Qodo’s agentic pre-review for that repo’s pull requests:
   • The review agents surface logic gaps, missing tests, and cross-repo breaking changes before human review.
   • Qodo’s Context Engine uses surrounding microservices and shared libraries (already indexed) to catch issues diff-only review would miss.
4. After two months, they realize:
   • Qodo has handled ~50 PRs across those months and significantly reduced “LGTM” misses.
   • Review time per PR dropped because reviewers start from a review-ready queue instead of a cold diff.
5. Now the front-end and data teams want the same workflow. But adding their repos would push them far beyond 30 PRs/month.
6. They use the sustained overage as a clear, data-backed signal to move up to a higher-volume plan that supports their real PR throughput across services.

Pro Tip: If you’re unsure whether your team will exceed 30 PRs/month, pull a quick report from your Git provider showing PR count for the last 2–3 months in the repos you plan to connect. If the number is consistently above 30, treat the Developer plan as a short-lived pilot and plan your upgrade path upfront.

Summary

The Qodo Developer plan is designed for focused pilots: up to 30 PRs/month per workspace, with each PR counted once when Qodo runs its first pre-review on that pull request. You can iterate freely on a PR without consuming additional quota, and when you hit the 30-PR limit, Qodo simply pauses new PR reviews until the next month or until you upgrade—no data loss, no surprise behavior.

If you find yourself consistently bumping into the 30 PR ceiling, that’s a healthy sign: Qodo has likely become a core review layer for your team, and it’s time to move to a plan that matches your actual code velocity.

Next Step

Get Started