The code reviewer that catches
the most real bugs
Drape reviews every pull request and catches more real bugs than any AI reviewer we tested — with 98% of its comments valid. And because it’s the CI Brain, every finding knows your CI history: which tests are flaky, what failed here before, what’s covered, and who owns the code.
5 free review units for every organization. No credit card required.
Benchmarked on verified bugs, not opinions
crbench runs every reviewer on the same 119 cases* — 91 real pull requests from Sentry, Grafana, Keycloak, Cal.com, Kubernetes, and more, plus 28 built to test specific bug classes, across 8 languages. Every defect is backed by a landed fix or revert, independent corroboration, or an audit.
| Reviewer | Overall | Real bugs caught | Comments valid |
|---|---|---|---|
| Drape | 69% | 88.4% | 97.8% |
| Cursor Bugbot | 56% | 73.9% | 98.8% |
| Claude Code (Opus 5.5) | 54% | 78.3% | 92.6% |
| Cubic | 44% | 63.6% | 90.5% |
| Greptile | 42% | 61.0% | 95.4% |
| Qodo | 39% | 54.0% | 94.5% |
| CodeRabbit* | 30% | 41.1% | 90.0% |
crbench leaderboard, October 2026. Overall weighs bugs caught by severity and charges for false alarms. Drape on Opus 5.5. *CodeRabbit reviewed 62 of the 119 cases. Anyone can submit a reviewer and re-run the scoring — see the full leaderboard and methodology.
How crbench is built
Real pull requests — and a bug only counts when something proves it.
crbench starts from real pull requests, many of them collected by Martian’s Code Review Bench — we’re grateful for the work that went into it. On top of those, crbench sets a higher bar for what counts as a bug.
Every defect needs proof: a fix or revert that landed after the change merged, independent corroboration, or an audit. Any valid finding earns credit, not only the ones on an answer key, so a reviewer that finds a real bug nobody listed isn’t scored as noise.
Every label we dropped is published with its reason, and anyone can submit a reviewer and re-run the scoring.
What doesn’t count as a bug
- A call that compiles. If the merged PR builds, “won’t compile” isn’t a defect.
- A change the language allows. If
tsc --strictpasses, it isn’t an interface break. - An import the same PR defines. The class exists, so the import resolves.
- A null-safe comparison. Comparing a missing value with
!=can’t throw. - A style preference. “Consider extracting a constant” is advice, not a bug.
Only in Drape
The only reviewer that knows your CI history
Other reviewers read the diff. Drape reads the diff and everything the CI Brain has learned about the code it touches — so findings come with evidence, and red builds come with an explanation.
- Flaky tests — “
test_checkoutfails 18% of runs onmain. A red run there isn’t yours.” - Failure history — tests covering this file failed 6 times in 30 days, so changes here get a closer look
- Coverage — changed lines no test exercises are called out next to the finding
- Ownership — each finding names the CODEOWNERS team that owns the path
Drape reviewed billing/invoice.py line 88
High Discount is applied after tax, so every discounted invoice overcharges by the tax on the discount.
test_invoice_totals failed 6× in 30 days
test_checkout
Flaky
not caused by this PR
On every push
Reviews that keep up with the PR
A review on every push shouldn’t mean the same comments on every push. Drape remembers what it said.
- Earlier findings are re-checked against the new code — fixed ones are marked resolved
- The same finding is never posted twice, even when the code around it moves
- Resolve the thread on GitHub or GitLab and Drape dismisses the finding; reopen it and the finding comes back
- The summary shows what’s new, what’s fixed, and what was already ruled out
Drape · PR #142 · push 3
In the thread
Push back. It listens.
Reply to a finding the way you’d reply to a colleague. Drape reads the reply, checks it against the code, and answers in the thread.
- Show it’s wrong and Drape withdraws the finding and resolves the thread
- Add context and Drape revises the finding to match
- Ask a question and get an answer that points at the code
- Replies are free — they never count as a review
Drape on api/orders.py
order.items can be empty here, so items[0] raises.
@dana
The serializer rejects empty orders before this runs.
Drape
You’re right — OrderSerializer.validate_items requires at least one item. Withdrawn.
Resolved
Built for how your team actually works
Reviews when you need them
Automatic when a pull request opens or is marked ready, and again on every push. Comment /drape review to ask for one. Drafts and bot PRs are skipped by default.
Your bar, per repo
Turn review on repo by repo and set the severity that earns an inline comment. Everything below it waits in the summary, folded away.
One inbox for every PR
Every open pull request with its verdict — Ready, Caution, or Block — next to its flaky tests, failures, and coverage. Watch a review in progress, finding by finding.
Isolated by design
Each review runs in a throwaway sandbox with read-only repository access and no secrets. Drape reads your code; it never runs it. The checkout is deleted when the review ends.
Safe on outside contributions
Pull requests from people outside your organization wait for a maintainer to ask before Drape reviews them.
A bill you control
Every active user adds 20 review units a month to a pool your org shares. Past that, prepaid credits — no overage billing.
Frequently asked questions
How is Drape different from Bugbot, CodeRabbit, or Claude Code?
Two ways. Drape catches more real bugs — 88% on crbench, ten points ahead of the next reviewer tested — while keeping 98% of its comments valid. And Drape is the CI Brain, so every review knows your CI history: which tests are flaky, what failed here before, what’s covered, and who owns the code. Other reviewers only see the diff.
What is crbench?
An open benchmark of real bugs, built on real pull requests — many of them collected by Martian’s Code Review Bench. Every defect is backed by a fix or revert that landed after the change merged, independent corroboration, or an audit. Any valid finding earns credit, not only the ones on an answer key. Every dropped label is published with its reason, and anyone can submit a reviewer.
When does Drape review a pull request?
When a pull request opens or is marked ready for review, and again on every push. You can also ask for a review with a /drape review comment or from Drape itself. Drafts and bot PRs are skipped by default, and pull requests from outside contributors wait for a maintainer to ask.
Does Drape run my code?
No. Each review runs in its own isolated sandbox with read-only access to the repository, no secrets, and no inbound network. Drape reads your code; it never executes it. The checkout is deleted when the review finishes.
Which code hosts are supported?
GitHub pull requests and GitLab merge requests.
How much does it cost?
Every organization gets 5 free review units, once. Pro includes 20 review units per active user each month, pooled across your organization — a busy repo can use what a quiet one doesn’t. Unused units don’t carry over. Past the allowance, owners buy prepaid credit packs: 100 units for $200, 500 units for $900, 2,000 units for $3,200. Credits last 12 months and are used only after the month’s included units. No overage billing: when the allowance and credits run out, Drape skips the review and says so on the pull request, with a link for an owner to buy more. Reviews pick up again next month, or as soon as credits are bought.
What is a review unit?
A review unit is one completed review of up to 1,000 changed lines. A bigger change counts once per started 1,000 lines, so a 2,400-line pull request is 3 units. Lockfiles, generated, and vendored files don’t count, and a review of a later push counts only the lines that push changed, so most follow-up reviews are 1 unit. Replies to findings are free, and a review that fails or is skipped is never billed.