QuickReview

A self-hosted AI code reviewer for GitHub pull requests: many narrow reviewers, one verified review.

A single model asked to "review this PR" reads the diff once, from one angle,
and stops when it has found something worth saying. QuickReview fans each
change out to a dozen or so narrow, read-only lens passes that each look
for one kind of problem and never see each other's output. It merges their
findings so one root cause gets one comment, and an adversarial validator
re-derives every candidate from the code before one review is posted.

On 185 real PRs with 520 defects each verified in the code, QuickReview on
GPT-6.1 Sol finds 97% of the high-severity defects, 93% of the medium and
84% of the low; at each severity the best of the six other reviewers we ran
finds 90%, 82% and 52%. On the same model it also finds more than the model
maker's own reviewer at every severity: against Claude Code's /code-review
on Claude Opus 5.5 and against Codex CLI on GPT-6.1 Sol. That recall costs
more: about $2 and 17.5 minutes per PR, where the other tools take $0.07–0.53
and 0.7–2.3 minutes (Benchmarks).

Around the review sits a small, deterministic TypeScript daemon with no LLM
in its decision path. It takes GitHub App webhooks, runs an authoritative
reconcile poll, keeps one sticky pi
session per PR, and posts as your GitHub App through one gated mutation
path, on your infrastructure, under your keys.

Status: beta. The reviewer has run continuously since mid-August 2026 on
a busy commercial repository. The packaging for other teams is young: expect
rough edges in setup. dry_run = true is the shipped default, so a fresh
install never posts anything.

How a review works

1. Plan the lenses by rule. Plain code, not a model, reads the changed
   files and the PR text and plans the passes, each with the reason it was
   planned. The PR's session may add a lens or raise its reasoning tier, with
   a stated reason; it may never drop one.
2. Fan out isolated lenses. Each pass is a leaf agent with read-only
   tools, the diff and a worktree at the exact head. None can see another
   pass, spawn agents, or run your code. pass-baseline and pass-tests run
   on every code change, pass-sweep reads every changed file line by line,
   and the rest are picked by path, content and size: behaviour delta, code
   quality, intent against the PR text, backward compatibility, security,
   data safety, concurrency, bounds, rollout and more.
3. Merge duplicates. One root cause becomes one comment anchored at its
   cause, with the other sites in its body
   (docs/duplicate-merge.md).
4. Validate. pass-validate re-reads the code for every candidate and
   keeps, demotes, doubts or kills it from a closed vocabulary. A plausible
   but wrong finding costs more than a missed nit.
5. Post one review. Severities map to tags by fixed rules (any surviving
   blocker means REQUEST_CHANGES), the review posts through the gate, and
   every candidate, posted or not, lands in a per-finding reasoning record.

The lens catalogue, with each lens's trigger and severity cap, is §3.3 of the
QuickReview report.

Benchmarks

Recall is the headline: a review that misses the defect has failed, whatever
else it does. Precision, cost and time are shown beside it, because that is
where QuickReview pays. Unless a chart or table names another build or model,
its results are the frozen build of 2026-10-04 on gpt-6.1-sol, shipped
defaults, one review per PR. The third-party tools we ran used the best
configuration we found for each (except Claude Code, which ran /code-review
at its default effort and was not varied), the OpenAI-based ones on the same
model, under the same judge on the same PRs. Every run behind these results
is public, with its reviews, verdicts and answer key, in the Hugging Face
dataset quickchatai/quickreview-bench
(DOI 10.57967/hf/11598), and each number can be recomputed from it.

AACR-Bench, verified defects. AACR-Bench's own reference comments are
mostly not real problems, so we built a key of 520 defects, each verified in
the code and graded by its consequence: high would block a merge (a
user-visible bug on a normal path, a crash, data loss, a security hole, a
broken build), medium should be fixed before merge, low is real but
fine as a follow-up. The chart at the top is this key. QuickReview misses 2.5
of the 90 high-severity defects, 10.5 of the 145 medium and 46 of the 285 low
(a partly found defect counts as half); the best other reviewer at each
severity misses 9, 26 and 136.5. Over the panel and Codex CLI the
high-severity lead holds under a paired bootstrap (+8.3 points [+1.9, +14.6]
over the panel). The price: 6.9 comments per PR, 42% of them true but minor.

