AI Code Review in CI/CD Pipelines: Where to Run It (2026)

Direct answer

An AI code review can run in exactly three places, and the choice sets your cost, latency and security posture before you compare any vendor. As a Git-host app outside your CI (CodeRabbit, Greptile, Cursor Bugbot, Copilot, Anthropic Code Review) - lowest friction, your code leaves your network. As a step inside your pipeline (PR-Agent, Semgrep, SonarQube, Qodo) - runner control and an audit trail, paid for in minutes and maintenance. As a merge gate - the only one of the three that actually stops a bad merge. Verified 2026-10-18.

AI code review tools that work with existing CI pipelines

Direct answer: Only a minority genuinely run inside your pipeline. PR-Agent (MIT, pragent/pr-agent), Semgrep CE and SonarQube install as pipeline steps with no vendor cloud in the path. CodeRabbit, Greptile, Cursor Bugbot, Graphite and Anthropic Code Review are Git-host apps that sit beside your CI, not in it. GitHub Copilot code review is a hybrid: it uses Actions, but inference stays in GitHub’s cloud. Verified 2026-10-18.

The phrase “works with your existing CI” is doing two completely different jobs on vendor pages, and the difference is the whole article.

One meaning is “we post on the same pull request your CI is already checking.” That is co-existence, not integration. The reviewer is a GitHub App or GitLab bot reacting to a webhook. Your pipeline does not invoke it, cannot sequence it, and does not log it.

The other meaning is “we execute as a job in your pipeline.” Your runner clones the repo, your job calls the reviewer, your exit code decides what happens, and your CI logs retain the evidence.

Both are legitimate. They are not substitutes, and the second one is much rarer than the marketing implies.

Tool	Runs as a Git-host app	Runs as a CI step	Inference location	Self-hosted runner supported
PR-Agent	Yes (webhook server or GitHub App)	Yes - Action, Docker, CLI	Any endpoint you nominate via LiteLLM	Yes
Semgrep CE	No	Yes - semgrep CLI	Local engine, rules can be vendored	Yes
SonarQube	No	Yes - scanner step	Your server	Yes
Qodo Merge	Yes	Partly - .pr_agent.toml driven, portal-managed	Qodo cloud, or on-prem/VPC on Enterprise	Enterprise only
CodeRabbit	Yes	No (CLI exists, not a pipeline product)	CodeRabbit cloud, or self-hosted at 500+ seats	n/a
Greptile	Yes	No	Greptile cloud, or Enterprise self-host	n/a
Cursor Bugbot	Yes	No	Cursor cloud	n/a
Graphite	Yes	No	Graphite cloud	n/a
GitHub Copilot	Yes	Hybrid - consumes Actions minutes	GitHub cloud, always	Yes for the Actions job, not for inference
Claude Code Review	Yes, GitHub only	No	Anthropic	No

If you need code to stay inside your perimeter, the first three rows are the shortlist and everything else is a conversation with your security team. We go deeper on that in self-hosted AI code review tools.

The three places a review can run

	1. Git-host app	2. CI pipeline step	3. Merge gate
Setup effort	Minutes, OAuth install	A day of YAML plus ongoing ownership	Hours, on top of 1 or 2
Does your code leave your network	Yes, on every PR	Only if you point it at a cloud model	Inherits from 1 or 2
Runner minutes	None	Yours, $0.006/min Linux 2-core, zero on self-hosted runners	Same as 2, plus merge-queue re-runs
Audit trail	Vendor dashboard and PR comments	Your CI job logs and artifacts	Branch rule history
Can you sequence it after tests	No	Yes	Yes
Can it stop a merge	Only via a status check you also configure	Yes, by exit code	That is the whole point
Who has it	CodeRabbit, Greptile, Cursor Bugbot, Graphite, Copilot, Anthropic	PR-Agent, Semgrep CE, SonarQube, Qodo	CodeRabbit pre-merge checks, any required CI job

Place 1: a Git-host app outside your CI entirely

The vendor installs a GitHub App or GitLab integration, subscribes to pull request webhooks, clones or fetches the diff into its own infrastructure, runs inference there, and posts comments back through the API.

