alibaba/open-code-review

Open Code Review is worth a look if you already pay for a model API and want structured, repeatable review output rather than a free-form agent chat. Its pitch is precision and token economy, not maximum recall, so calibrate expectations before wiring it into a workflow.

The problem

A developer finishing a branch usually wants two things: a second pass over the diff that catches defects, and findings placed at the exact lines a reviewer can act on. Asking a general-purpose coding agent to do this works for small changes, but on larger changesets the agent may sample only part of the diff, and its location references can drift from the actual code. The result is a review that looks thorough but quietly skips files. Open Code Review changes the division of labour: engineering logic decides which files enter the review and where comments attach, while the model supplies the judgement about what is wrong. The output is a line-level report you can read, or JSON you can feed to another tool.

What's different

The design is a hybrid. Deterministic steps handle the parts that must not go wrong — selecting and filtering files, generating diffs, anchoring comments to lines — and the agent handles interpretation. Debugging a fixed pipeline plus a narrow model call is more tractable than tuning a long natural-language skill, which is the author's stated reason for splitting the work this way.

The README's own benchmark claims a precision/F1 advantage over Claude Code with the same underlying model at roughly one-ninth the tokens, while explicitly conceding lower recall as a deliberate trade-off project README. Treat that as the vendor's measurement, not an independent result. Independent evidence is thinner: a commenter ran an early version against 10 of the 50 PRs from a public benchmark and reported good recall (~74%) but poor precision (~12%), with F1 around 20% early benchmark report. A maintainer replied that a faulty tool call in that version caused the false positives and had since been fixed maintainer reply. Without a fresh independent rerun, the question of real-world false-positive rate remains open — and that is the metric that decides whether reviewers keep the tool switched on.

Who should try it

Good fit: teams that want code review as a scriptable step — a branch-range review in CI, a JSON report consumed by another agent, or a full-file scan of a legacy directory where there is no useful diff. The workspace, branch-range, single-commit and scan modes cover those cases, and resume sessions exist for long reviews. Poor fit: anyone hoping for a drop-in replacement for human review or for a tool that finds everything. The documented lower recall means you should not read a clean report as proof the change is sound, and a solo developer without an API key or a delegation setup has no path to a first review. If you already have an agent subscribing to a model, compare the token bill and output format against simply prompting that agent.

Requirements and limitations

Git 2.41 or newer is required because diffs, code search and repository operations rely on it. You also need a configured LLM provider unless you use delegation mode, so the running cost is model usage, not the CLI itself. Installation is available through npm, an install script, a GitHub release binary, or from source; see the installation docs and configuration docs for provider setup, including OpenAI- and Anthropic-compatible endpoints.

Ongoing upkeep matters more than first install. Review quality depends on the model you point it at and on the built-in rule set covering issues like NPE, thread-safety, XSS and SQL injection; when those rules or prompts change, re-check the output rather than assuming stability. The precision-over-recall choice also means tuning thresholds or rules is a continuing task, not a one-time setting.

HotRepo's take

HotRepo has tracked 18 daily-board appearances between 2026-07-27 and 2026-10-27, with the last three recorded board days averaging +256 stars/day against +2,906/day in the three before — recorded board days only, not a continuous series. The trajectory is fading, but that says little about review quality. The concrete thing to verify before adopting is the false-positive rate on your own repository after the fixes the maintainer described, since precision is what determines whether developers keep the tool enabled.