Same model, two reviewers. With the model held fixed, QuickReview still
finds more than the model maker's own reviewer on each of the three models
where we ran both, at 11 to 20 times the cost ($3.24 against $0.16 per PR on
Opus). This contrasts two tools, not a measured design effect: they also
differ in budget and inputs, Claude Code ran /code-review at its default
effort, and the Opus and GPT-6 Sol rows are September builds of QuickReview.

Martian, 50 PRs. Martian scores against about three "golden" comments
per PR and counts every other comment as a false positive. It extracts about
12.8 issues per PR from QuickReview's reviews, so QuickReview has the highest
recall and the lowest precision. We
audited the goldens: of the 86 that describe a real defect the PR
introduces, it finds 75 (87%), the most of the seven reviewers judged alike.

Qodo PR-Review-Bench, 100 PRs. 580 injected issues: 309 functional bugs
and 271 violations of rules written in the repo. QuickReview finds the most
functional bugs of the thirteen tools (52.1%) and the second-most issues
overall, at the lowest precision; it is fourth on F1.

Judged side by side. A pairwise judge reads two reviews of the same PR
blind and picks the better one. GPT-6.1 Sol and Claude Opus 5.5 both judged,
and a Bradley-Terry fit over their 596 verdicts gives Elo; alone, the two
judges pick the same winner only 56% of the time, which is why they are
pooled. On the 20 Martian PRs where QuickReview on GPT-6.1 Sol or DeepSeek did
worst, QuickReview on Opus 5.5 (six of its lenses on GPT-6 Luna) beat Claude
Code's /code-review at high effort on Opus 5.5 in 29 of 40 verdicts, at more
than ten times its cost ($4.61 per PR on average). Only Claude Code's max mode (Opus
5.5 directing Sonnet 5.5 agents, about $20 per PR) ranks higher, by a margin
inside the intervals. Every judgment, with both judges' reasoning, is in the
dataset's elo_judgments table.

Other models. QuickReview runs on any model provider pi supports, on the
credential you already have. On AACR-Bench
it holds most of its recall on cheap open models, and it falls apart on a
weak one:

QuickReview on	PRs	High (90)	Medium (145)	Low (285)	All (520)	Mean $/PR	Judge
GPT-6.1 Sol (frozen build)	185	87.5 (97%)	134.5 (93%)	239 (84%)	461 (89%)	2.06	gpt-6-sol
DeepSeek V4.1 Flash (mostly low effort)	185	83 (92%)	131 (90%)	237.5 (83%)	451.5 (87%)	0.74	gpt-6.1-sol
GLM-5.3 Flash	185	83 (92%)	120.5 (83%)	231.5 (81%)	435 (84%)	0.52	gpt-6.1-sol
GPT-6 Luna	185	39 (43%)	44 (30%)	64 (22%)	147 (28%)	0.04	gpt-6-sol
Claude Opus 5.5	40	32/34 (94%)	30.5/31 (98%)	57/61 (93%)	119.5/126 (95%)	3.24	gpt-6-sol

The best third-party reviewer at each severity finds 81 of 90 high (Codex
CLI), 119 of 145 medium and 148.5 of 285 low (both the pi-review panel). The
open-model rows ran a later build (mid-October, with cost changes made after
the freeze) and a later judge; DeepSeek ran at low reasoning effort on 143 of
its PRs and lost one lens pass on 5 PRs. On GLM, one lens pass was lost on 1 PR
and the validator on 2, and on 7 more a lens pass ran but is missing from the
review's record of executed passes. The GPT-6 Luna and
Opus rows ran a September build; on the same 40 PRs as Opus, the frozen
GPT-6.1 Sol build finds 33 of 34 high, 28 of 31 medium and 44 of 61 low. Read
the table as directional. The open-model runs, their reviews and their
verdicts are in the dataset.

The full tables

AACR-Bench (185 PRs, 10 languages, 520 verified defects; a partly found defect counts ½)

