PR-Agent

This is the review bot as a set of commands rather than a service. You type describe, review, improve or ask on a pull request and get exactly that, which is the trait that decides it: nothing happens unless you asked, so the noise level is whatever you choose. It works the same way across four forges plus Gitea, which is more coverage than the commercial products bother with.

You maintain it, and that is the trade. Pick it when you want control and have somebody willing to own the workflow. Pick CodeRabbit when you would rather buy the outcome.

Read the first paragraph before adopting. It states that this is a legacy project maintained by the community and directs readers to the sponsor's own review offering as the context-aware alternative. That is the maintainers being straight with you, and it is also a description of a project whose upstream has moved on.

There has already been one migration cost: images moved to a new registry namespace at a specific release, with older ones frozen, so anything pinned to the old path stops updating silently. What it does right: it supports forges the commercial tools ignore, which for some teams is the only reason a review bot exists at all.

1. Context assembly is the documented core ability, not an implementation detail. Diffs are compressed and individual file patches are fitted adaptively so a large pull request still fits a window, with surrounding context expanded where the change needs it. 2. Repository-level instruction files are read as first-class input. 3. Verification is self-reflection: the model scores its own suggestions so low-confidence output can be filtered rather than posted.

Publishing the compression strategy as documentation rather than treating it as a trade secret is unusual, and it is what makes the tool's behaviour predictable on a large change.

Study this arrangement, because it will be copied. The commercial vendor funds the open version that competes with its own offering, and the open version's front page recommends the commercial one. For the price of a sponsorship the vendor keeps the name, keeps the goodwill, and keeps the free tier from being built by somebody hostile.

For the project it means survival without independence, and development funded by individual sponsorship of a maintainer. Nobody acquires this; it was already owned once. Likely path: slow maintenance while the sponsor's product takes the growth. Position: use it as a free tool, never as a supplier.

This is the cheapest thing on the board for a team our size. It arrives as a workflow file of about a dozen lines, runs on our own pipeline minutes, and identifies itself with the repository's built-in token, so there are no user accounts to create, no directory to synchronise and nothing to revoke when somebody leaves. Cost is pipeline time plus whatever the model provider charges.

The data question is the only real one: our diffs go to whichever provider we key, and that choice is ours to make and document. Onboarding is a merged pull request. Approved with conditions: one owner, one provider decision, written down.

MIT, and there are three ways in: a container image, a Python install, or a command-line invocation against a pull request URL. Credentials are environment variables, which means it fits a secrets manager I already run rather than a configuration format invented for it.

The provider list is the part I care about. It reaches down to Ollama, so a review can be produced entirely on hardware I own and no diff leaves the network. There is no protocol client here and there does not need to be. It does one job, it does it in a container, and I can read every prompt it sends.