orangu refuses to turn a truncated code review into a pass
A model reviews a file, exhausts its output allowance, and never reaches a verdict. A loose review pipeline may still build a pleasant summary from the fragments it received. Orangu leaves the file unreviewed. Its patch verdict comes from file statuses, so the absent result blocks approval.
Running code review locally can keep source and prompts on the developer's machine, but privacy does not tell us whether the model found the bug or finished speaking. Incomplete work needs to remain visible in the review record.
orangu is an open-source local coding environment made of three Rust programs: a terminal client, an optional model coordinator, and a native GGUF inference server. Its product site lists version 1.2.0 on August 24, 2026. The GPLv3 project can work offline after the models are downloaded, and its components communicate through OpenAI-compatible endpoints.
Inside /auto_review, the project gives the model a bounded task, retains explicit failure, and calculates the final status outside the model's prose. That is the part other review harnesses should study.
Each check gets its own request
The auto-review documentation defines checks for Code, Security, Memory, Performance, Test Suite, and Documentation, with a separate Overall section. Orangu sends one request per enabled category, attaching the complete file and its diff. Each category may report up to five short findings.
The requests run as scratch exchanges. They have no tool definitions and never enter the user's chat history. Output is capped at 512 tokens by default, though the limit can be increased or disabled. When the project uses orangu-server, requests for a file share a slot, allowing the server to reuse that file and diff from its KV cache.
These constraints suit local models with limited memory or slow generation. A security review cannot drift into shell activity, while an independent documentation review does not inherit another category's conclusion. The cap also makes runtime more predictable.
It can be too tight. Thinking tokens may consume much of a 512-token allowance before the answer is complete. The documentation suggests raising the cap, for example to 2048, for deeper reviews. Bounding a response controls resources. It cannot make the response complete.
A blank result cannot approve a file
Every category response must contain a verdict or findings. When the request fails, or truncation leaves neither, orangu keeps the file in an unreviewed state. It records the problem under Overall rather than treating silence as a clean check.
A model writes the patch-level summary after the category passes, but it does not choose the final status. Orangu derives that status from its file records. Approval requires every file to be approved. One rejected or unreviewed file rejects the patch.
This prevents a failed assessment from disappearing inside confident summary prose. The summary can still misdescribe the code, but the missing state survives it.
The same rule is simple to reproduce outside orangu. Give each required check an explicit state such as pending, passed, failed, or incomplete. Allow only the harness to change the aggregate result, and require every mandatory check to reach passed. A timeout, parser error, empty answer, or cancelled request should end as incomplete. The model can explain those records, but its explanation must not replace them. This turns a vague "review completed" message into a result that another program can inspect before merge.
Source Reading Methodology tests the artifact that must survive a model edit rather than trusting the surrounding explanation. In orangu, that artifact is the set of file and category states. The paragraph at the top of the report is commentary on those states.
Freshness depends on local Git state
/auto_review compares both committed and uncommitted branch changes with the merge base of the default branch. Before it starts, orangu checks whether the branch trails its locally known main or master reference. It refuses a stale branch and asks for a rebase, but it does not fetch remote changes.
The guard therefore proves freshness only against local refs. Fetch and rebase before opening the review:
git fetch origin
git rebase origin/main
orangu
After /auto_review, examine every rejected or unreviewed file, run the repository's tests, and read the diff. A model report is review input, not proof of correctness.
Scope has another edge. /auto_review <file> can inspect one file. On main or master, it reads the full file instead of a branch diff. /auto_review all takes its inventory from git ls-files, so it excludes ignored and untracked files. An audit record should state which form ran. A new untracked file is outside "all" until Git knows it exists.
Measure the reviewer you actually run
The project repository explains the mechanism in unusual detail, but it does not provide evidence that its verdicts beat another tool or a human reviewer. Its release history records implementation changes, not review accuracy. A fair evaluation needs labelled defects, a fixed model and quantization, saved prompts, repeated runs, and false-positive counts.
That evaluation can stay local. Send the same patch corpus through two models behind orangu-server or another OpenAI-compatible endpoint. Save the category outcomes as structured data. Count known defects found and clean lines flagged. The comparison will tell you more than an anecdote about one impressive review.
Our nano-pi article argued that the loop is the small part of an agent. Orangu's review design makes the point concrete. Scope, cache reuse, explicit failure, and a deterministic verdict rule shape the result before the summary is written.
A private reviewer can still review badly. Any team borrowing this pattern should preserve the narrower invariant: a failed, truncated, or structurally empty review must remain unreviewed.
