PR Lens vs Claude Code Review

Claude Code Review and PR Lens answer different questions, so neither replaces the other. Claude Code Review reads a pull request hunting for bugs and posts each finding as an inline comment on the line it came from. Anthropic's own documentation puts the average at $15 to $25 per review, billed on token usage, as of September 2026. PR Lens looks for nothing. It draws the pull request as animated architecture and data-flow diagrams and posts them as one comment inside the pull request. Claude Code Review tells you which line is wrong; PR Lens tells you what the whole change is.

I use both. This post is about where the line between them falls.

What Claude Code Review does

Anthropic launched Code Review on 9 March 2026, and TechCrunch's write-up that day described it as a tool that "automatically analyzes AI-generated code, flags logic errors, and helps enterprise developers manage the growing volume of code produced with AI".

The mechanism is in Anthropic's docs. When a review runs, several agents analyse the diff and the surrounding code in parallel on Anthropic's infrastructure. Each agent looks for a different class of issue. A verification step then checks each candidate finding against actual code behaviour and drops what it cannot substantiate. What survives is deduplicated, ranked by severity, and posted as inline comments on the lines where the issues are, with a summary in the review body. Findings carry one of three severities: Important, Nit, and Pre-existing, the last of those for a bug that was already in the codebase before this pull request.

Two details I like. The check run always completes with a neutral conclusion, so a finding never blocks a merge through branch protection. And the review reads a REVIEW.md at the repository root, which the docs describe as review-only instructions given to the agents that find and verify findings. You can cap how many nits a review posts, list paths to skip, and redefine what Important means in your repository. That is a real answer to the noise problem, and most tools in this category do not have one.

Reviews complete in 20 minutes on average, according to the docs. An owner turns Code Review on once for the organisation and then picks per repository whether reviews run once when a pull request opens, on every push, or only on request. Commenting @claude review works in any of the three.

What PR Lens does

PR Lens takes the diff, the surrounding system, and writes a typed JSON graph document: lanes, nodes, edges, and what the change did to each one. A renderer turns that document into SVG. The model never draws anything.

You get two lenses. The architecture lens is the blast radius: what the pull request touches, drawn against the parts of the system it did not touch, with the calls that run between them. The data-flow lens is the ordered pipeline as an animated sequence, one dot crossing one arrow at a time. Colour carries the delta: green new, amber changed, red gone, with removed components struck through.

It arrives as exactly one comment on the pull request, rewritten in place on every push, with nested details sections that scope the diagram down to the new path or to what was retired. Every comment links to a canvas at prlens.dev/c/<id> where the same diagrams are full size, and where pressing play walks the change one step at a time.

There is no findings list and no severity anywhere in it. Nothing in a PR Lens comment tells you that a line is wrong.

The difference on one pull request

Take a checkout change: a payment intent is created in a new place, an order worker starts writing an audit event, and a receipt is persisted where it was not before.

Claude Code Review reads that diff and tells you the token refresh races with logout, or that a query is not scoped to the caller's tenant. Those findings are precise and they are local to a line, and they assume you already know what the change is trying to do.

PR Lens draws the change: the route that moved, the worker that now runs after it, the store that gained a write, and the parts of the system around them that stayed still. It makes no claim about correctness. It shows you where the change landed, which is where a reviewer looks first.

That distinction matters more than it used to. LinearB's 2026 benchmarks, drawn from 8.1 million pull requests across more than 4,800 organisations, found that AI-generated pull requests wait 4.6 times longer for a reviewer to pick them up, at over 16 hours against about 200 minutes. Once review starts, the AI ones finish faster. The cost is in the picking up, and a findings list does not touch it, because you cannot read a finding until you have opened the pull request and decided to engage with it.

What Claude Code Review is good at

Bug finding, honestly. The verification pass is the part I would copy if I were building a finder. Making agents challenge their own output before it reaches a human is the only mechanism I have seen that meaningfully cuts false positives, and false positives are what kill these tools inside a team. Three reviews of noise and everyone starts scrolling past the bot.

It is also well behaved on the pull request page. Findings arrive with thumbs up and thumbs down already attached, a fixed issue auto-resolves its thread on the next push in push-triggered mode, and the check run carries a severity table whose last line is a machine-readable count you can pull with gh and jq if you want to gate merges yourself.

The pricing is honest about what it is. Reviews are billed on token usage, average $15 to $25 each per the docs, and are billed through usage credits rather than out of a plan's included usage. Running on every push multiplies that by the number of pushes, which the docs say plainly. For a team merging a hundred pull requests a month, that is a real line item, and it is worth it if the bugs it finds are real.

Which plans can use Claude Code Review, as of September 2026

The managed service is a research preview for Team and Enterprise subscriptions, and it is not available to organisations with Zero Data Retention enabled. On other plans you can still run /code-review inside a local Claude Code session, which reviews your branch's commits and your uncommitted changes without installing anything on GitHub.

There is a third route worth knowing: the claude-code-action GitHub Action can install the code-review plugin and run the same skill from your own workflow, with --comment so the findings land on the pull request. On public repositories, GitHub withholds secrets from runs triggered by fork pull requests, so that route reviews only branches in the same repository. Vendor terms move; check the docs before you budget against any of this.

PR Lens is MIT licensed and free for open source. The hosted GitHub App runs on Gemini and needs no key of yours. If you would rather keep the model call in your own CI, the Action takes your own key and speaks Gemini, OpenAI, or any endpoint that answers /chat/completions. Full list of routes in what is PR Lens.

Can I run both on the same pull request?

Yes, and they do not collide. Claude Code Review writes inline comments on diff lines and a check run. PR Lens writes one top-level comment, identified by a hidden HTML marker so it only ever adopts its own, and rewrites that same comment on every push. An older analysis that finishes last is discarded rather than posted.

The order I read them in: the diagram first, to learn the shape of the change, then the findings, which now have somewhere to sit. A comment about a tenant-scoped query means more once you have seen which worker reaches that store and what else writes to it.

Which one to turn on first

If your problem is that agent-written code is landing with bugs nobody caught, turn on the finder. That is what it is for, and Claude Code Review is a good one.

If your problem is that pull requests sit unread because nobody wants to start a 400-line diff on a Friday, a finder will not fix it. Reviewers stall because opening the pull request means rebuilding a model of the system from scratch, and a list of suspicious lines arrives after that work is already done. That rebuilding cost is what a drawing removes, and it is the reason we built PR Lens rather than another finder. The taxonomy behind that split is in AI code review tools grouped by what they actually do, and if the pull requests in question come out of Claude Code sessions, how to review Claude Code pull requests is the specific version.

Most teams I talk to end up with one of each, which is roughly where we landed ourselves: a finder watching for correctness, a drawing carrying the shape, and the review starting from the second one.