Qodo Code Review Guide (2026)

Qodo is an AI code review platform for teams that want pull-request findings tied to repository context and written engineering rules. Its current product, Qodo 2, runs several review agents, ranks findings, and reports them inside the Git workflow.

The product’s naming history still affects current research. Older pages call the product Qodo Merge, and many developers still connect it with PR-Agent. Qodo now treats the hosted platform and the open-source project as separate paths, which affects features, ownership, pricing, and deployment.

This page is based on current vendor material and the public PR-Agent project. Qodo and PR-Agent are research-only tools for CodeWalkers, so no first-person use claim stands in for measured evidence.

Qodo at a Glance

checked July 28, 2026: Qodo's current code review documentation, changelog, and pricing page describe the product below. Plan details and provider coverage can move, so treat this table as a dated snapshot.

Area	Current Position	Buyer Check
Main product	Qodo 2 hosted platform	Trial on live PRs
Review method	Multiple review agents	Signal per comment
Context	Repo, history, rules	Cross-repo contracts
Open source	Separate PR-Agent project	Operator ownership
Hosted price	Pooled monthly credits	Actual PR volume
Enterprise	Single tenant or on-prem	Contract details

What Qodo Is Now

Qodo 2 reached general availability for agentic code review on February 4, 2026. The official changelog says the release added a multi-agent review process, full repository context, pull-request history, ranked findings, and structured steps for fixing them.

The platform sits in the review stage and also reaches earlier work through its IDE, CLI, and agent skills. For a tool landing page, the pull-request loop is the useful center: code enters a PR, Qodo gathers context, several agents inspect it, and the highest-ranked findings return to the author and reviewer.

Qodo 2.1 added a Rule System for GitHub deployments in February 2026. Qodo 2.2 added a portal configuration page, past-PR relevance data for some enterprise deployments, and guided provider setup. Qodo 2.3 added an organization-wide Findings page with 30-day reporting.

Those releases move Qodo beyond a comment bot. The buying question covers governance and reporting as much as bug detection. A small team may use only the PR findings, while a larger group may care about rule scope, bypassed findings, and trends across repositories.

Qodo and PR-Agent

Qodo's April 23 transition post says PR-Agent moved to the independent The-PR-Agent organization, returned to the Apache 2.0 license, and gained an external maintainer. Qodo also says PR-Agent has not kept pace with its commercial platform.

Hosted Qodo supplies the managed service, context layer, rule controls, reporting, and paid deployment choices. The open-source PR-Agent project supplies code a team can inspect, run, alter, and connect to its own model provider.

The two paths answer different operational needs. A hosted trial asks whether Qodo’s findings improve a team’s pull requests with tolerable noise and credit use. A PR-Agent trial also asks who owns the runtime, provider keys, webhook security, logs, updates, and failed jobs.

Question	Hosted Qodo	PR-Agent
Who runs it?	Qodo	Your team
How is it paid?	Credits or contract	Infra and model use
Who updates it?	Qodo	Your operator
Where are rules kept?	Qodo Rule System	Project configuration
Best first test?	14-day trial	Sandbox repository

Open source removes a software license fee from one line of the budget. It leaves the rest of the operating bill in place. A team without a named owner for the self-hosted service should test the managed product first.

How Qodo Reviews a Pull Request

Qodo describes specialized agents that inspect a pull request from different angles. They share repository context, PR history, and organization rules, then produce ranked findings that explain the issue, its effect, and a path to a fix.

The design matters when a diff looks harmless by itself. A renamed function may break callers elsewhere, a schema edit may violate another service’s contract, or a familiar pattern may have failed in a past PR. Repository and history context give the reviewer evidence beyond the touched lines.

Qodo’s claims about recall, precision, and low noise come from Qodo. A buyer should verify them against known bugs from its own repositories. The test set should include a finding that needs cross-file context, a false-positive trap, a missing test, and a rule with a clear pass condition.

Human judgment still owns the final review decision. A ranked comment can explain code behavior while missing product intent, release timing, or an external dependency. The human reviewer owns the merge and checks whether a suggested fix preserves the contract around the code.

