Qodo PR-Agent: the open-source reviewer, clearly separated

What PR-Agent is in 2026

PR-Agent is open-source software that connects a language model to pull request context and Git provider actions. It can describe a change, review it, suggest improvements, answer questions, update changelogs, and expose related tools through comment commands or a local CLI. The project emphasizes one model call per common tool, token-aware handling of large diffs, provider flexibility, and deployment options that let a team keep control of infrastructure and credentials.

Its relationship with Qodo changed. The project began under CodiumAI, later Qodo, and supplied the foundation for the hosted PR review product that became Qodo Merge. In 2026 Qodo donated PR-Agent to the open-source community. The repository moved to the The-PR-Agent organization, calls itself a community-maintained legacy project of Qodo, and says it is in the process of moving toward an open-source foundation. The repository also states that PR-Agent is not Qodo's free offering.

What the core commands do

PR-Agent organizes review tasks as explicit commands. This is useful operationally because a repository can run only the job it needs. A small documentation change might need a description and no broad review. A security-sensitive change might run review with tailored instructions. A reviewer can ask a line-specific question without rerunning every tool.

/describe
/review
/improve
/ask "Does this change preserve retry idempotency?"

The project's current feature table covers GitHub, GitLab, Bitbucket, Azure DevOps, and Gitea across the three main tools, CLI, app or webhook deployment, and several core context mechanisms. Some interactive features vary by provider. Check the table for the exact tool and host combination rather than treating platform support as one yes-or-no field.

PR-Agent also reads repository context files such as AGENTS.md in current releases, supports agent skills, can fetch ticket context on supported providers, and uses adaptive compression to fit large pull requests. Those features improve context while making configuration version-sensitive. Pin a tested release and read its release notes before adopting new defaults.

Install PR-Agent as a GitHub Action

The repository recommends GitHub Actions as the quickest path for a GitHub project. The workflow runs on pull request events, invokes the project action, and receives a model key plus the GitHub token through Actions secrets. Use an immutable release tag or commit in production after evaluating the current release. The repository README shows @main for a quick start; a moving branch is inappropriate for a required reviewer because behavior can change without a repository pull request.