This is the default for every cloud reviewer and it is the correct default for most teams. Install time is minutes. There is no YAML. There is no runner cost. Vendors ship sensible behaviour out of the box: CodeRabbit’s reviews.auto_review.enabled defaults to true and auto_incremental_review defaults to true, so incremental re-reviews happen without you configuring anything (CodeRabbit config schema, verified 2026-10-18).

The costs are real and they are not minutes.

Your code leaves your network on every PR. Not the repository necessarily, but the diff, the surrounding context the tool retrieves, and whatever is embedded in it. That includes committed .env files, real records in test fixtures and debug logs, which is the risk people forget. Run a secrets scanner before you run anything else.

You get no pipeline-native audit trail. The evidence lives in the vendor’s dashboard and in PR comments. If your auditor wants “show me that every PR touching the payments service was reviewed in the last 12 months,” PR comments are a weak artifact and vendor dashboards have retention policies you do not control.

You cannot sequence it. You cannot say “only review after the tests pass, and skip the review entirely if the build is broken,” which is the single highest-value piece of cost control available, because reviewing a PR that does not compile is money spent on noise.

Place 2: a step inside your CI pipeline

Your runner checks out the code, your job invokes the reviewer, your logs capture the output.

You get three things the app model cannot give you. Runner control, which means a self-hosted runner inside your VPC and, per GitHub’s billing documentation, no Actions minute consumption at all. A real audit trail, because the job record, its inputs and its exit code live in the same system as every other compliance artifact you already produce. And sequencing, so the review runs after tests, once, on the final state of the diff.

You pay in minutes and in maintenance. The minutes are trivial: GitHub-hosted Linux 2-core x64 runners are $0.006 per minute, Linux arm64 $0.005, Windows 2-core $0.010 and macOS 3-core or 4-core $0.062 (GitHub billing docs, verified 2026-10-18). Included allowances are 2,000 minutes on Free, 3,000 on Pro and Team, and 50,000 on Enterprise Cloud, and public repositories on standard runners are free. A three-minute review job is $0.018. That is not the cost.

The maintenance is the cost. Someone owns the pinned action version, the API key rotation, the model fallback chain, the timeout behaviour when the provider is slow, and the merge_group trigger you will need the day you turn on a merge queue. Budget a day to build it and a few hours a quarter to keep it working.

Place 3: a merge gate

This is the only one that changes outcomes rather than adding information.

A gate means the reviewer’s verdict appears as a required status check on a protected branch or ruleset, or inside a merge queue, and a failing verdict prevents the merge. Everything else is advisory, and advisory findings get ignored at exactly the rate you would expect.

Most teams who believe they have a gate do not have one. Three reasons, all specific.

Reason one: the default review state does not block. A reviewer that posts a COMMENTED review has neither approved nor requested changes, and a branch rule requiring one approval is satisfied by a human approval regardless of what the bot said.

Reason two: a green check is not evidence a review happened. If the bot is rate limited, paused, or skipped the PR for a path filter, it can report success. CodeRabbit’s reviews.fail_commit_status defaults to false, which means on review errors it does not fail the status surface (CodeRabbit config schema, verified 2026-10-18). Set it to true if the check is required, or your gate is decorative.

Reason three: the merge queue runs a different event. Covered below, because it is the one that actually deadlocks repositories.

Best AI code review tools for CI/CD pipelines

Direct answer: For a pipeline you own, PR-Agent is the best answer - MIT since 23 April 2026, v0.48.0 on 2026-10-16, runs as Action, Docker, CLI or webhook across GitHub, GitLab, Bitbucket, Azure DevOps and Gitea, with any model via LiteLLM. Pair it with Semgrep CE or SonarQube for the deterministic layer. Everything else is an app that sits beside CI. Verified 2026-10-18.

Our criteria, stated so you can disagree with them: can it execute in a pipeline you control, can you point it at a model endpoint you choose, does it support more than one Git host, and is the exit-code behaviour documented. Review quality is not in this list, because no independent evaluation has measured these tools in a pipeline configuration at all.

PR-Agent wins on every criterion and it is free. Qodo relicensed it to MIT on 23 April 2026 and handed it to community governance under The-PR-Agent/pr-agent; the LICENSE file on main is MIT even though Qodo’s blog said Apache 2.0. Latest release is v0.48.0, 2026-10-16. Install options documented on docs.pr-agent.ai: GitHub Action, Docker, pip install "pr-agent[github]", a webhook server, and an AWS Lambda deployment. Extras cover github, gitlab, bitbucket, azure, codecommit, gitea and google.

