Alibaba's code reviewer doubles Claude Code's score on the same model

27 minutes ago

Same model, same two hundred pull requests. Run through Claude Code, it scores 11.6. Run through Open Code Review, it scores 25.1, on a fifteenth of the tokens. This is Alibaba's code review tool, the one that reviewed code for tens of thousands of developers inside Alibaba for two years before they open sourced it in May. It is written in Go, Apache licensed, and it runs on every desktop.

Ask

Ask about this presentation

Answers are generated from this presentation.

Chapters

  1. 0:00Open Code Review · doubles Claude Code's score on the same model
  2. 0:29What you will know by the end
  3. 0:45You point it at a diff and get comments pinned to lines
  4. 1:11Three ways a general agent gets a review wrong
  5. 1:40The model gets the wheel in two places
  6. 2:06Five gates before a token is spent
  7. 2:31Related files are reviewed in one conversation
  8. 3:03Each sub-agent plans, loops, and goes around again
  9. 3:35Position is computed, so it does not drift
  10. 4:03Fifty-two file types arrive with a rulebook
  11. 4:37The benchmark behind the number
  12. 5:06What the 25 hides: Claude Code finds more of the real defects
  13. 5:37Claude Code has a review command. CodeRabbit posts on every PR.
  14. 6:12The catch, from the FAQ
  15. 6:47One in five defects, and one in three comments is real
  16. 7:14Where it sits among the other reviewers
  17. 7:42Should you install it
  18. 8:12One line installs it · v1.12.1
  19. 8:36Doubles the score by filing a third of the comments
Show transcript

Open Code Review · doubles Claude Code's score on the same model

Open Code Review

Alibaba's code reviewer doubles Claude Code's score on the same model
GoApache 2.0macOS, Linux, Windows

Same model, same two hundred pull requests. Run through Claude Code, it scores 11.6. Run through Open Code Review, it scores 25.1, on a fifteenth of the tokens. This is Alibaba's code review tool, the one that reviewed code for tens of thousands of developers inside Alibaba for two years before they open sourced it in May. It is written in Go, Apache licensed, and it runs on every desktop.

What you will know by the end

By the end you will know how a pipeline with hard-coded gates gets that score out of the same model, why Claude Code still finds more of the real defects, and whether this belongs in your pull request pipeline this week.
and where I would not use it

By the end of this, you'll know how a pipeline with hard-coded gates gets that score out of the same model, why Claude Code still finds more of the real defects, and whether you should put this in your pull request pipeline this week. I'll also say where I would not use it.

You point it at a diff and get comments pinned to lines

ocr review # staged, unstaged, untracked
ocr review --from main --to feature # a branch since it left main
ocr review --commit abc123 # one commit
ocr review --format json --output result.json
every comment carries a file, a start and end line, the existing code, and a suggestion

Here's what it does. You point ocr at a diff: everything you have changed, one commit, or a branch against main. It reads the changes, sends them to whichever model you configured, and hands back comments. Each one is pinned to a file and a line range, and carries the existing code and a suggestion. Ask for JSON and it writes a file your own tooling can read.

Three ways a general agent gets a review wrong

Three ways a general coding agent gets a review wrong

it cuts corners
on a large change it reviews some files and skips the rest
the position drifts
a real finding points at the wrong line or the wrong file
the quality swings
a small prompt change moves the whole result

If you've asked a general coding agent to review a pull request, you know the three ways it goes wrong. On a large change it cuts corners and skips files. The line numbers drift, so a real finding points at the wrong place. And a small change to the prompt swings the whole result. Alibaba's diagnosis is that a purely language-driven reviewer has no hard constraints, so they built the constraints in code and left the model two jobs.

The model gets the wheel in two places

The model gets the wheel in two places. Go code drives the rest.

load the diffgit, in Go five gateswhich files, which rule group filesone model call one sub-agent per groupplan, loop, roundsup to 8 in parallel pin every commentto its lines, in Go text or JSON
deterministic, in Gothe model

The whole thing is a pipeline, and the model only gets the wheel in two places. Go code loads the diff from git, decides which files are reviewable, and picks a rulebook per file. Then one model call groups related files. Each group gets its own sub-agent with its own context, up to eight running in parallel. And Go code, not the model, pins every comment back to its lines before anything is written out.

Five gates before a token is spent

Every changed file passes five gates before a token is spent

1
binary files drop first
2
your exclude list wins
3
a file on your include list is kept, whatever follows
4
an extension allowlist
5
built-in test-file patterns
ocr review --preview
lists every file with the reason it was kept or dropped, and calls no model

