Alibaba's open-code-review, Explained

Alibaba open-code-review is the code review system Alibaba ran internally for two years, released to the public in May 2026 under Apache-2.0. It's a Go CLI called ocr that reads your git diff, sends changed files to an LLM you configure, and writes line-level comments. The software costs nothing. The inference does, unless you route it through a coding agent you already pay for.

It reached 16,243 stars and 1,095 forks by July 30, 2026, which for an enterprise-origin release is fast.

Key Takeaways:

• Apache-2.0, no seat limits, no vendor account. You supply a model endpoint or delegate the review to your existing agent.
• The architecture is deliberately split: engineering code decides what gets reviewed, the model decides what's wrong with it.
• Alibaba's published benchmark reports higher precision and F1 than a general agent on the same model, at roughly 1/9 of the tokens, with lower recall as an explicit trade.
• Delegation mode needs no API key at all, which is the cheapest way to try it.
• Prerequisite worth checking before you start: Git 2.41 or newer.

---

What Alibaba released

The project is alibaba/open-code-review, Apache-2.0 licensed, created May 18, 2026, written in Go, with an official site and docs. The README's account of its origin: it was Alibaba Group's internal code review assistant, served tens of thousands of developers over roughly two years, and flagged millions of defects before being opened up. Those are the company's own figures and there's no external audit of them, but the shape of the tool backs the story. Nobody designs bundle-level context isolation and a separate comment-positioning module for a weekend project.

"Free and unlimited" needs one qualification. The tool imposes no quota, no seat count and no license fee, and it's genuinely unrestricted in that sense. But it is not free to run in the default mode, because you configure a provider and pay that provider per token. The exception is delegation mode, where ocr does file selection and rule resolution and hands the actual review to your coding agent's model, so the cost lands on a subscription you already have. If you're evaluating it, start there.

It carries an OpenSSF Best Practices Silver badge, ships on Windows, macOS and Linux, distributes through npm, and publishes READMEs in English, Chinese, Japanese, Korean and Russian.

---

The hybrid architecture: rules plus LLM

The README opens with a complaint about general-purpose agents doing review, and it's specific enough to be worth quoting the substance of. Three failures: on large changesets agents cut corners and silently review only some files; reported issues drift off their actual line numbers; and quality swings with small prompt changes, which makes the whole thing undebuggable. Their diagnosis is that a purely language-driven pipeline has no hard constraints.

So the deterministic half handles everything that must not go wrong:

• File selection is computed, not decided by a model, so nothing important gets skipped.
• File bundling groups related files into one review unit. Their example is message_en.properties and message_zh.properties reviewed together. Each bundle runs as a sub-agent with isolated context, which is why it stays stable on very large diffs and parallelizes naturally.
• Rule matching runs through a template engine rather than natural-language instructions, matching rules to file characteristics so the model sees a short relevant ruleset instead of everything.
• Positioning and reflection are separate modules that check where a comment lands and whether it holds up, after the model has produced it.

The model half is left with the parts models are good at: deciding what to look at next, pulling in context from other files, and judging whether a pattern is actually a bug.

The trade this buys is visible in their benchmark, built from 50 open-source repos, 200 real pull requests and 10 languages, with 1,505 ground-truth issues annotated and cross-validated by more than 80 senior engineers. Against a general agent on the same underlying model, they report higher precision and F1, roughly a ninth of the token spend, and faster wall-clock reviews. Recall is lower, and they say so directly: fewer false alarms, at the cost of letting more real issues through. Whether that's the right trade depends entirely on whether your team currently ignores review bots because of noise.

---

Running it yourself

There's no server to deploy. It's a CLI.

npm install -g @alibaba-group/open-code-review

Then point it at a model:

ocr config provider    # pick a built-in provider or add a custom endpoint
ocr config model       # pick a model, connectivity gets tested automatically

Both are interactive, and the provider step covers OpenAI-compatible and Anthropic-compatible endpoints, so a local or self-hosted model works the same as a hosted one. Reviewing:

ocr review                                    # staged, unstaged and untracked changes
ocr review --from main --to feature-branch    # branch range
ocr review --commit abc123                    # one commit
ocr scan --path internal/agent                # whole files, no diff needed