name: PR Agent

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: the-pr-agent/pr-agent@PINNED_VERSION
        env:
          OPENAI_KEY: ${{ secrets.PR_AGENT_OPENAI_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Start with the narrowest documented permissions for the output you enable. A tool that posts comments needs pull request write access; a tool that applies code or labels may need more. The current project also documents a restricted mode intended to reduce GitHub permissions. Review the action source and permission matrix at the pinned version, protect the workflow file through CODEOWNERS, and avoid exposing model secrets to untrusted fork code.

Run PR-Agent locally from the CLI

The CLI is useful for evaluation, debugging, and environments where a hosted app is undesirable. The current quick start installs the pr-agent Python package, supplies a model-provider key, and passes a pull request URL plus a command. Local execution still needs Git provider credentials or environment configuration appropriate to the target repository.

python -m venv .venv
source .venv/bin/activate
pip install pr-agent

export OPENAI_KEY="replace-with-dedicated-secret"
pr-agent --pr_url https://github.com/owner/repository/pull/123 review

For repeatable use, pin the package version in a locked environment rather than installing the latest package on every run. Keep secrets outside shell history and source control. In CI, use the provider's encrypted secret store. In a shared runner, clear temporary configuration and verify that logs do not contain pull request content or model credentials. The project's self-hosted privacy statement makes clear that data handling follows the model provider relationship you configure.

Docker and webhook deployments become services, which adds a wider security surface. Terminate TLS, validate webhook signatures, isolate tenants, rate-limit triggers, rotate Git and model credentials, and record which repositories the service can access. A local command used by one maintainer and an organization-wide webhook bot are the same code with very different risk.

Choose and control the model

Model choice is one of PR-Agent's clearest advantages. The repository lists support for OpenAI, Anthropic, Google, DeepSeek, Mistral, and many additional routes through LiteLLM, including Azure OpenAI, AWS Bedrock, Vertex AI, Databricks, OpenRouter, Ollama, and others. This lets a team choose for quality, residency, contract, cost, or local operation instead of accepting one fixed model rail.

Flexibility creates a test matrix. Models differ in context size, instruction following, latency, price, structured output reliability, and familiarity with a language or framework. A model upgrade can change the number and severity of findings even when PR-Agent code and prompts stay fixed. Pin a model identifier where the provider supports it and treat model changes as reviewer changes.

The project says common tools use one model call and finish in roughly 30 seconds at low cost. Treat those numbers as project guidance rather than a service guarantee. Actual latency and spend depend on the configured model, provider, diff size, compression, network, retry behavior, and platform API. Capture tokens and cost per tool in your environment. A cheap review that produces no accepted findings is expensive; a costly review that catches a production incident can be cheap.

Configure PR-Agent without creating noise

PR-Agent exposes extensive configuration through TOML, environment variables, organization settings, prompts, and provider-specific deployment files. This is enough control to fit a team closely and enough control to create an unmaintainable reviewer. Begin with a small configuration file that names high-value concerns, excludes generated paths, and leaves optional scores or labels disabled until people ask for them.

• Scope paths. Exclude lockfiles, generated clients, vendored code, snapshots, and large fixtures where semantic review adds little.
• Write concrete instructions. Name a module, invariant, failure mode, and expected evidence instead of asking for general excellence.
• Limit automatic commands. Review and describe may be enough. Run improvement or write actions manually until value is proven.
• Separate author and reviewer output. Authors need actionable fixes; reviewers need risk, test, and requirement evidence.
• Cap comment volume. High-signal findings must remain visible among optional advice.
• Version the behavior. Record PR-Agent release, model identifier, prompt changes, and config changes together.

Use a gold set of historical pull requests to test configuration. Include true defects, false alarms, large diffs, generated files, security-sensitive changes, and changes with linked tickets. Run the same version and model against the set after any prompt or config update. Compare findings structurally rather than accepting a new output because it reads more smoothly.

Configuration also needs an ownership boundary. Keep repository-specific behavior beside the repository, organization defaults in the central deployment, and secrets in the provider store. Document precedence so a maintainer can explain why a setting took effect. Require review from both a code owner and the review-platform owner when a change expands permissions, enables writes, changes the model route, raises token limits, or weakens path exclusions. For routine prompt tuning, attach before-and-after results from the gold set. Delete settings that merely restate defaults, because they conceal which choices are intentional and make upstream default changes harder to evaluate. Export the effective configuration in diagnostics where the deployment supports it, and include a configuration hash in logs. When a finding changes unexpectedly, the team can then distinguish a model update, code update, prompt change, provider change, and repository override without reconstructing the service from memory. Keep a changelog entry for every production reviewer change with its rollout date, rollback command, and observed output delta. A bot that participates in branch policy deserves the same change discipline as CI infrastructure. Test configuration parsing in CI and reject unknown keys when the tooling permits, since silent typos create false confidence. Quarterly, remove obsolete overrides, rotate secrets, verify webhook signatures, and replay the gold set on the pinned release. This maintenance is part of the self-hosting cost.

Security and operational checklist

A pull request bot reads proprietary code, receives untrusted text from branches and comments, holds repository permissions, calls a model, and writes back into the review record. That is a meaningful trust boundary. Self-hosting gives control over the service and increases responsibility for everything around it. Threat-model the complete path before installing it organization-wide.

Separate reading from editing. A reviewer that can comment needs less authority than a fixer that can push commits. Run the review path first, inspect suggestions, and require a person or a separately permissioned workflow to apply changes. If write automation is enabled later, use protected branches, scoped tokens, fresh tests, and a review of the new diff. Model-generated code has the same trust status whether it arrives from an author agent or a reviewer agent.

The current repository notes that /help_docs was disabled after a credential-exposure issue while a fix was pending. That is useful evidence of why version and security-note review matter. Do not assume an optional tool is safe because it exists in an older tutorial. Read current release notes and the security policy at every upgrade.

Cost and the build-or-buy decision

PR-Agent costs no license fee. The operating bill includes inference, compute, network, secrets, logging, monitoring, upgrades, incident response, and engineering ownership. Model inference may dominate for a simple Action installation. Staff time dominates when the bot becomes organization-wide, needs several Git providers, carries custom prompts, or participates in required branch checks.

Build a monthly total with model tokens per command, review count, reruns, compute, storage, and maintenance hours. Include the human cost of false positives and the value of accepted findings. Compare that with Qodo's $0.012 shared credits, minimum $30 pack, and enterprise quote. The economically correct answer can change after a model reprices or an internal maintainer changes teams, so revisit it quarterly.

Questions people ask

Keep reading