Every changed file passes five gates before a token is spent. Binary files drop first. Your own exclude list wins next. A file on your include list is kept no matter what follows. Then an extension allowlist, then a built-in list of test file patterns. And you can run the preview and see the verdict for every file, with the reason, without calling a model at all. I like that a lot.

Related files are reviewed in one conversation

Related files are reviewed together, and the grouping is allowed to fail

one model call sees file paths and line counts, never the code
ten files a group at most
over the token budget, back to one file per group
a bad answer, and every file gets its own group

Then the files get grouped, so a handler, its service and its test are reviewed in one conversation. That grouping is one model call, and it only sees file paths and line counts, never the code. Three guards keep it sane. Ten files a group at most. A group that would blow the token budget splits back to single files. And if the model's answer is garbage, every file gets its own group. The grouping can fail. The review cannot.

Each sub-agent plans, loops, and goes around again

Each sub-agent plans, loops up to a hundred tool calls, and goes around again

plan if a file changed 50+ lines, or a group 100+
read-only tools, returns a checklist
loop up to 100 tool calls
code_search · file_read · file_read_diff
file_find · code_comment · task_done
rounds effort low 1 · medium 2 · high 3
confirmed findings pinned, plan dropped
the plan phase is skipped for small changes, so it costs nothing there
rounds stop early when one adds nothing new, or the token budget runs out

Each group's sub-agent runs a loop. If any file changed fifty lines or more, or the group changed a hundred, it plans first with read-only tools, and that plan becomes a checklist. Small changes skip the plan. Then the main loop runs, up to a hundred tool calls: search the code, read a file, file a comment. And it goes around again with the confirmed findings pinned, one to three rounds depending on the effort you set, stopping early when a round finds nothing new.

Position is computed, so it does not drift

a comment quotes the existing code, and Go slides that quote across the diff to find the exact lines
no match, and one more model call re-anchors it
a filter pass drops comments it can prove wrong
a second line pass runs over the whole set

This is the part that fixes position drift. A comment quotes the existing code, and Go code slides that quote across the diff to find the exact lines. If it can't match, one more model call re-anchors it. Then a filter pass reads every comment against the diff and throws out the ones it can prove wrong, and a second line pass runs over the whole set. The position is computed, so it does not drift.

Fifty-two file types arrive with a rulebook

Fifty-two file types arrive with a rulebook, and half of each rule says when to stay quiet

52
built-in rulebooks: Java, Go, Python, TypeScript, Rust, Swift, Terraform, Solidity, SQL mappers, GitHub workflows
Thread safety, flag only:
a check-then-act race
a non-atomic compound operation
unsafe lazy initialization
writes to a HashMap from several threads
Do not report:
local variables · read-only use
immutable objects · code already synchronized

Each file also arrives with a rulebook for its type, and there are fifty-two of them, from Java and Go to Terraform and Solidity. The Java one tells the model when to flag a thread safety issue: a check-then-act race, an unsafe lazy singleton, a HashMap written from several threads. And it says when to stay quiet: local variables, read-only access, code that is already synchronized. The do-not-report list is half the rule. That is where the precision comes from.

The benchmark behind the number

Alibaba's benchmark: real pull requests, defects marked by eighty senior engineers

50
open source repos
200
real pull requests
10
languages
1,505
annotated defects
top row: Open Code Review driving Claude Opus 4.6, F1 25.1, on 385K tokens a review
Alibaba’s own benchmark, AACR-Bench, published on Hugging Face

Now the number from the title. Alibaba built a benchmark from fifty open source repos, two hundred real pull requests in ten languages, with 1,505 defects annotated by more than eighty senior engineers. The dataset is public on Hugging Face. The top row of their table is Open Code Review driving Claude Opus 4.6: an F1 of 25.1, on 385 thousand tokens a review.

What the 25 hides: Claude Code finds more of the real defects

Open Code Review
v1.3.1, Claude Opus 4.6
25.1
F1
33.9%
precision · 301 of 889 comments
20.0%
recall · 301 of 1,505 defects
385K
tokens a review
Claude Code
v2.1.169, Claude Opus 4.6
11.6
F1
7.2%
precision · 435 of 5,980 comments
28.9%
recall · 435 of 1,505 defects
5,664K
tokens a review
the score measures signal, and this tool buys signal by staying quiet
Alibaba’s benchmark table, both rows on Claude Opus 4.6 over the same 200 pull requests