One detail that matters for a pipeline and almost nobody mentions: PR-Agent has a [push_outputs] block that routes finished tool output to stdout, a JSONL file, a generic webhook, Slack or Telegram without calling any git-provider API. The docs state the record contains type, timestamp, payload and markdown, and that /review, /describe and /improve are the three tools that emit. That gives you a machine-readable review artifact you can archive, which is exactly what the app model cannot produce. The whole section is host-only by design: the docs say a repository cannot set these keys, so a PR cannot redirect review output to an attacker’s webhook.

Semgrep CE and SonarQube are the deterministic layer, and they are the layer that belongs on every push. Both reproduce run to run, which LLM reviewers do not, and auditors care about that property. The Semgrep caveat we keep repeating: the CE engine runs fully locally only if you vendor rules into a directory and pass --config /path/to/rules, because --config auto needs the network and semgrep ci requires semgrep login against the hosted platform. See Semgrep in GitHub Actions and SonarQube in GitHub Actions.

Qodo Merge is the closest thing to a configurable CI-native commercial reviewer. Its behaviour is driven by a .pr_agent.toml committed to the default branch, with organisation-level settings in the Qodo portal and repository settings taking precedence (Qodo docs, verified 2026-10-18). Flat team fee around $30 per month up to 30 users, credits at $0.012 pooled across the team with no rollover.

GitHub Copilot code review is the hybrid, and the hybrid is where the hidden cost lives. It moved to an agentic architecture in March 2026 and runs validation through Actions, including on self-hosted runners via Actions Runner Controller, but the review service itself stays in GitHub’s cloud. That is not self-hosted review. It is also, since 1 June 2026, the reason private-repo reviews consume Actions minutes.

How do code review bots connect to CI pipelines?

Direct answer: Four mechanisms. Webhook - the host pushes a pull_request event to the vendor; no CI involvement. Pipeline step - your runner invokes a CLI or container with the PR URL and a token. Status check API - the bot writes a commit status or check run your branch rules can require. Merge-queue event - GitHub fires merge_group, which is separate from pull_request and must be added as a trigger explicitly. Verified 2026-10-18.

Understanding which mechanism a tool uses tells you immediately what it can and cannot do.

Webhook-driven bots cannot be sequenced. The host fires the event the moment the PR opens. Your tests have not run. The bot reviews code that may not compile. Vendors mitigate this with draft-PR filters, which is why reviews.auto_review.drafts defaults to false in CodeRabbit and Cursor Bugbot exposes triggers.drafts in .cursor/config/bugbot.yaml.

Pipeline steps are sequenced by construction. This is the whole argument for place 2. A needs: [test] in GitHub Actions, a stage: ordering in GitLab, or a stage('Review') after stage('Test') in Jenkins means the review only runs on code that builds. If you are paying per review, that single line is the highest-ROI configuration change available to you.

The status-check API is how any of this becomes a gate. CodeRabbit’s schema documents reviews.commit_status, default true, as mirroring review progress “using legacy commit statuses for compatibility with required checks” - that string exists specifically so you can name it in a branch rule. A CI-step tool does the same thing for free: the job’s own check name is requirable.

The merge-queue event is the one that bites. GitHub’s documentation on managing a merge queue states plainly that the merge_group event is separate from the pull_request and push events, and that if your repository uses Actions for required checks “you need to update the workflows to include the merge_group event as an additional trigger. Otherwise, status checks will not be triggered when you add a pull request to a merge queue.” The consequence it spells out: “The merge will fail as the required status check will not be reported.”

So a review job triggered only on pull_request, marked as a required check, on a repository with a merge queue enabled, produces a permanently stuck queue. The fix is two lines:

on:
  pull_request:
  merge_group:

There is a second-order decision here. Running an expensive AI review inside the merge queue is usually wrong. The queue batches PRs and re-runs checks against the combined state, which means the same review can execute several times for one merge. Run the cheap deterministic checks on merge_group and keep the AI review on pull_request only. GitLab’s analogue is merge trains, which has the same sequencing property and the same cost implication. If this is new to you, start with what is a merge queue.