Reviewer	High (90)	Medium (145)	Low (285)	All (520)	Comments correct	Mean $/PR	Median min/PR
QuickReview	87.5 (97%)	134.5 (93%)	239 (84%)	461 (89%)	92%	2.06	17.5
pi-review panel (high)	80 (89%)	119 (82%)	148.5 (52%)	347.5 (67%)	89%	0.27	1.8
Claude Code (Opus 5.5)	72.5 (81%)	105 (72%)	147 (52%)	324.5 (62%)	81%	0.20	0.7
open-code-review (high)	63.5 (71%)	102 (70%)	133 (47%)	298.5 (57%)	86%	0.53	1.8
Codex CLI (high)	81 (90%)	101.5 (70%)	104.5 (37%)	287 (55%)	93%	0.14	2.1
OpenCode (+ PR text)	76 (84%)	99 (68%)	88.5 (31%)	263.5 (51%)	93%	0.17	2.3
PR-Agent	55.5 (62%)	70 (48%)	68.5 (24%)	194 (37%)	76%	0.07	1.9

Martian (50 PRs, Core; one gpt-6.1-sol judge for every row, the vendor rows re-judged from their published comments)

Tool	Precision	Recall	F1	F2	Real goldens (86)	Mean $/PR	Mean min/PR
QuickReview	16.2	65.8	26.1	40.9	75 (87%)	2.84	26.1
qodo-extended-v2	56.2	60.1	58.1	59.3	68 (79%)	–	–
cubic-v2	54.3	60.1	57.1	58.9	58 (67%)	–	–
open-code-review	26.7	58.9	36.8	47.4	67 (78%)	0.86	3.3
PR-Agent	41.9	36.1	38.8	37.1	46 (53%)	0.09	1.4
claude-code	36.5	41.1	38.7	40.1	45 (52%)	–	–
OpenCode	32.7	33.5	33.1	33.4	48 (56%)	0.19	2.4