How the Rule System Changes Review

Qodo's Rule System description says rules can come from written requirements, repository patterns, and prior pull-request history. The system can find duplicate or conflicting rules, scope them to repositories, and report rule use and violations.

Build a rule from the protected operation, required control, and evidence. A payment-webhook rule should name signature verification, its position before business-field parsing, and the test or code path that proves compliance. This structure gives Qodo a stable condition to evaluate on every run.

Start with rules human reviewers already enforce. Good first candidates include authentication boundaries, generated paths that should be skipped, migration ordering, and API compatibility. Each rule needs an owner who can resolve conflicts and remove it when the code or policy moves on.

Rule reporting can expose a process problem. If developers bypass the same valid finding every week, either the rule lacks authority or the delivery process makes compliance too costly. If the rule draws many rejected comments, narrow its scope and add contrasting examples.

Git Providers and Deployment

Qodo's provider setup index lists GitHub, GitLab, Bitbucket, and self-hosted editions. Its 2026 changelog adds guided Bitbucket Cloud and Azure DevOps setup, while enterprise material also names Gerrit.

Provider coverage needs a plan-level contract check. Azure DevOps arrived as an enterprise feature in Qodo 2.1, and some single-tenant or on-prem paths need vendor help. A logo on a provider list does not prove every Qodo 2 feature works in every cloud and self-hosted edition.

Ask the vendor to show the exact combination you will buy: provider, cloud edition, hosting model, authentication method, comment workflow, rule availability, and ticket connection. Run the same known-bug PR through that setup before contract approval.

Enterprise deployment adds choices such as single-tenant software, on-prem operation, customer-held model keys, SSO or SAML, and audit logs. These are current pricing-page claims, not a security assessment. Review the contract, trust material, data flow, retention terms, and failure behavior with your security team.

Security and Data Questions

Qodo's pricing page says customer code is used only to produce reviews and does not train models. Its public site also names strict retention, customer-held model keys, private deployments, and air-gapped enterprise use.

Turn each claim into a contract question. Ask which pull-request data is stored, how long findings and embeddings remain, where logs live, which model providers receive code, and whether customer-held keys alter retention. Include ticket text and repository history because context can reach beyond the diff.

Installation permissions deserve the same level of scrutiny. The app needs enough access to read code and post findings. Confirm who can add repositories, alter rules, raise an overage cap, view findings across teams, and change the provider connection.

Test the exit path before broad rollout. Remove one repository, revoke a provider token, and request deletion of stored context. Record what remains visible in the portal and how long the process takes; data control is easier to judge from that exercise than from a plan label.

Qodo Pricing

The Qodo pricing page lists a 14-day no-card trial, pooled credits at $0.012 each, and no permanent hosted free tier. Pro Team starts at $30, while Enterprise uses negotiated pricing.

Plan	Listed Price	Review Allowance	Main Fit
Trial	$0 for 14 days	Unlimited trial credits	Measured pilot
Pro Team	From $30/mo	2,500 pooled credits	Up to 30 users
Larger packs	$0.012 per credit	5,000 or 20,000	Higher PR volume
Enterprise	Custom	Contract terms	30+ users or private deployment

Qodo estimates 2,500 credits at about 18 reviews, 5,000 at about 36, and 20,000 at about 144. PR size and difficulty alter credit use. Unused credits expire each month, and reviews can enter paid overage until a team-set spending cap stops them.

The useful budget starts with your pull requests. Count monthly PRs, split them by size, and include repeat reviews after new pushes. The free trial should reveal the average and worst credit burn before you choose a pack.

Test Qodo's Rules and Credit Pool

Use the hub's four-week method for the shared sample and outcome labels. Add two Qodo-specific questions: does the Rule System change a known result, and how many pooled credits does each pull-request shape consume?

1. Rule delta: replay one known issue before and after adding a precise engineering rule.
2. Conflict test: add two intentionally overlapping rules and inspect Qodo's conflict handling.
3. Credit range: compare a small fix, a database edit, and a cross-repository contract change.
4. Overage stop: set a spending cap and confirm how a blocked review appears to authors.

