oss-pr-reviewer

The deciding trait is that it hands you a document instead of talking to your contributors. You run it, you get a report, and you decide what to say, which keeps the tone of your project in your hands rather than in a model's. For a maintainer who has watched a bot lecture a first-time contributor, that separation is the whole appeal.

It also means the work of responding is still yours. Pick it if you want a reading aid. Pick a bot that posts if what you wanted was fewer messages to write.

Batching is the necessary compromise and it has a cost nobody advertises. Splitting a change set by size means the caller who was modified in one batch and the callee in another are never considered together, which removes exactly the class of bug that human reviewers are worst at catching and that a tool was supposed to help with. Determinism makes it repeatable, not complete.

What it does right is refuse to guess. The batching rules are fixed rather than adaptive, so two runs over the same change produce the same division.

1. Schema validation of model output is the correct boundary: a response that fails to parse is rejected rather than half-interpreted, which converts an ambiguous failure into a clean one. 2. Recording what was not read is the rarer discipline, and it is the one that makes the report honest, because a reader can distinguish an absent finding from an unexamined file.

2. That distinction is what most review tooling elides. Publishing the reason a file was skipped turns a silent omission into a documented one, which is the whole difference.

There is nothing to value. No hosted tier, no meter, no team, and the market it addresses is unpaid maintainers, who are the least monetisable audience in software. That is not a criticism of the tool; it is a statement about why nobody will fund its second year.

Moat: none, and the platform whose API it calls could ship the same feature. Likely path: it remains useful and unmaintained, which for a few hundred lines of TypeScript is a survivable outcome. Position: copy it into your own tooling rather than depending on the package.

This one fits where my team already works. Structured output means the findings land in the systems we run rather than in somebody's terminal, it executes under credentials my platform team issues, and nothing is installed on a laptop, so the endpoint conversation never happens. The licence answers legal in a single reading.

What is absent is a vendor, a support path and any usage record beyond what my own pipeline keeps. Approved with conditions: it runs in CI under a scoped token, and its report is advisory on the merge check rather than blocking it.

A review tool with exactly one model vendor is a review tool that stops working when that vendor changes a policy, a price or a model name, and none of those are decisions I get a vote in. Nothing here reaches a machine of mine, which for a tool that reads private diffs is the wrong default.

The permissive licence is the escape hatch and I would use it on day one, because this is a few hundred lines of TypeScript and the provider call is one module. Fork it, swap the client, keep the batching. That is the correct way to use this.