Qodo PR-Review-Bench (100 PRs; one gpt-6.1-sol judge under Qodo's stated matching rule; five more vendors are in the paper)

Tool	Comments/PR	Precision	Recall	F1	Functional recall	Rule recall	Mean $/PR	Mean min/PR
qodo-exhaustive	4.6	58.0	46.4	51.5	48.2	44.3	–	–
qodo-precise	3.1	68.0	35.9	47.0	36.2	35.4	–	–
augment	2.5	67.5	29.7	41.2	49.2	7.4	–	–
QuickReview	7.1	37.3	45.3	40.9	52.1	37.6	2.48	19.6
OpenCode	2.6	64.9	29.0	40.0	43.7	12.2	0.20	2.3
copilot	4.2	46.8	33.6	39.1	46.3	19.2	–	–
open-code-review	3.5	47.1	28.1	35.2	45.6	8.1	0.46	1.9
PR-Agent	3.4	47.2	27.2	34.5	43.7	8.5	0.10	1.2

Tuning and held-out PRs. The last tuning round was mined from misses on
part of each benchmark, including 145 of the 185 AACR-Bench PRs. The 40 PRs
in the Opus comparison were used to tune its September build. On the PRs
kept out of the last tuning round, the frozen build finds 83% of AACR-Bench's
defects (20 PRs), against the next best 72%, ties qodo-extended-v2 on Martian's
real goldens (43 of 52, 30 PRs), and on Qodo (31 PRs) reaches 60.3% recall and
F1 53.0, level with qodo-exhaustive's 51.3.

Read more. Two papers carry the method, every table and the threats to
validity: Measuring whether a code review finds the real
defects and QuickReview: a multi-pass
automated code reviewer.
Every run behind these numbers is published as the Hugging Face dataset
quickchatai/quickreview-bench: the answer
key, every review and verdict, the Elo judgments, and the run directories
with a numbers-only extract in place of each raw session log. bench/aacr/recompute/
rebuilds each number from it with no model call, and
bench/aacr/README.md shows how to
re-score the runs with no keys, re-judge them with our judge or
your own, or re-run the
benchmark on your own keys. Costs are list
prices; on a subscription plan they are quota, not a bill. The charts are drawn
by bench/aacr/showcase/readme_charts.py.

Why this exists

Nobody on your team is actually reviewing the volume of code your team now
produces. The author asks their agent to write the code, the reviewer asks
their agent to review it, the author replies "address the comments" — two
humans spending a day as slow message brokers between two AIs. The review
was already AI on both sides. The dead time was ours.

QuickReview moves human judgment up a level, to "is this something we need
and want?", while the machine checks what is checkable. The philosophy, in
short, is in MANIFESTO.md.

What it does around the review

• Reviews on trigger. A label or a team review request marks a PR;
  everything else is ignored, and bot-authored PRs never queue.
• One sticky session per PR follows it through pushes, author replies,
  re-reviews and rechecks, with a pinned findings ledger that survives
  context compaction.
• A hard severity contract: P0–P2 blockers, questions, nits; a
  reachability gate; a cap on nits in re-reviews. [check this] marks what a
  human must verify, [ask your human] what the author's AI must ask its
  person, [deferred] what is real but not for this PR (the reviewer files
  it).
• CI-aware approvals. Without green CI at the head, approval is withheld
  and the review posts as a COMMENT.
• Post-approval rechecks. Pushes, CI results, base advances and replies
  wake the same session; the only allowed change of verdict is APPROVE →
  REQUEST_CHANGES, never a silent re-approve.
• A learning loop. [feedback] comments and signals such as merges over
  a standing block demote the validator's bar the same day; an end-of-day
  sweep curates durable learnings, and rubric changes land only on one-click
  human ratification.
• One mutation gate. Every GitHub write goes through one gate with
  posting-time guards; in dry-run each would-be write lands in
  state/dryrun/. No code path dismisses a review.
• Sovereign by default. Self-hosted daemon, your GitHub App, your memory
  store, rules as files in your repo. Only the model call and the names of
  packages a PR imports (fetched from npm and PyPI so the reviewer can read
  the library; [review] dependency_sources = false turns it off) leave your
  infrastructure. Memory embeds locally.
• The reviewer reads code; it never runs it. The layers that hold that
  line, what they guarantee and what they do not, are written as claims you
  can falsify in docs/exec-boundary.md. Please try.

Optional, and each degrades cleanly when unconfigured: an operator TUI, a
Slack concierge, a local companion session, opt-in escalation notes, and the
OpenViking-backed reviewer memory.

Quickstart

You need Docker with Compose v2, a model credential, and either gh
signed in to your own GitHub account or a GitHub account that can create an
App on the repository to review. On Windows, run everything inside WSL2.

1. Sign in to a model provider, or have a provider key in the
   environment. Any provider pi supports works: a subscription login, an
   API key stored by pi's /login, or a key under the name the provider
   documents. The review runs on the credential you have.
2. Connect GitHub: gh signed in, or a GitHub App.
3. Choose a repository.

The home, below, walks the three steps and skips what is already done.

There is a second route that needs no App: [github] auth = "user" runs the
reviewer on your own GitHub account. Use it on one box where gh is
already signed in. It is polling-only, with no webhooks and no tunnel. Every
review it posts is a COMMENT that states its verdict, because an automated
verdict must never count as your approval and GitHub refuses either on your own
PR. Your token reaches the daemon only as the 0600 file
<secrets dir>/github_token, which qcr github-token sync refreshes from
gh. It never comes from the environment or a command line. On the App route
no personal access token is used.

# once: install `qcr`, the host wrapper the image writes (docs/host-wrapper.md);
# the images are public on ghcr.io
docker run --rm --user "$(id -u):$(id -g)" -v ~/.local/bin:/out \
  ghcr.io/quickchatai/quickreview:<version> install

qcr                  # the home: sign in, connect GitHub, choose a repository

A bare qcr opens the home: QuickReview's own pi, with the plugin loaded
and a panel of your repository's open pull requests. On a first run the panel
is a short setup checklist, and anything already set up is found and skipped:
sign in to a model provider with pi's own /login (a provider key already in
the environment counts, and the step is then found done), check that gh is
signed in, and choose a
repository from your recently pushed ones or paste any owner/name or URL.
alt+n runs the next step. The home then lists the pull requests, "To review"
and "Reviewed". qcr tui opens the admin TUI, and only it starts the
companion. Through the Docker wrapper the home runs in a container of its own:
its login is kept in the qcr-login volume, its config and sessions in the
qcr-state volume, and its gh uses the token the wrapper finds on this
machine (GITHUB_TOKEN, GH_TOKEN or gh auth token). The always-on daemon, a GitHub App, webhooks and a server over ssh
are the setup wizard's steps: docs/onboarding.md.

Which model it runs on

