AI Review

The deciding trait is where it works. Six hosting platforms are supported, including the ones commercial bots ignore, so the tool meets your repository where it actually is rather than where a vendor's roadmap put it. For a team on a self-managed forge, that is the whole decision.

What you give up is the polish of a product with a dashboard: you configure it, you run it, you own the noise it makes. Pick it if your forge is unusual and you would rather tune a config than file a feature request. Pick CodeRabbit if you are on GitHub and want somebody else to operate it.

The failure mode is unbounded exploration. In agent mode the model issues shell commands until it decides to stop, and nothing in the documentation states a maximum number of turns. On a large repository one pull request can cost an unpredictable multiple of a plain diff review, and the process that discovers this is your invoice.

The second gap is that it edits nothing: the row records no file editing and no commits, so every comment is work created rather than work removed. What it does right is confining the shell commands to reading, ls, cat, rg and git, which is the correct restriction for a process this open-ended.

1. Three prompt layers are exposed for editing, which is unusually transparent and has a methodological consequence: two installations of this tool are not the same instrument. Any claim about its review quality is a claim about one configuration, and cannot be transferred between teams. 2. The documentation does not pretend otherwise.

2. No evaluation is published and none is claimed. For a review tool this is the important absence, because review quality is measurable in a way that agent capability often is not: a held-out set of pull requests with known defects would settle it. The design is legible; the performance is unmeasured.

The competitive position is the problem, not the funding. Every hosting platform this integrates with has an incentive to ship its own reviewer, and several already do; a client-side tool sitting outside them has no distribution and no data advantage to compound. Moat: none, and the architecture forecloses one by design.

There is also nothing to buy: no entity, no hosted tier, no revenue line, so the exit is not an acquisition but a slow decline in commits. Likely path: it stays useful precisely for the platforms the incumbents neglect. Position: adopt it for a forge nobody else serves, and treat the maintainer as a single point of failure.

The boring answers are good for once. No seat cost across sixty engineers, so the only bill is model spend on an account we already reconcile. It runs as a step in the pipeline rather than as a service, so there is no vendor holding our source.

What is missing is a console. There is no central place to see which repositories run it, which model each one uses or what any of it cost last month, so governance is whatever our pipeline templates enforce. Onboarding is a merge request. Approved with conditions: templates owned by the platform team, and a spend limit on the provider key.

Ollama listed beside the hosted providers is the line that matters: the whole review can run against weights on my own box, and nothing about the diff leaves the machine. Configuration comes from YAML, JSON or environment variables, which means the same setup works from a shell, a script and a pipeline without three different mechanisms.

Apache-2.0 keeps the fork available and the tool proxies nothing through a vendor, so there is no service to be deprecated out from under me. Python is the only grumble: a dependency tree I did not choose. Grudging respect, and it is the rare reviewer I could run air-gapped.