Real config: GitHub Actions, GitLab CI and Jenkins

We use PR-Agent for all three because it is the only reviewer in this market that is MIT licensed, runs in all three shapes, and documents the interface publicly. The first two are the vendor’s own published configurations. The third is not - PR-Agent publishes no Jenkins page, and we say so rather than passing off our own recipe as official.

GitHub Actions

This is PR-Agent’s documented workflow, with the sequencing and merge-queue corrections this article argues for:

name: AI review
on:
  pull_request:
    types: [opened, reopened, ready_for_review, synchronize]
  issue_comment:
  merge_group:

jobs:
  pr_agent_job:
    if: ${{ github.event.sender.type != 'Bot' }}
    runs-on: ubuntu-latest
    permissions:
      contents: read
      issues: write
      pull-requests: write
    steps:
      - name: PR Agent action step
        uses: the-pr-agent/pr-agent@main
        env:
          OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Three notes. Pin the version in production. @main is what the docs show, but PR-Agent supports pinning to a release tag, and an unpinned third-party action with pull-requests: write is a supply-chain decision you should make deliberately. The if: guard matters - without it, bot-authored PRs trigger reviews that trigger comments that trigger reviews. Swap OPENAI_KEY for your provider’s key if you route to Claude, Gemini, Bedrock, Azure OpenAI or a local Ollama or vLLM endpoint through LiteLLM.

To gate on the result, add needs: [test] to the job and name pr_agent_job in your ruleset’s required status checks. To stop paying for reviews on every push, drop synchronize from the trigger list and re-review with a comment command.

GitLab CI

PR-Agent’s documented GitLab job, which runs the container directly rather than using an integration:

stages:
  - test
  - pr_agent

pr_agent_job:
  stage: pr_agent
  image:
    name: pragent/pr-agent:latest
    entrypoint: [""]
  script:
    - cd /app
    - export MR_URL="$CI_MERGE_REQUEST_PROJECT_URL/merge_requests/$CI_MERGE_REQUEST_IID"
    - export gitlab__url=$CI_SERVER_PROTOCOL://$CI_SERVER_FQDN
    - export gitlab__PERSONAL_ACCESS_TOKEN=$GITLAB_PERSONAL_ACCESS_TOKEN
    - export config__git_provider="gitlab"
    - export openai__key=$OPENAI_KEY
    - python -m pr_agent.cli --pr_url="$MR_URL" describe
    - python -m pr_agent.cli --pr_url="$MR_URL" review
    - python -m pr_agent.cli --pr_url="$MR_URL" improve
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'

GITLAB_PERSONAL_ACCESS_TOKEN and OPENAI_KEY go in masked CI/CD variables. The rules: block is what keeps this off branch pipelines. $CI_SERVER_FQDN is why this works unchanged on GitLab Self-Managed, which is the main reason GitLab shops end up here rather than on a cloud app. Note that the documented script runs three commands, so you are paying for three model calls per MR; drop improve first if you are cost-constrained. For the commercial alternative on GitLab, see CodeRabbit’s GitLab integration.

Jenkins

No vendor-published Jenkins recipe exists. We checked docs.pr-agent.ai/sitemap.xml on 2026-10-18: the installation pages are GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, local, and a Mosaico server. This stage is assembled from the documented Docker and CLI interface and should be treated as our construction, not the vendor’s:

pipeline {
  agent any
  environment {
    OPENAI__KEY            = credentials('openai-key')
    GITHUB__USER_TOKEN     = credentials('github-pat')
    CONFIG__GIT_PROVIDER   = 'github'
  }
  stages {
    stage('Test') {
      steps { sh 'make test' }
    }
    stage('AI review') {
      when { changeRequest() }
      steps {
        sh '''
          docker run --rm \
            -e OPENAI__KEY \
            -e GITHUB__USER_TOKEN \
            -e CONFIG__GIT_PROVIDER \
            pragent/pr-agent:latest \
            --pr_url "${CHANGE_URL}" review
        '''
      }
    }
  }
}

