Open Code Review: Alibaba's open source AI code reviewer, explained in depth

Open Code Review (the command is ocr) is a command line tool that reviews your Git changes with a language model and returns comments pinned to exact lines, the way a colleague would on a pull request. It started as Alibaba's internal code review assistant and, according to the repository, served tens of thousands of developers for two years before being open sourced under the Apache-2.0 license.

In this five-part guide we installed and tested it thoroughly (v1.13.2, released October 20, 2026) on a sample API with planted bugs. This first part covers what it is, how it works inside, what its benchmark says and when it makes sense over simply asking Claude Code for a review.

What Open Code Review is and what problem it solves

The core idea is simple: if you ask a general-purpose agent to "review this diff", the result depends too much on the prompt and the model's mood. The Open Code Review README lists three failures anyone who has tried will recognize:

• Incomplete coverage. On large changesets the agent cuts corners and reviews only some files.
• Position drift. The comment says "line 42" and the issue is on line 57, or in another file.
• Unstable quality. A natural-language skill is hard to debug, and small prompt changes swing the result.

Its answer is to combine deterministic engineering (plain code that does not make mistakes) with an LLM agent only where judgement is needed. Which files get reviewed, which rules apply to each one and which line each comment lands on is decided by Go code; what is wrong with that code is decided by the model.

On the license: this blog usually covers MIT projects. Apache-2.0 is just as permissive for company or client work (commercial use, modification and redistribution allowed); it adds an explicit patent grant and asks you to keep the copyright notice and NOTICE file if you redistribute a modified version.

How it works inside: the review pipeline

The repo's architecture docs describe in detail what happens when you run ocr review. We summarized it in this diagram:

1. The diff

ocr gets the changes from Git in one of three modes:

2. The file filter

Before spending a single token, every file goes through a series of gates. Binaries are dropped, as are secret paths (.env, .ssh/, id_rsa, .npmrc, .pypirc…), tests (*.test.ts, *_test.go, test_*.py…), generated code (*.pb.go, *.generated.*), dependencies and build output (node_modules, vendor, dist, target, .next…) and extensions outside its supported list. You will see it in action in part 2 with ocr review --preview.

The secret exclusion is worth noting: it runs before your own rules and cannot be overridden with include. If someone commits a .env by mistake, its content never reaches the LLM.

3. Per-file rules

Each file gets its own review checklist. There are system rules for more than 40 file types (Java, Go, TypeScript, Python, PHP, Rust, MyBatis SQL, package.json, GitHub Actions workflows, Terraform, Solidity…) and you can add or replace your own per project. That is the topic of part 3.

4. Semantic grouping

A single LLM call that only sees metadata (path, status and added or deleted lines, never the code) groups related files: a handler with its service, or messages_en.properties with messages_es.properties. Each group holds at most 10 files. If that call fails, it falls back to one file per group.

5. Parallel sub-agents

Each group is reviewed by a sub-agent with its own isolated context, 8 at a time by default (--concurrency). When the change is large (one file with 50+ changed lines, or a group adding up to 100), it first runs a plan phase that produces a checklist. Then it enters a loop of up to 100 rounds with six tools: read files, read another file's diff, search the code, find files, emit a comment (code_comment) and finish (task_done).

--effort sets how many passes it makes: low = 1, medium = 2 (default) and high = 3. Each pass receives the findings already confirmed so it looks for new ones.

6, 7 and 8. Positioning, filtering and output

Every comment includes the exact code snippet it refers to (existing_code). A sliding-window algorithm finds it in the diff to compute start_line and end_line; if that fails, an extra call tries to re-anchor it. Finally another LLM call (REVIEW_FILTER_TASK) checks every comment and drops the ones that are provably wrong. The result comes out as text, JSON or SARIF and is saved as a session in ~/.opencodereview/sessions/.

The benchmark: precision over recall

Alibaba publishes its own benchmark, AACR-Bench: 200 real pull requests from 50 popular repositories in 10 languages, with 1,505 issues annotated and cross-checked by more than 80 engineers. The dataset is on Hugging Face.

The most striking numbers, same model with and without Open Code Review:

How to read it:

• Precision = of what it reports, how much is a real defect. Open Code Review with Claude 4.6 Opus is right about one comment in three; plain Claude Code, one in fourteen. Less noise to triage.
• Recall = of the real defects, how many it finds. Here Claude Code wins (28.9% vs 20%). The project calls this a deliberate trade-off: it would rather stay quiet than add noise. Its roadmap includes an "Ultra Mode" for more recall at a higher token cost.
• Cost: around 15 times fewer tokens in that comparison (385K vs 5,664K); the README says "~1/9" on average.

Two honest caveats: the benchmark was designed and run by the same team that builds the tool, and absolute numbers are low for everyone (nobody passes 26% F1). Automated review is still a first pass, not a replacement for human review.

What ships besides the CLI

• ocr scan: reviews whole files instead of a diff. Useful for auditing an inherited repo or a folder with no history.
• Delegation mode (ocr delegate): ocr does the deterministic part and your agent (Claude Code, Codex, Cursor…) does the review on its own subscription, no API key. We test it in part 4.
• Plugins and skills for Claude Code, Codex, Cursor, Kimi Code and OpenCode, plus a VS Code extension.
• CI/CD: a reusable GitHub Action and examples for GitLab CI, Gerrit, Bitbucket Pipelines, GitFlic and Codeup. Covered in part 5.
• Web session viewer (ocr viewer): replays every review call by call so you can see why the model said what it said, and compares two sessions (new, persisting and resolved findings).
• MCP client: give the reviewer external tools, such as looking up the Jira ticket or your internal docs.
• OpenTelemetry: tokens, requests and latency per model, never exporting prompt content.

When to use Open Code Review (and when not)

It fits well if:

• You want a low-noise automatic first review on every PR with predictable cost.
• Your team has house rules (security, money in cents, transactions) that must be applied every time, file by file.
• You already pay for Claude Code, Codex or Cursor and want a more rigorous review without another API key (delegation mode).
• You deal with large PRs, where general agents skip files.

It is not for you if:

• You want it to fix the code on its own: the roadmap rules that out explicitly. It suggests changes, but applying fixes always requires human approval (the Claude Code plugins can apply them because your agent does the editing there).
• You need maximum recall on critical code: today it favors precision.
• You cannot send code to an external provider and have no local model with real tool calling (Ollama works, but the model must support native tool calls; deepseek-r1, for instance, does not).

FAQ

Is Open Code Review free? The tool is (Apache-2.0). You pay for the model: your Anthropic, OpenAI or DeepSeek API key, or your agent subscription in delegation mode. With a local Ollama model it costs nothing.

Does it send my code to Alibaba? No. It sends diffs (and the snippets the agent reads) to the LLM endpoint you configure. Sessions and rules stay on your machine in ~/.opencodereview/.

How is it different from CodeRabbit or Copilot code review? Those are managed services. Open Code Review is a CLI you run yourself, locally or in your CI, with the model you choose, and its selection and rule logic is open source you can audit.

Does it work for any language? It ships specific rules for over 40 file types and a generic rule for everything else. Files with extensions outside the supported list are excluded unless you force them with include.

Does it run on Windows? Yes: there are Windows binaries (amd64 and arm64), a PowerShell installer and the npm package.

Conclusion

Open Code Review is the closest thing to an "industrial" open source AI code reviewer: it takes what agents do badly in reviews (skipping files, inventing line numbers, noise) and replaces it with deterministic code. The trade-off is that it finds somewhat less than a free-roaming agent, but what it finds is usually real.

In the next part we install it, configure a provider and run the first review: how to install and use Open Code Review.