The shipped config names no model. With one model credential, a review runs
on that provider, on its newest model that reasons. With several, a terminal
asks once and remembers, and a run with nobody to ask picks one and says, in
one line, which model runs, why, and how to change it. qcr model shows the
model and what else is usable, qcr model use <provider[/model]> changes it,
--model picks for one run, and [models] model in config.toml pins it.
The estimate was measured on one model: on any other a review shows no dollar
estimate and stops at a spend limit instead (the GitHub Action has only the
limit you set). All of it is in
docs/llm-setup.md.

Where the reviewer lives

• This computer, in Docker (docker/README.md): the
  pick when the machine is itself an always-on server, such as a cloud VM;
  on a laptop it reviews only while the machine is awake.
• A server over ssh, recommended when your own computer sleeps. Setup
  rides the Ansible deploy
  (deploy/ansible/README.md); it needs
  passwordless sudo there and ansible-playbook on your machine.

Polling is the default: the daemon checks GitHub every few minutes and
exposes nothing, at the cost of trigger latency up to one poll interval and
quiet author-reply routing and [feedback] loop. Webhooks need an HTTPS URL:
a Cloudflare quick tunnel, ngrok or your own named Cloudflare tunnel, on the
App route only. The trade-offs are in
docker/README.md.

dry_run = true stays on until you flip it, through the wizard's go-live
step or by hand (docs/ownership.md); a dry-run install
is a complete one whose reviews are files you read. Slack is set up
separately, any time, with npm run slack:setup from a clone (the image
does not carry it yet).

Install with npm

The npm package is the whole app, the same code the image runs, as the qcr
command on Node 22.19 or later (npm, pnpm and bun all work; an older Node is
not blocked, but only 22.19+ is supported):

npm i -g @quickchatai/quickreview

qcr login              # pi's own /login: any provider pi offers
qcr model              # which model reviews run on, why, and what else is usable
qcr review             # review this branch against its base, with no daemon
qcr review 123         # review a pull request (or pass its URL)
qcr pi                 # pi with the plugin (/qcr-review /qcr-scan /qcr-setup) and /selfimprove
qcr update             # update qcr with the package manager that installed it
qcr                    # the home: pi on your own login, with your repo's pull requests
qcr tui                # the admin TUI

qcr review asks where the result goes (shown, saved as markdown and JSON,
or posted to the PR as a comment-only review through the same gate as the
bot); piped or with --json, it prints. Without Docker, memory is off and
the companion runs unsandboxed, and both say so; the release image is still
the better host for an always-on bot (docker/README.md).

Already using pi? Install just the plugin:
pi install npm:@quickchatai/pi-quickreview
(packages/pi-plugin/README.md).

In your coding-agent CLI

One command installs QuickReview's review, scan and setup into each
coding-agent CLI on this machine, with no Docker. Each line is what to run,
then what to type in that CLI:

npx @quickchatai/quickreview plugin install --to claude        # Claude Code: /qcr:review /qcr:scan /qcr:setup
npx @quickchatai/quickreview plugin install --to codex         # Codex: $qcr:review $qcr:scan $qcr:setup
npx @quickchatai/quickreview plugin install --to copilot       # Copilot CLI: /qcr-review /qcr-scan /qcr-setup
npx @quickchatai/quickreview plugin install --to cursor        # Cursor: /qcr-review /qcr-scan /qcr-setup
npx @quickchatai/quickreview plugin install --to opencode      # opencode: /qcr-review /qcr-scan /qcr-setup
npx @quickchatai/quickreview plugin install --to gemini        # Gemini CLI: /qcr:review /qcr:scan /qcr:setup
npx @quickchatai/quickreview plugin install --to antigravity   # Antigravity: /qcr:review /qcr:scan /qcr:setup
npx @quickchatai/quickreview plugin install --to all           # every one found on this machine
npx @quickchatai/quickreview plugin update                     # every install, to this release
npx @quickchatai/quickreview plugin uninstall --from all       # or --from <host>

With qcr installed, qcr plugin … is the same command. Each host's scope,
reload step and the move from the old Docker-based Claude Code plugin are in
docs/plugin.md.

Configuring and running it

• Repo profiles (docs/profiles.md): house-rule
  addenda, lens-selection heuristics and per-lens switches. Shipped:
  default, example-django, minimal, fast, snappy and security
  (a security-only review by the fourteen pass-sec-* lenses); start from
  extends = "default" and write only what differs.