The pattern generalises because the container’s contract is small: a PR URL, a provider name, a provider token and a model key. The same four values make this work under Buildkite, CircleCI, Drone, Azure Pipelines or a cron job. when { changeRequest() } is the Jenkins equivalent of the GitLab rules: block, and putting the review stage after Test is the sequencing win.

Do not make this stage fail the build on findings by default. An LLM reviewer’s output is non-deterministic, and a non-deterministic blocking gate trains engineers to re-run the build until it passes. If you want blocking behaviour, gate on the deterministic stage and leave the AI stage advisory until you have measured its precision on your own repository. Our 14-day pilot protocol is the method for that.

When should static analysis run in a CI pipeline?

Direct answer: Deterministic static analysis runs on every push, in under a few minutes, failing the build on new findings only. The expensive AI review runs once per pull request, after tests pass, never per commit. The split exists because linters and SAST are cheap and reproducible while an AI review costs roughly $0.95 to $25 per invocation and produces different output each time. Verified 2026-10-18.

The layering is not a style preference. It is arithmetic.

Layer one, every push: fast and deterministic. Formatters, linters, type checks, unit tests, and a SAST pass. Semgrep CE with vendored rules, SonarQube’s scanner, or DeepSource’s engine, which runs 5,000-plus rules across 30-plus languages before any AI agent sees the code. These are pennies and seconds, they reproduce exactly, and they give you a defensible “this rule was enforced on every commit” statement.

Layer two, once per PR, after layer one is green: the AI review. Published per-review costs: Macroscope at $0.05 per KB reviewed with a $0.50 floor and a published $0.95 average, and four modes spanning Budget $0.025 to Ultra $0.20 per KB. Cursor Bugbot at roughly $1.00 to $1.50 per PR review. CodeRabbit on-demand overage at $0.25 per reviewed file. GitHub’s own estimate for Copilot code review: $0.05 to $1 at Lite effort, $0.25 to $5 at Balanced. Anthropic’s published token cost for its own Code Review: $15 to $25 per review.

Run that per commit on a 15-commit PR and you have multiplied your bill by 15 for an output that gets progressively more ignored.

Vendors already assume you want this and then default against it. CodeRabbit ships auto_incremental_review: true with auto_pause_after_reviewed_commits: 5, so incremental reviews keep firing until the fifth reviewed commit. Cursor Bugbot’s triggers.frequency takes everyPush or oncePerPr. Set it to oncePerPr.

Layer three, on merge or nightly: the expensive whole-repo work. Dependency and licence scanning, full SAST with cross-file taint, and secret scanning across history. Note the market gap here: cross-file taint analysis with an open source licence does not exist. Semgrep’s interfile: true is proprietary-only, Semgrep CE cannot do interfile, and Opengrep’s --taint-intrafile matches --pro-intrafile under LGPL 2.1 but goes no further (verified 2026-10-18).

One more rule, learned the expensive way: never review a broken build. If make test fails, the diff is wrong in ways the author already knows about, and an AI review of it generates findings that are symptoms rather than causes. needs: [test] in Actions, stage ordering in GitLab, when { changeRequest() } plus stage order in Jenkins. See what is a CI/CD pipeline for the general shape, and Snyk in CI/CD for the security-specific layering.

AI code review tools with configurable merge checks

Direct answer: CodeRabbit has the most configurable merge gate in the market: reviews.pre_merge_checks with off, warning and error modes on title, description, docstrings, linked-issue assessment and custom checks, where error can block the PR if request_changes_workflow is on. GitHub Copilot can count toward merge requirements via ruleset toggle. Anthropic Code Review deliberately never blocks. Verified 2026-10-18.

This is the section most comparison pages skip, so here are the exact keys.

CodeRabbit. From the published config schema, verified 2026-10-18:

Key	Default	What it does
reviews.request_changes_workflow	false	Auto-approves once comments are resolved, the latest commit is reviewed and no pre-merge checks are failing. On GitLab, all discussions must be resolved
reviews.commit_status	true	Mirrors review progress “using legacy commit statuses for compatibility with required checks”
reviews.fail_commit_status	false	On review errors, fails the outward review status surface. Leave at false and a failed review reports green
reviews.pre_merge_checks.*.mode	warning	off disables, warning posts a warning, error “requires resolution before merging” and can block if the request-changes workflow is on
reviews.pre_merge_checks.issue_assessment.mode	warning	Gate on whether the diff actually addresses the linked ticket
reviews.pre_merge_checks.custom_checks[]	[]	Named check plus free-text instructions, each with its own mode
reviews.pre_merge_checks.override_requested_reviewers_only	false	When on, the author cannot override a failing check. Eligible overriders are requested reviewers, members of requested reviewer teams on GitHub, and submitted reviewers with author association OWNER, MEMBER or COLLABORATOR