Same model, through Claude Code: 11.6. So what does the 25 hide? Recall. Open Code Review finds one in five of the real defects. Claude Code finds 28.9 percent, more of them. It also files nearly six thousand comments to get there, and one in fourteen is right. Open Code Review files 889, and one in three is right, on a fifteenth of the tokens. The score measures signal, and this tool buys signal by staying quiet.

Claude Code has a review command. CodeRabbit posts on every PR.

Claude Code has a review command and CodeRabbit posts on every pull request. What is left?

a file filter you can preview for free
a token guard that skips a monster diff before the request is sent
a JSON envelope your own pipeline owns end to end
the table compares v1.3.1 with a Claude Code from June. Today the tool is at v1.12.1 and Claude Code at 2.1.272, and the table has not been rerun.

The obvious pushback: Claude Code already has a review command, and CodeRabbit will comment on every pull request for a subscription. True. What those don't give you is a filter you can preview for free, a guard that skips a monster diff before the request is sent, and a JSON envelope you own end to end. One caveat cuts the other way. That benchmark ran version 1.3.1 against a Claude Code from June. The tool is at 1.12.1 today and Claude Code is at 2.1.272, and the table has not been rerun.

The catch, from the FAQ

The catch, straight from the FAQ

the model must make native tool calls. One that writes them out as text loops and returns zero comments.
Git 2.41 or newer
a paraphrased quote lands the comment at line 0, and you find the spot yourself
a finding in a file outside the group is off limits

Here's the catch, and it is in the FAQ. The model has to make real tool calls. A model that writes them out as text, the way some reasoning models do, loops and returns zero comments. You need Git 2.41 or newer. When the model paraphrases a quote instead of copying it, the comment lands at line zero and you find the spot yourself. And a finding in a file outside the group is off limits, so a bug that spans two groups can go unreported. That is the recall number, explained.

One in five defects, and one in three comments is real

One in five defects found, and one in three comments is real. That is a review you read, not one you scroll past.
385K tokens a review, on your own key, with the model you already pay for

So how do you read one in five? Not as a scanner. A security scanner is judged on recall. This is judged on your attention: every third comment is a real defect, which means you read them, instead of scrolling past forty false alarms to find one. And at 385 thousand tokens, that is a review you can afford on every pull request, on your own key, with whichever model you already pay for.

Where it sits among the other reviewers

Where it sits

Qodo's PR-Agent
open source, lives in the pull request
CodeRabbit
hosted, a subscription
Claude Code's review
inside the agent you already run
Copilot code review
inside GitHub
Open Code Review is the deterministic pipeline you run yourself, with a rulebook per file type, and twenty thousand active users inside Alibaba by its own count

Where does it sit? Qodo's PR-Agent is the open source one that lives in the pull request. CodeRabbit is the hosted one. Claude Code and Copilot each ship a review of their own. Open Code Review is the one that is a deterministic pipeline you run yourself, with a rulebook per file type, and a track record: twenty thousand active users inside Alibaba, by their own count.

Should you install it

Should you install it? Depends which of these is you.

a team with a pull request pipeline and a model key
yes, this week. The GitHub Action posts findings on the reviewed commit.
solo, on Claude Code or Cursor
install the skill and use delegation mode: your agent runs the review with its own model, no second key
you need recall: an audit, a security pass
run it beside your scanner, not instead of it

Should you install it? Depends which of these is you. If you're on a team with a pull request pipeline and a model key, yes, this week. The GitHub Action posts the findings on the reviewed commit. If you're solo on Claude Code or Cursor, install the skill and use delegation mode. Your agent runs the review with its own model, and you need no second key. If what you need is recall, an audit, a security pass, I'd run it beside your scanner and not instead of it.

One line installs it · v1.12.1

One line installs it, and the version today is 1.12.1

npm install -g @alibaba-group/open-code-review
1.12.1
Apache 2.0
125 releases since May 21
macOS, Linux, Windows
plugins: Claude Code, Codex, Cursor, OpenCode

One line installs it from npm, and the command is ocr. Version 1.12.1 shipped today. That is 125 releases since May 21, about one a day. The licence is Apache 2.0, so it is fine at work. Plugins for Claude Code, Codex, Cursor and OpenCode ship in the repo.

Doubles the score by filing a third of the comments

Open Code Review doubles Claude Code's score on the same model by filing a third of the comments
github.com/alibaba/open-code-review
Go · Apache 2.0 · 1.12.1

So: a pipeline with hard gates, a model that only gets the wheel twice, and a score that comes from staying quiet. Are you running this on your own key, or handing the review to your coding agent? Tell me which, and what it caught. That is alibaba slash open dash code dash review, on GitHub. New repo tomorrow.