PR-Agent, one of the first open-source AI pull request reviewers, is now community-owned. Its README says Qodo donated the project to the open-source community, that it lives in the PR-Agent GitHub organization, and that it is "in the process of being donated to an open-source foundation". The repository is MIT licensed, has about 14,500 stars, and gained 279 in a day, which put it on GitHub's weekly trending list.
If you want a self-hosted AI reviewer that works with the model you choose, it is worth a look. It also has a few details that matter: who maintains it, how it differs from Qodo's product, and one tool that is turned off for a security reason.
TL;DR: questions people ask first
| Question | Answer from the README |
|---|---|
| What does it do? | Describes, reviews, improves and answers questions about pull requests |
| How fast and costly? | Each tool uses a single LLM call, about 30 seconds |
| License | MIT |
| Stars | About 14,500 |
| Where does it run? | GitHub Action, CLI, Docker, self-hosted, webhooks |
| Git hosts | GitHub, GitLab, Bitbucket, Azure DevOps, Gitea |
| Models | OpenAI, Claude, Gemini, DeepSeek, Mistral, and anything via LiteLLM |
| Who owns it? | The community, after Qodo's donation |
| Is it Qodo's free tier? | No |
| Known gap | /help_docs disabled since v0.36.1 over a credential-exposure issue |
What changed: from Qodo project to community project
The README's "Big News" section is the reason for the renewed attention. It says that after years of building the tool alongside the community, Qodo has donated PR-Agent to the open-source community. The project now lives in the PR-Agent GitHub organization, is "fully community-owned" and is open to contributions and more maintainers. Documentation moved to docs.pr-agent.ai.
It also draws a line between this project and Qodo's commercial offering. According to the README, the hosted Qodo Merge, which was the enterprise version of PR-Agent, has been rebranded and has evolved into Qodo 2.0, "a full AI code review platform". The repository states that it is not Qodo's free tier for open-source projects, and it describes itself as a community-maintained legacy project of Qodo. If you want Qodo's hosted features, that is a separate product with its own terms.
The project now has its first external maintainer, Naor (@naorpeled in the README), and a foundation donation is in progress. We could not verify which foundation or the timeline.
One practical migration note from the README: releases 0.34.2 and later are published to Docker Hub under pragent/pr-agent. Older releases up to v0.31 stay in the legacy codiumai/pr-agent namespace as a frozen archive, with no new images. If you pinned an image or a docker:// reference, update it.
Two branching lines merging with a green dot, representing an AI reviewer checking a pull request before merge
How to set it up
The README recommends the GitHub Action. Add a workflow file that runs on opened and updated pull requests, with your model key and the repository token as secrets.
name: PR Agent
on:
pull_request:
types: [opened, synchronize]
jobs:
pr_agent_job:
runs-on: ubuntu-latest
steps:
- name: PR Agent action step
uses: the-pr-agent/pr-agent@main
env:
OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
For local use, install the package and point it at a pull request.
pip install "pr-agent[github]"
export OPENAI_KEY=your_key_here
pr-agent --pr_url https://github.com/owner/repo/pull/123 review
Provider SDKs are optional extras, and pr-agent[all] installs every integration. GitLab, Bitbucket and Azure DevOps each have their own setup guides in the documentation. Pinning @main follows the latest code, so for stable builds pin a release tag or commit and review changes before updating.
The tools you get
PR-Agent tools run as comments on a pull request or from the CLI. The README lists /describe to write a summary, /review to produce a review, /improve to suggest code changes, and /ask for free-text questions about the change. There is also /similar_issue for finding related issues. The README says each tool uses a single LLM call and a "PR Compression" strategy to handle both small and large pull requests, and that behavior is customizable through JSON-based prompting and configuration files, including a .pr_agent.toml in the repository.
Compared with agent-style reviewers that explore a codebase over many steps, this design is deliberately lightweight: one call, one result. That makes it cheap and fast, and it also limits depth. A reviewer that sees only the diff and a compressed context can miss problems that depend on code elsewhere.
Data privacy and keys
For self-hosted use, the README says that if you host PR-Agent with your own OpenAI key, your data handling is between you and OpenAI under that provider's API data policy. The same logic applies to any other provider you choose: your diffs, and any context the tool gathers, go to that model's API. Using a local model through Ollama keeps them on your machine. If your code is sensitive, decide that before you install.
The disabled tool and the credential issue
The README carries a warning: /help_docs has been temporarily disabled since v0.36.1, pending a fix for a credential-exposure issue tracked as #2445. We did not open the issue or the code, so we cannot say how the exposure happens or who is affected. Until it is resolved, do not enable related features, and keep tokens narrowly scoped. This is general advice for any CI tool that reads pull requests: a GitHub Action that runs on pull requests from forks can be handed untrusted text, so set repository permissions to the minimum and avoid exposing secrets to fork builds.
A four-week rollout plan
The README gives installation steps but not an adoption plan, so here is one that fits the tool's design. The official documentation site holds the configuration reference.
Week 1: observe only. Install the Action on one repository and run /describe and /review on every pull request. Do not require anyone to act on the comments. Count how many comments are correct, wrong, or trivial.
Week 2: tune the prompts. Use the repository-level configuration file to remove categories that produce noise, such as style comments your linter already covers. The README says review categories and behavior can be customized through configuration, so use that before you judge the tool.
Week 3: add /improve. Code suggestions carry more risk than a summary, because someone may accept them without reading. Ask reviewers to apply suggestions by hand for now.
Week 4: compare costs and decide. Check your model bill for the month and the time reviewers saved. If most comments were noise, change the model before you abandon the tool, because quality varies a lot by model.
Keep a short log of misses, meaning bugs a human found that the tool did not. That log is the best evidence of where a single-call reviewer falls short in your codebase.
Where single-call reviewers fall short
A tool that sends the diff and some compressed context to a model once will do well on what a diff shows: missing null checks, unclear names, obvious logic slips, missing tests. It will do worse when a bug depends on code outside the diff, such as a changed function that other modules call in a way the change breaks. Review agents that search the repository can catch more of those, at higher cost and with more complexity. Neither approach replaces a person who knows the system, and the results from Postgres's delayed release over AI-found bugs show that AI-assisted review can surface real issues while also adding work.
How it compares with other review options
The category is busy. A few explainx.ai posts cover neighbors:
- QuickReview is a self-hosted reviewer with a many-lens design and vendor claims we checked.
- Alibaba's Open Code Review ships a CLI and a benchmark.
- code-review-graph tries to reduce tokens by sending only relevant graph context.
- Hosted agents, such as Codex's auto-review, review inside the vendor's product.
PR-Agent's pitch is breadth and control: many Git hosts, any model, and an MIT license. Its trade-off is that depth depends on prompts and the model you attach, and project support now rests on community maintainers.
What to ask before adopting it
- Who reviews the reviewer? Treat output as suggestions. Our post on how Claude Code's team runs AI review with risk tiers is a good model for keeping humans in charge of what merges.
- Which model and what cost? One call per tool is cheap, but large pull requests and frequent updates add up. Set model and token limits in configuration.
- Which repositories? Start with a low-risk repository and compare its comments with human review for a few weeks.
- Who maintains it in a year? A community project with a pending foundation move carries more uncertainty than a funded product. Watch the release cadence.
- What can the workflow read? Limit the token's permissions, and do not let it run with secrets on fork pull requests.
What we did not test
We read the README and repository page. We did not install or run PR-Agent, check the issue, or measure review quality. Star counts are as shown on November 4, 2026.
Related reading
- QuickReview: self-hosted AI code reviewer, claimed vs verified
- Alibaba Open Code Review CLI and benchmark
- code-review-graph: token-efficient AI code review
- Codex auto-review: free, fewer approvals
- Claude Code team code review process and risk tiers
- Postgres 19 delayed by AI code review bugs and reverted features
Details are accurate as of November 4, 2026. Check the repository for current releases and security notes.