That last row is the closest thing to real role-based enforcement on review findings that we have found in any of these products. It is off by default.

Copilot. Configured through a repository or enterprise ruleset rather than a config file. The relevant toggles, per GitHub’s documentation verified 2026-10-18: “Automatically request Copilot code review” under Branch rules, “Allow Copilot to approve pull requests,” and “Allow Copilot approvals to count toward merge requirements.” Note the direction of travel: Copilot is set up to satisfy a merge requirement, not to block one. If a single approval is required and Copilot can supply it, you have weakened the gate, not strengthened it.

Anthropic Code Review refuses to be a gate, by design. It never approves and never blocks pull requests, and it never builds or runs your code. Three admin-set depth tiers per repository (Quick, Standard, Deep) and reviews now land in 6 to 10 minutes against roughly 20 in the preview. GA was 15 October 2026, Claude Team and Enterprise only, not on Pro or Max. Treat it as a very good advisory reviewer and gate on something else. More in Claude Code review.

CI-step tools gate by exit code, which is the cleanest mechanism of the four. A failing job is a failing check and branch rules already understand it. The discipline is to decide what “failing” means and keep it deterministic.

AI code review tools for custom CI pipelines

Direct answer: If your pipeline is not GitHub Actions or GitLab CI, your real options are the ones with a container and a CLI: PR-Agent (pragent/pr-agent, needs only a PR URL, provider name and two tokens), Semgrep CE, and SonarQube’s scanners. Everything else assumes a Git-host app. Verified 2026-10-18.

The test for “will this work in my weird pipeline” is one question: is there a documented container or binary that takes a pull request URL and a token and exits with a status code?

PR-Agent passes. Documented Docker invocations exist for GitHub, GitLab, Bitbucket and Gitea, each a single docker run with provider-specific env vars. pip install "pr-agent[all]" gives you the CLI directly. Commands are /review, /describe, /ask, /improve, /add_docs, /generate_labels and /similar_issue.

Semgrep CE passes, with the caveat about --config auto and semgrep login noted above.

SonarQube passes through its scanner CLI and Docker images, with the important edition split: SonarQube Community Build analyses the main branch only and has no pull request analysis, which starts at Developer Edition. SonarQube Cloud’s free tier does include PR analysis up to 50,000 lines of code on private projects. These two get conflated constantly.

Qodo Merge is a partial pass. Behaviour is file-driven through .pr_agent.toml and provider blocks such as [github_app] with pr_commands, which makes it scriptable, but it is a hosted product with on-prem and VPC options on Enterprise rather than a container you run in an arbitrary pipeline. See Qodo Merge on GitHub.

CodeRabbit, Greptile, Cursor Bugbot and Graphite all fail this test as pipeline components. They are excellent products installed the other way round. CodeRabbit ships a CLI and IDE reviews, and its self-hosted image exists, but self-hosting is gated at 500-plus seats per its own docs, and the CLI is not positioned as a pipeline product.

For Azure DevOps, Bitbucket Data Center or Gitea specifically, PR-Agent is close to the only answer in this market, and that is as much a market gap as a recommendation.

What this actually costs, honestly

Three cost lines, and most buyers only see the first.

Tool	Licence line	Model tokens	Pipeline minutes	Modellable end to end
PR-Agent	$0, MIT	Yours	Yours, or $0 on a self-hosted runner	Yes
CodeRabbit Essentials	$24/dev/mo annual, 1 linked repo	Included	None	Yes, plus $0.25/file overage
Greptile Pro	$30/seat/mo, 50 credits, $1 per extra	Included	None	Yes, but credits do not pool
Cursor Bugbot	Usage only, Premium $30/mo plan upward	Included	None	Yes, ~$1.00-1.50/review
Macroscope	$0 seats, $0.05/KB, $0.50 floor	Included	None	Yes, $0.95 published average
GitHub Copilot	From $10/mo, bundled	Credits at $0.01, est. $0.05-$5/review	Yes on private repos, unquantified	No
Claude Code Review	Claude Team or Enterprise, $20/seat/mo annual, 20-seat min	$15-25/review, vendor-published	None	Partly
Qodo Merge	~$30/mo up to 30 users	Credits $0.012, pooled, no rollover	None on the hosted app	Yes