A real run against a 17-line file with a deliberate null dereference returns one comment anchored to src/user.js:4-4, tagged [bug · high], and reports its own cost on the way out: 1 file reviewed, 1 comment, roughly 4,632 tokens split 3,455 in and 1,177 out. It also prints Skipping plan phase for src/user.js (17 lines < threshold 50), which is the deterministic half deciding a file is too small to plan over before the model ever sees it.

ocr scan is the one people miss. It reviews entire files rather than a diff, which makes it the tool for auditing a codebase you inherited and where a diff tells you nothing. Long reviews checkpoint: ocr session list then --resume <session-id> picks up an interrupted range.

For delegation:

ocr delegate preview
ocr delegate rule src/main.go src/handler.go

Beyond the CLI there are plugins for Claude Code, Codex, Cursor and OpenCode, a portable agent skill for other skill-compatible agents, an MCP server for extending the review agent with external tools, CI recipes for GitHub Actions, GitLab CI, GitFlic CI and Gerrit, a session viewer for replaying reviews in the browser, and OpenTelemetry export.

Requirements are thin: Git 2.41 or newer, because the tool leans on git for diff generation, code search and repository operations. That version floor is the one thing likely to bite on an older build box.

---

How it sits against CodeRabbit and Greptile

Different shape of product, not a different tier of the same one. CodeRabbit and Greptile are hosted services: you install a GitHub or GitLab app, it comments on pull requests, and you pay per seat while the vendor runs the models and holds your code on their infrastructure. open-code-review is a binary on your machine or your CI runner, with your key and your endpoint, and nothing leaves the path you configure.

That makes the comparison mostly about where your code goes and who operates the thing. The hosted products give you a PR bot that works the day you install it, with review history and dashboards nobody has to maintain. open-code-review gives you the same review inside your own boundary, and hands you the operational cost in exchange. For a team that already rejected hosted review bots on data-residency grounds, that's not a feature comparison, it's the only option in the category.

---

Who should actually use this

Teams reviewing in a jurisdiction or on a codebase where sending diffs to a third-party SaaS is off the table. Teams that already pay for Claude Code or Codex seats and want review to use that budget rather than a new one. And anyone who tried a review bot, drowned in nitpicks, and turned it off, because a tool that explicitly optimizes for precision over recall is aimed squarely at that experience.

It's a weaker fit if you want zero setup, dashboards, or a per-PR bot without a CI story. What it does share with the rest of the current agent tooling, including hosted runtimes like MoClaw, is the direction of travel: bounded jobs with checkable output beat open-ended ones, and the engineering that makes them reliable sits outside the model. The repository tags itself harness for the same reason, which is a small piece of evidence for how far that word has spread.

FAQ

Is open-code-review really free?

The software is, under Apache-2.0, with no seat or usage limits and no account required. Running it isn't free by default, because reviews consume tokens from whatever provider you configure and you pay that bill. Delegation mode is the exception: ocr handles file selection and rules while your coding agent performs the review with its own model, so no separate API key or spend is involved.

Does it support GitHub and GitLab?

Through CI rather than as a hosted app. The docs cover GitHub Actions, GitLab CI, GitFlic CI and Gerrit, so you wire it into your pipeline and it posts results from there. Locally it works against any git repository regardless of host, since it operates on the repo rather than the forge's API.

Which models does it run on?

Any OpenAI-compatible or Anthropic-compatible endpoint. ocr config provider offers built-in providers and accepts a custom endpoint, which covers self-hosted and open-weight models as well as hosted ones. The benchmark comparison holds the model constant and varies only the review architecture, so the published precision gain isn't tied to one vendor's model.

How is it different from just asking Claude Code to review my PR?

That comparison is the benchmark. Same model, two architectures: the general agent decides for itself which files to read, and on large changesets it skips some. open-code-review computes file selection in code, bundles related files into isolated sub-agent contexts, matches rules with a template engine, and runs comments through separate positioning and reflection passes. The reported result is higher precision and F1 at about a ninth of the tokens, with lower recall.

Can it review a repository with no recent commits?

Yes, that's what ocr scan is for. It reviews whole files rather than a diff, either across the repository or scoped with --path, which makes it usable for auditing an unfamiliar codebase where there's no meaningful change to inspect.