# Reviews that matter, in seconds. Unblock your GitHub PRs with Rapid Review. Don’t waste time and tokens on slow and noisy reviews. [Start a trial](https://rapidreview.dev/go/beta) Any programming language · Trial: 50 credits or 14 days, whichever ends first An example of a review on a pull request, “Retry failed payments with backoff” (acme/checkout #482): an agent pushes; the `rapid-review` check posts 1 finding, a major one on `src/payments/retry.ts`, “Retries can charge a customer twice.”, with a suggested change; the agent pushes the fix, Rapid Review replies that it looks fixed and resolves the thread, and the check finds nothing new. ## Rapid Review by the numbers. Speed, volume, and precision. Time to review, median: 32 seconds. A review’s change, median: 900 changed lines and 11 files. Findings per pull request, average: 3.8, 2,746 in all, on 727 pull requests. Over 3,155 reviews in standard mode. ## Fast, without being shallow. Where a review’s speed comes from. In standard mode, most reviews of a pull request are complete in under a minute: every part of the change reviewed, the findings on the pull request as inline comments, and the summary comment and the `rapid-review` check up to date. Rapid Review was built for speed from the start, without giving up depth: fixed rules where rules are enough, fast models for quick judgements, and frontier models for reviewing the code. - **Every part of the change:** Standard mode reviews every part of the change, with context from the rest of the repository and the repository’s learnings. - **Frontier models on the code:** Anthropic’s Claude reviews the code. - **Fast models for narrow calls:** Fast models, such as TypeSafe AI’s Jev, make quick, narrow judgements along the way. - **Fixed rules where they’re enough:** Deterministic code analysis does the work fixed rules do well, with no AI model involved. [Why Rapid Review is fast](https://docs.rapidreview.dev/why-rapid-review.md) ## From the push to the fix. What Rapid Review posts on a pull request, and what it does with your replies. ### On the line it’s about Each finding is an inline comment with its severity, an explanation and a fix in words. A small, exact fix comes as a suggestion you can commit. An example of an inline comment on `src/export/pages.ts`: a major finding, “The export leaves out the last page.”, with a suggested change from `Math.floor` to `Math.ceil`. ### The check Each reviewed push gets a check named `rapid-review`. Its title gives the result; its summary, the rest. An example of the `rapid-review` check, titled “No new findings”, whose summary opens “2 of 3 earlier findings addressed, 1 open, no new findings.” ### Checks what got fixed On the next push, every earlier finding is checked against the whole push. A fixed one gets a reply, and its thread is resolved. An example of Rapid Review’s reply on a fixed finding, “Looks fixed in 9a03f51.”, with the thread resolved. ### Learns from your replies Reply to a finding with the reason it isn’t a problem, and Rapid Review can record it as a learning for later reviews of the repository. An example of a reply, “Intended: the importer adds the header itself.”, and Rapid Review’s answer that it recorded a learning for later reviews of the repository. ### One summary, kept current One summary comment says how many findings are new and how many are still open. It’s updated on each push. An example of the summary comment: “No new findings. No earlier finding is still open.”, a sentence on what the pull request does, and its folded sections. Examples of what Rapid Review posts on a pull request. Times in UTC. ## Built for the way agents push. Push first, describe later, push again. For coding agents Agents often push first and write the description after. Rapid Review can wait for it, reads what the pull request claims, and checks each later push against its earlier findings. An example of the `rapid-review` check on four pushes in turn: 2 findings posted; no new findings; waiting for the description, then 1 finding posted; no new findings. [How reviews run](https://docs.rapidreview.dev/reviews/when-reviews-run.md) ## Your code and data. What is sent, to whom, and who sees the reviews. - **Not used for training:** Review requests go only to model providers that do not train on the data. - **Secrets stay out:** Files that look like secrets are never sent to a model. - **Seen as on GitHub:** Only people who can see a repository on GitHub see its reviews. - **You choose what is read:** Files your configuration excludes aren’t read for the review. [What Rapid Review sends and stores](https://docs.rapidreview.dev/data-handling.md) ## Choose how to start. Open source, or a team. ### Open source A public repository under a license the Open Source Initiative approves can get free reviews: 100 credits a month and at most 10 in any hour (fair use policy). An admin of the repository applies in the Rapid Review app, and Rapid Review approves each application. [About free open-source reviews](https://docs.rapidreview.dev/open-source.md) ### Teams Rapid Review Developer is $30 a month with 40 credits. Rapid Review Pro is $49 a month with 70 credits. Rapid Review Max is $119 a month with 200 credits. Prepaid credits cost $1 each, bought in advance. A review uses 1 credit in standard mode and 3 credits in advanced mode. Trial: 50 credits or 14 days, whichever ends first, plus 100 credits with an invite code. Payments run through Stripe. [Start a trial](https://rapidreview.dev/go/app) ## Questions ### Which programming languages does Rapid Review review? Any. Rapid Review isn’t built for a fixed list of languages. ### Can Rapid Review approve or block a pull request? It never approves a pull request or requests changes. The `rapid-review` check blocks merging only if your branch protection requires it. ### Are draft pull requests reviewed? No. A draft is reviewed once it is marked ready for review. Pull requests from forks aren’t reviewed. ### How do I make reviews quieter? Pick a higher confidence tier or leave paths out in `.rapid-review.yml`, write review instructions in `.rapid-review/instructions.md`, and reply to wrong findings with the reason. ### Where do I see all reviews and findings? In the Rapid Review app. You sign in with GitHub and see the repositories you can see there. ## Get started with Rapid Review. Rapid Review is a GitHub App. Install it on a personal account or an organization, and choose its repositories. [Start a trial](https://rapidreview.dev/go/beta) · [Read the docs](https://docs.rapidreview.dev) Trial: 50 credits or 14 days, whichever ends first. ## How these numbers are counted - **Time to review:** From when a review starts to when its check is complete and its inline comments are posted: the median, which half the reviews took less than. The wait before a review starts, in the queue or for the pull request’s description, isn’t counted, nor the time GitHub takes to deliver the push and to show the results. - **A review’s change:** The changed lines, added and removed, and the files of the pull request that a review covers, each at the median. The files a review leaves out, such as lockfiles and files that look like secrets, aren’t counted. On a later push, the parts reviewed before and unchanged since are carried over rather than reviewed again, and count here. - **Findings per pull request:** Every finding the reviews showed, as an inline comment, in the review or in the check, over the pull requests they reviewed. A finding repeated on later pushes of a pull request counts once. - **Reviews:** Every review in standard mode that finished, of every account, since Rapid Review began recording them. The numbers are counted from Rapid Review’s review data, and are at most an hour old. --- © 2026 Rapid Review, Inc. · 2261 Market Street STE 73436, San Francisco, CA 94114, USA