Wiring Up PR-Agent: The GitHub Action, the Model Key, and What It Costs in Tokens

The question this page answers is not what a PR agent is — that is a different article — but what happens between deciding you want PR-Agent on your repository and having it review a pull request. The gap between those two points is roughly one YAML file and one model key, and the parts people get wrong are the ones nobody documents: which installation path is current, what the default model costs per review, and why a single pull request can bill you ten times.

PR-Agent is the open-source tool CodiumAI built and later donated to the community. It now lives in its own GitHub organisation as a community-maintained legacy project of Qodo, MIT-licensed, at about 12.6k stars and 1.7k forks. It is free; the model calls it makes are not, and that is the only number in this setup that scales with your team.

The three installation paths, and which one you actually want

• The GitHub Action — a workflow file that runs code>the-pr-agent/pr-agent@main/code> on pull-request events. This is the recommended path and the one to start with: it needs no server, no webhook endpoint and no secret beyond the model key and the token GitHub already gives the action.

• The CLI — code>pip install pr-agent/code>, then code>pr-agent --pr_url <url> review/code>. Useful for trying a review against an existing PR before you wire anything, and for running the same engine from a laptop or a CI job that is not GitHub Actions.

• The container and the webhook — the Docker image, or the hosted webhook path for GitLab, Bitbucket, Azure DevOps and Gitea. Choose this when your repositories are not on GitHub, or when you need the review to run inside your own network boundary.

One caveat worth knowing before you copy a version number from a tutorial: the project's own documentation notes that the published code>pip/code> package currently trails the latest release, and points users at a GitHub-tag install if they need the newest code. That is a stable-state problem rather than an incident, but it means "the docs told me to pip install" and "I have the current release" are not the same sentence.

The model key is the actual decision

PR-Agent ships with model support that is deliberately open. The release notes list GPT-5.6 as the new default, with Gemini 3.6 and the Claude Opus 5 and Claude Sonnet 5 families supported, and DeepSeek and Mistral working through the same configuration block. Whichever you pick, you are supplying the key, and the review runs on your account.

That is the open-source trade in one sentence: you own the plumbing — keys, secrets, uptime, and the bill — in exchange for a per-review cost that has nothing to do with seats. A five-developer team on a per-seat hosted tool pays the same whether it merges ten pull requests a month or a thousand. On the token-priced route the number tracks what you actually review, which is better when you are busy and worse when you are not.

Two configuration choices move that number more than the model choice does:

• Run once per pull request, not once per push. Some tools default to reviewing every commit. A PR with ten pushes becomes ten review runs, ten model calls and ten times the bill, for nine reviews of code that no longer exists. Check this setting first, wherever you deploy.

• Cap the diff. Every one of these tools compresses the diff before it reaches the model, because a 2,000-line change does not fit in a prompt with room to think. PR-Agent's PR-compression strategy is the canonical implementation. A generated file, a lockfile or a vendored dependency can dominate the diff and the cost without containing anything a reviewer would read — exclude them.

What the commands do, and what each one costs

Once installed, the tool responds to slash commands on the pull request. Each is typically one model call, which is why responses arrive in tens of seconds and cost fractions of a cent:

• code>/describe/code> — writes the PR title, summary, walkthrough and labels from the diff alone.

• code>/review/code> — scans for bugs, security issues and maintainability problems, with severity labels and a score.

• code>/improve/code> — suggests committable code changes rather than commentary.

• code>/ask/code> — answers a question grounded in the diff, which is the command reviewers use most once they trust the tool.

• code>/update_changelog/code> — regenerates the changelog entry for the pull request.

The automatic behaviour most teams want is a single code>/review/code> on pull-request open. Everything else can be left to a comment, which keeps the cost predictable and keeps the agent out of the way of a reviewer who is already reading.

The failure modes nobody warns you about

• The action succeeds and posts nothing. Usually a permissions problem: the workflow token can read the diff but not write a comment. Check the action's log for a 403 on the comment call before you debug the model.

• It reviews the wrong diff. Fork pull requests run with a restricted token by default, and a workflow that has not been configured for them reviews an empty or partial diff and reports no findings. Silence is not a clean bill of health.

• The review is confident and wrong. Every model-backed reviewer will occasionally describe code that is not in the diff. The mitigation is structural rather than prompt-level: require the tool to cite the lines it is complaining about, and treat an uncited finding as a comment rather than a gate.

• Cost creeps. Not from a price change, but from scope: more repositories, more pushes per PR, larger diffs. Set a monthly budget on the key you issued for this purpose, and treat the alert as the signal that something changed in your workflow rather than in the model.

Where a router fits, and where it does not

A PR agent is one of the few AI workloads where swapping models mid-flight is genuinely useful: the cheap first pass catches formatting and obvious defects, and only the pull requests that survive it need an expensive model. That is exactly the shape OrcaRouter's OrcaCode Review product implements — a fast pass from a cheap frontier model, escalation to a stronger one when the screen finds something — and it is also something you can approximate yourself with PR-Agent by pointing its configuration at a gateway and routing by PR size.

What a router does not do is make the review correct. The value is in one key for every model you might compare, provider list price with no markup on top, and failover when a provider has a bad afternoon in the middle of your merge queue. Claude Opus 5.5 and Claude Sonnet 5.5, GPT-5.6 and the Gemini line are all callable through the same OpenAI-compatible endpoint, which makes "which model reviews our code" a configuration change rather than a procurement exercise.

What to do this week

• Install the GitHub Action on one repository, not all of them. One repository tells you the review quality and the per-PR cost; all of them tells you both things divided by an unmeasured denominator.

• Decide the model by measurement, not by reputation. Run code>/review/code> on your last twenty merged pull requests with two different models and compare the findings that a human agreed with. That number is the only benchmark that matters here.

• Set "once per pull request" before you set anything else, and set a budget on the key.

• Keep the human gate. A PR agent that blocks merges is a PR agent your team will find a way to bypass within a month.

Sourcing note: the PR-Agent origin, licence, star count, installation paths, command set, model defaults and the note that the pip package trails the latest release are from the project's own repository and documentation as read on 4 November 2026. The per-seat and per-credit pricing of hosted alternatives is from those vendors' published pages and is mentioned only for contrast. Grok and model names are used as configuration examples; the model identifiers on OrcaRouter's gateway were checked against the live model list on the same date. The failure modes are drawn from how these tools behave when the workflow token is under-scoped, not from a specific incident report.