Line 1, the licence. Per-seat: CodeRabbit Essentials $24 per developer per month annual ($30 monthly) covering one linked repository, Team $48 for 5 repos, Advanced $72 for 10. Greptile Pro $30 per seat per month with 50 credits included, $1 per extra credit, where a seat is any developer who received a review and credits are per author and do not pool. Sourcery Pro $12 per seat annual. Korbit Pro $12 annual, billed per Git author. Per-usage: Macroscope, Cursor Bugbot, CodeRabbit overage, as listed above. Bundled: Copilot from $10 per month, monthly billing only since 1 June 2026. Full normalisation in the AI code review price book.

Line 2, the model tokens. Zero if the vendor bundles inference, which most do. Yours to pay if you run PR-Agent or any self-hosted path against your own key. Anthropic’s published $15 to $25 per review for its own multi-agent topology is the only vendor-published token figure we have found for a shipping reviewer, and it is a useful upper bound on what a thorough multi-agent review costs in tokens.

Line 3, the pipeline minutes, which is where the honesty matters. For a CI-step reviewer, the arithmetic is simple: runtime in minutes times the published rate, so a three-minute Linux job is $0.018 and a 50-PR-per-day team spends about $27 a month. Self-hosted runners consume no Actions minutes at all.

For Copilot code review on private repositories, we cannot model it, and nobody else can either. Since 1 June 2026 those reviews consume Actions minutes in addition to AI credits. GitHub’s documentation acknowledges the mechanism and quantifies nothing: the review-depth page says only that Balanced reviews “use more AI credits, and may consume marginally more GitHub Actions minutes.” There is no published per-review minute figure. Any blog post giving you one has invented it.

What you can do instead is measure it. Turn Copilot code review on for one repository for two weeks, read the Actions usage report for that repository before and after, and divide by the number of reviews. That is a number for your repository, which is the only number that was ever going to be useful.

Two more Copilot cost facts worth carrying: included AI credits were cut on 1 September 2026 to 1,900 for Business and 3,900 for Enterprise, drops of 36.7% and 44.3% from the promotional June-to-August allowance, and paid overage is on by default for organisations. Also, the 300-file / 20,000-line PR cap was removed on 27 August 2026, which both improves the product and invalidates any Copilot benchmark run before September 2026.

What nobody has measured

Everything above is architecture and price, which are verifiable. Review quality in a pipeline configuration is not.

No party without a commercial stake has published a false-positive rate, precision figure or noise measurement for any shipping commercial AI code reviewer. The two genuinely independent benchmarks measure bare models in fixed harnesses rather than products you can buy: SWE-PRBench (350 PRs, human-annotated, the only benchmark publishing a per-model false-positive rate, Claude Sonnet 4.6 lowest at 0.227 and Llama 3.3 70B highest at 0.417) and CR-Bench from Nutanix (584 instances, 174 verified, reporting a signal-to-noise ratio explicitly because false positives are costly; GPT-5.2 single-shot at 27.01% recall and 3.56% precision).

c-CRAB (arXiv 2603.23448) converts human review comments into executable tests across 184 PR instances, 67 repositories and 234 validated review comments. Its v3 headline: “Considering the union across all four tools,” 97 of 234 tests were passed by at least one tool, 41.5%. Per tool: Claude Code 32.1%, Devin 24.8%, PR-Agent 23.1%, Codex 20.1%. Conflict disclosure: five of six authors are academic, at the National University of Singapore and Zhejiang University, but Ridwan Shariffdeen lists SonarSource as his affiliation and the paper carries a disclaimer that its conclusions do not represent SonarSource policy. Sonar sells SonarQube and acquired Gitar in May 2026, and Gitar is a paid sponsor of this site. SonarQube is not among the four tools c-CRAB evaluates, which blunts the conflict, but we flag vendor-funded benchmarks everywhere else so we flag this one too. Also: the widely circulated “40 to 70% false positive rate” figure is not in that paper and should not be cited to it.