Pair each rule with one compliant pull request and one known violation. If Qodo cannot distinguish them, adding broader rules will increase noise. Record first-run and rerun credits separately because a push can change the budget without changing the repository count.

Use the same trial for PR-Agent only when self-hosting is under serious review. Add operator time, model use, incident handling, and upgrade work to that comparison. A free repository does not create a free service.

Reading Qodo Findings Data

Qodo 2.3's Findings page gathers critical findings across repositories and reports 30-day trends. The release page says team leads can see whether findings were fixed or bypassed before merge.

A high finding count can mean risky code, an over-broad rule, or a new reviewer learning where to look. Read it beside pull-request volume, accepted comments, bypass reasons, and production defects. One chart cannot separate those causes on its own.

Track a few ratios the team can act on: valid findings per reviewed PR, accepted findings per rule, repeat findings after a rule was documented, and bypasses later linked to an incident. Split the data by repository because a generated client library should not set the baseline for a payment service.

Use the page to start a code-owner review of repeated findings. A recurring valid rule violation can point to missing automation or a weak template. Fixing that source removes future review work, while individual scoring can teach authors to hide or rush past findings.

Limits to Check Before Adoption

Qodo’s public pages describe an expanding platform, and some parts remain plan-bound or in beta. The Rule System began with GitHub deployment limits, while past-PR relevance and organization findings also launched with scope restrictions. Confirm availability in your chosen provider and hosting model.

Rules can spread a bad standard as quickly as a good one. Give each rule a named owner, a reason, examples, and a review date. Track accepted findings and bypasses, then remove rules that produce debate without code fixes.

Context gathering increases the data exposed to review. Security review should cover repository access, ticket data, model providers, retention, logs, network paths, customer-held keys, and the response when a provider is unavailable. Enterprise labels do not answer those questions by themselves.

Credit pricing also rewards smaller pull requests because size affects use. That can align with good review habits, yet it makes forecasting harder for teams with large generated diffs or broad migrations. Trial those cases instead of using the vendor’s average as your budget.

Qodo Code Review Verdict

Qodo earns a trial when repository context, centrally owned rules, provider breadth, or private deployment sits near the top of the buying list. Its pooled-credit model also fits teams that want to pay for review volume instead of every developer seat.

Qodo 2 suits teams that want review findings, centrally governed rules, and cross-repository reporting in one paid system. Its pooled credits make a measured small-team trial straightforward, but the Rule System and Findings data must change decisions to justify the bill. PR-Agent is an operations choice for teams with a named owner for its runtime and security.

FAQ

Is Qodo the same product as PR-Agent?

No. Qodo 2 is a commercial review platform with managed context, rules, analytics, and deployment choices, while PR-Agent is a separate Apache 2.0 project under The-PR-Agent organization. They share history, yet Qodo says the open-source project has not kept pace with the hosted platform.

Can a team self-host PR-Agent?

Yes, PR-Agent remains self-hostable and lets a team choose its model provider and infrastructure. That team owns secrets, updates, webhooks, usage costs, and incident response, so self-hosting makes sense when data control has an assigned operator. It is not a quick way to avoid a subscription.

Which Git providers work with Qodo?

Qodo publishes installation paths for GitHub, GitLab, Bitbucket, and Azure DevOps, with some deployment choices tied to plan and hosting model. Enterprise material also names Gerrit as an available provider. Confirm the exact provider, cloud or self-hosted edition, and required Qodo 2 features during the trial before signing a contract.

Does Qodo have a free plan?

Qodo’s pricing page lists a 14-day trial with unlimited credits and no card, followed by paid service. It says there is no permanent hosted free tier. Qualified open-source projects can apply for free access, while self-hosted PR-Agent still creates model, compute, maintenance, and monitoring costs.

How should a team test Qodo?

Use a small group of recent pull requests with known outcomes, then record valid bugs, missed bugs, repeated comments, credit use, and review time. Include generated files, a cross-repository contract, and one rule violation. A useful trial tests the failure cases your human reviewers already understand.