Most "AI code review tools" lists are written by the people selling the tools. This one has the same catch – we make an open-source reviewer called Scopy, so I'm not going to pretend I'm neutral. What I can do is walk you through the open-source side of this market honestly, competitors included, since it's small enough to actually cover in one post.
So here's what open source really buys you in a code reviewer, which tools are worth a look, and a few questions that matter more than any feature list.
Why open source matters more here than for most tools
For a lot of software, open source is a nice bonus. For a code reviewer it changes a few things that actually affect your decision here.
The first is where your code goes. A reviewer reads every pull request you open, which is about as private as your codebase gets. With a closed cloud tool you're taking the vendor's word for what happens to that code once it leaves your machine. With an open one you can read the pipeline yourself, and if you self-host it, the code never leaves your infrastructure at all. We got into that trade-off in self-hosted vs cloud AI code review.
The second is that you can see how the review works. Every tool here says it's accurate. With a closed one that's a claim you either believe or you don't. With an open one you can look at what context it pulls, what it asks the model and what it does with the answer before it comments on your PR. That won't guarantee the reviews are good, but at least you can check.
The third is lock-in, or the lack of it. Model prices move, companies get bought and free tiers have a way of quietly growing a paywall. When the tool is open source and you bring your own model key, walking away is an afternoon of work rather than a migration project you are now forced to take.
The tools worth knowing
Scopy
Scopy runs as either a hosted app or on your own servers. What we've put most of our effort into is not commenting unless we're fairly sure. Before Scopy leaves a finding it reads the code around the change, not only the diff and then double-checks its own candidate issues before posting them. The reasoning is simple enough: a reviewer that drops ten nitpicks on every PR gets muted inside a week, and a muted reviewer catches nothing because it's not read.
PR-Agent (Qodo Merge)
PR-Agent, from Qodo (formerly CodiumAI), is the open-source reviewer many people have heard of. You can self-host it with your own model keys, and it does more than review – PR descriptions, code suggestions, changelogs. The paid Qodo Merge adds hosting and support for GitLab, Bitbucket and Azure DevOps on top of GitHub.
Kodus
Kodus (the reviewer is called Kody) is built around model choice. It's open source, self-hostable, and it'll run against Claude, GPT, Gemini, Llama, or anything with an OpenAI-compatible endpoint, local models included. If your main worry is "we want to pick the model and swap it whenever" that's the whole idea here.
Open Code Review (Alibaba)
Open Code Review started as Alibaba's internal review tool. The interesting part is the architecture: deterministic analysis pipelines plus an agent, with tuned rules for specific bug classes like null-pointer errors and SQL injection. It's a CLI, so it integrates into CI easily, but there's no dashboard or GitHub App to lean on. Good fit if you're a platform team that wants to build the workflow yourself.
SonarQube Community Edition
Not an AI tool, but worth a mention because plenty of teams already run it. SonarQube is rule-based static analysis: thousands of hand-written rules across dozens of languages, and almost no false positives inside the areas it covers. It'll catch the bug classes its rules describe and nothing outside them, which makes it a good companion to an LLM reviewer. More on that split in AI code review vs static analysis.
What about CodeRabbit and Greptile?
CodeRabbit and Greptile are the two biggest names, and both are closed-source cloud products. Nothing wrong with that, they're popular for good reasons, but it puts them outside this post. If open source or self-hosting is a hard requirement for you, they're already off your list, which is usually how someone ends up reading a page like this...
How to actually pick one
Feature tables will mostly waste your time. Let's try answerting these:
Does your code have to stay on your own infrastructure? If yes, you're down to the self-hostable tools above, and the follow-up is which one you can realistically run. If no, the hosted versions save you the ops work so you can ship your product and not the infra for it.
Does it look past the diff? This is where review quality is won or lost. A lot of bugs only make sense once you see the caller, the type or the config default sitting in some other file. A reviewer that reads only the patch will miss them and sound confident doing it. We wrote up real examples in why diff-only code review misses bugs.
What happens between the model and your PR? Ask whether findings get checked or filtered before they're posted, or whether you're reading the model's first draft. That's usually what separates a bot people act on from one people scroll past.
Can you teach it your rules, and how painful is it? Every team has standards no general model knows about. Check that custom rules exist and that writing one doesn't mean learning a new mini-language.
What does it cost at your PR volume? Bring-your-own-key tools mean you pay the model provider directly, which tends to be cheaper as you scale but puts cost-watching on you. Hosted tools roll it into a subscription. Do the calculations for your own numbers.
Try it on your real PRs
Whatever makes your shortlist, don't judge it on a demo repo. Point it at a couple of weeks of your actual pull requests and count two things: bugs it caught that people missed, and comments nobody acted on. It will tell you more than any post, this one included.
If you want to see where Scopy lands, the quickstart is about five minutes, and the self-hosting guide covers the run-it-yourself route.