It reads the whole pull request. It comments on almost none of it.

A review bot that earns its comments. Seven specialists read the diff, the findings are ranked, and only the ones worth your time land on your code. The rest go in the summary.

1 day free on every plan. Card required to start.

Changes requested3 of 12 findings posted
  1. api/sessions.py:118blockersecurity

    The session token is compared with ==, which returns as soon as two bytes differ. Use compare_digest so the comparison takes the same time whatever the input.

  2. api/sessions.py:204should fixtesting

    test_expired_session covers the expiry path but never the refresh that precedes it, so a refresh that silently extends a revoked session would still pass.

  3. web/members.tsx:61should fixperformance

    Each row fetches its own membership. Twelve members means twelve round trips before the table renders.

The other nine findings are in the review summary. None of them holds up the merge.
An example review, not a real pull request.

Three steps, then it is part of the repo

  1. 1

    Install the GitHub App

    Sign in with GitHub and pick the repositories it can see. Nothing outside that list is ever read.

  2. 2

    Open a pull request

    Or comment /review on one that is already open. Each repository decides for itself: every pull request, on request only, both, or off.

  3. 3

    Read the review on your diff

    Demands arrive as inline comments and withhold the approval. Advice stays in the summary, where you can ignore it without dismissing anything.

Seven specialists, and a triage that decides which of them run

Before any of them start, a cheap pass reads the diff and picks. Touch authentication and security runs. Add a migration and performance runs. A documentation change gets two reviewers, not seven, and your bill says so.

  • security

    Auth gaps, exposed secrets, injection, data leaks, and CVEs arriving with a new dependency.

  • architect

    Coupling, interface changes, file organisation, and refactors large enough to be worth arguing about.

  • performance

    N+1 queries, algorithmic complexity, and overhead landing on a path that runs per request.

  • testing

    Whether new code brought tests, and whether those tests cover the case that will actually break.

  • qualityalways runs

    Clarity, naming, and documentation.

  • product

    User-facing behaviour: changed API responses, error copy, accessibility, and whether the change finishes the job.

  • discussionalways runs

    CI on the current head, and the change requests a human left that nobody has answered.

We audited our own noise and then turned most of it off

Across 3,296 comments this reviewer had posted, the lowest-severity tier was 55% of the volume — and roughly one in ten of those was worth keeping. Those comments were not wrong. They were just not worth interrupting anyone for.

Findings are ranked, and the rank decides

Blockers and should-fix items become inline comments and withhold approval. Everything under that line is advice in the summary. You move the line: blockers only, or everything, per workspace or per repository.

It reads what it already said

Before writing, it pulls its own earlier threads on the pull request. A point you have already answered does not come back on the next push.

It cannot spam you

One pull request gets three re-reviews in five hours by default — room for a real back-and-forth, not enough for a stuck agent to run up your bill.

Your repository, your rules

What the reviewer cares about is set from the dashboard, not from a config file somebody has to remember to update.

Standing instructions
Tell it what this codebase cares about, in plain English. It applies on every review, to every specialist.
Ignored paths
Generated clients, vendored dependencies, lockfiles — the reviewer skips them instead of reviewing them badly.
Paths that need a person
Name the files where approval has to come from a human. The reviewer still comments; it just will not sign off.
Triggers, per repository
Every pull request, /review on request, both, or off. A busy monorepo and a side project do not need the same setting.
Screenshots of the change
Comment /screenshot and it brings the app up in its sandbox and looks at the interface you changed.
A log of every run
The dashboard keeps what each specialist found, what was posted, what was held back, and what it cost.

Three plans. One difference: who pays for the model.

Every plan is a monthly fee plus a per-review price for whatever the fee doesn’t cover. On the managed plan the model is included and we run it. On the bring-your-own-AI plans your own AI key pays for the model, and the fee covers only the part we run: the sandbox each review gets, the GitHub plumbing and the dashboard.

  • Managed

    $40per month

    Reviews included
    25 a month
    Each review after that
    $8
    Repositories and members
    Unlimited

    The model is included; we run it.

    Start your trial
  • Bring your own AI

    $19per month

    Reviews included
    10 a month
    Each review after that
    $1.50
    Repositories and members
    Unlimited

    You connect your own AI provider key; it pays for the model.

    Start your trial
  • Bring your own AI — Starter

    $5per month

    Reviews included
    None
    Each review
    $1.50
    Repositories and members
    Unlimited

    You connect your own AI provider key; it pays for the model.

    Start your trial

1 day free to start, with a card up front so the trial rolls into the plan without an interruption. Cancel from the dashboard any time before it does.

Bringing your own AI means connecting a ChatGPT account or adding an Anthropic API key in Settings, or giving a repository an anthropic_api_key secret. Your provider bills you for the model on top of our fee: a ChatGPT plan you already pay for covers reviews out of its own allowance, while an API key is billed per token for every one.

See pricing in full