SWE-PRBench carries one finding that bears directly on pipeline design: performance degrades with more context, through attention dilution. That is a tension with the “index the whole repo” sales pitch, though retrieval is not the same thing as stuffing more tokens into a prompt. If you are choosing between a Deep tier and a Standard tier, it is a reason to test rather than assume.

How we verified this

Every config block above was taken from the vendor’s own documentation on 2026-10-18, not from secondary write-ups.

What we read at source. PR-Agent’s GitHub, GitLab and local installation pages, plus push_outputs and the default configuration.toml on main. CodeRabbit’s published JSON config schema, which is where every default value and quoted description in the merge-checks table came from. GitHub’s merge queue documentation for the merge_group wording, Actions billing for the per-minute rates and included allowances, and the Copilot code review concept and automatic-review pages for effort modes, cost estimates and ruleset toggles. Qodo’s configuration reference for .pr_agent.toml precedence.

What we could not verify, stated plainly. We found no per-review GitHub Actions minute figure for Copilot code review anywhere in GitHub’s documentation, so the Actions component of Copilot’s cost is not modellable and we have not estimated it. We found no Jenkins page in PR-Agent’s documentation (checked docs.pr-agent.ai/sitemap.xml), so the Jenkins stage above is our construction from the documented Docker and CLI interface and carries no vendor guarantee. We found no independent benchmark that evaluates any reviewer in a CI-step configuration as opposed to an app configuration, so nothing here should be read as a quality ranking. Gemini Code Assist’s free tier status remains genuinely unclear - one source says it stopped serving requests on 18 June 2026, another still advertises it, and Google’s docs describe 100-plus PR reviews per day from a GitHub App install - so we excluded it from every table rather than guess.

What changed recently enough to break stale pages. Copilot’s large-PR caps were removed 27 August 2026. Copilot retired annual billing on 1 June 2026 and cut included credits on 1 September 2026. CodeRabbit renamed Pro to Essentials and Pro Plus to Team in September 2026 at unchanged prices, and is no longer free for private repositories. PR-Agent relicensed to MIT on 23 April 2026 under new governance. Anthropic Code Review went GA on 15 October 2026.

Recommendations

Criteria: where the code goes, whether you can sequence the review, and whether the verdict can stop a merge. Not review quality, because nobody independent has measured that for a shipping product.

If you have no data-residency constraint and want this working this afternoon: install a Git-host app and do not build a pipeline step. CodeRabbit at $24 per developer per month annual if you can live with one linked repository on Essentials, or Copilot code review at no incremental licence cost if you already pay for Copilot. Set reviews.fail_commit_status: true and reviews.auto_review.drafts: false on day one.

If code must not leave your network, or you need an audit trail in your own CI: PR-Agent as a pipeline step, pointed at your Azure OpenAI tenancy, Bedrock account or a vLLM endpoint, on a self-hosted runner. Free, MIT, and the [push_outputs] JSONL artifact is the compliance evidence the app model cannot produce. Set your fallback models explicitly - leaving a hosted default in the fallback chain is a genuine egress hazard.

If you are not on GitHub or GitLab: PR-Agent, because for Azure DevOps, Bitbucket Data Center and Gitea it is close to the only option, and that is a finding about the market rather than an endorsement.

If you want a real merge gate: CodeRabbit is the only tool here with a documented, granular, blocking pre-merge check system. Turn on request_changes_workflow, set the checks you care about to error, enable override_requested_reviewers_only, and keep commit_status on so your ruleset can require it. Then add merge_group to every required workflow before you enable the queue, or you will deadlock the repository.

What I would not do: make an LLM review a hard blocking gate before measuring its precision on your own repository, review on every commit, or run an expensive AI review inside a merge queue. And I would not believe any per-review Actions-minute number for Copilot, including one I might have been tempted to calculate.

Next: the workflow surface beyond CI, in AI code review integrations - issue trackers, chat, CODEOWNERS and repo-level rule files. For the Git-host side specifically, AI code review tools that support GitHub. For the setup walkthrough, AI code review in GitHub Actions.