• Security review on demand: the qcr:security label or
  @<bot> security from a collaborator, or qcr review-now <pr> --security,
  adds the security lenses to a PR's next round.
• Presets: [review] preset is default, max (every model at its
  ceiling) or low (about half the cost and time, lower recall).
• Cost: the daemon is one small container; the model spend is per round.
  On AACR-Bench a review averaged $2.06 per PR at list prices (median
  $1.87); on Martian's and Qodo's PRs, $2.84 and $2.48. Those figures are
  GPT-6.1 Sol's; another model costs what its own prices and token use make
  it. Watch it with qcr spend and qcr today, time to first verdict
  with qcr metrics, and start with the trigger label on a few PRs.
• Operating: qcr status, qcr why <pr>, qcr tui, and
  docker compose logs -f daemon on the laptop route.

Direction: per-lens yield drives lens tuning, profiles grow beyond
Django, and review history is fed back into your implementing agents'
instructions. Non-goals: no
rebuilding GitHub's PR workflow, no running your code, no hard round budget,
no reading the implementing conversation, and the fixer and the reviewer are
never the same system (MANIFESTO.md).

Documentation

• docs/architecture/README.md — the process map, the review lifecycle, the sessions, the data model, the safety seams
• docs/onboarding.md — the guided setup, step by step
• docs/github-app-setup.md — the GitHub App, and how to register it by hand
• docs/llm-setup.md — models and credentials: which model a review runs on, how to pin one, what it costs
• docker/README.md — the compose stack, ingress shapes, version pin
• deploy/ansible/README.md — the server route
• docs/host-wrapper.md — the qcr host wrapper
• docs/profiles.md — repo profiles and per-lens tuning
• packages/pi-plugin/README.md — the pi plugin
• docs/plugin.md — QuickReview in Claude Code, Codex, Copilot CLI, Cursor, opencode, Gemini CLI and Antigravity
• docs/ownership.md — the owner-only surfaces: the dry-run flag, frozen seeds, ratification
• docs/exec-boundary.md — what stops a review session running your code
• docs/memory-embeddings.md — the embedder: local by default, hosted opt-in
• bench/aacr/README.md — the benchmark harness
• AGENTS.md — orientation for an AI agent editing this codebase
• CONTRIBUTING.md, CODE_OF_CONDUCT.md and SECURITY.md

Appendix — setting up by hand

The setup wizard's steps (docs/onboarding.md) compose
these tools rather than replacing them; re-running one afterwards re-checks it
without rewriting what already holds.

IMG=ghcr.io/quickchatai/quickreview:<version>
mkdir qcr-bot && cd qcr-bot
docker run --rm --entrypoint tar $IMG -C /opt/qcr -cf - docker-compose.yml docker/tunnel | tar -xf -
mkdir -p ~/.config/qcr/default/secrets      # app_id, app.pem, webhook_secret, one file each, 0600
docker run --rm --entrypoint cat $IMG /opt/qcr/config.example.toml \
  > ~/.config/qcr/default/config.toml       # fill the marked values
# .env: QCR_VERSION, QCR_UID, QCR_CONFIG_HOME, QCR_SECRETS_DIR, QCR_CLONE_DIR (docker/README.md)
docker compose pull --ignore-buildable
docker compose up -d
curl -s http://127.0.0.1:8787/health

Then point your HTTPS ingress at the webhook port, install the App, create
the trigger label and label a PR: state/dryrun/ fills up. The memory keys
are minted by the running server (the wizard's memory-keys steps, 60 and 72,
in docs/onboarding.md); declining memory is supported.

Star history

Acknowledgements

• Matt Pocock's skills: processes
  as versioned files an agent can follow. Its wayfinding, spec-writing,
  ticketing and grilling skills drove the loop that built this codebase.
• pi: small, sharp agent sessions
  you can attach to, with extensions that compose. Every review session is a
  pi session.
• OpenViking: the memory
  engine behind the reviewer's learning, on your own infrastructure.
• pr-agent: studied closely in
  docs/pr-agent-comparison.md.

License

MIT (LICENSE); third-party attributions in
THIRD-PARTY-NOTICES.md.