Roomote

The deciding trait is where the work lands. Output arrives as a pull request you read the way you read a colleague's, which means the process around it already exists: reviewers, checks, the argument in the comments. Nothing new has to be invented for the result to be absorbed.

What that costs you is visibility during the run. You see a finished proposal rather than a developing one, so a task that went sideways spent its whole budget before you found out. Pick it if your review culture is strong. Pick a supervised agent if it is not.

The gap is authorisation. Connect this to a busy channel and the set of people who can start a run against a production repository becomes the set of people in the channel, which is usually larger and less deliberate than the set with commit rights. Nothing in the row records a permission mapping between sender and repository, and chat platforms are not access control.

What it does right is finish the job. Tests are run before the pull request is opened, so the reviewer receives a proposal that has already failed once privately if it was going to.

1. Executing in a throwaway environment makes each run independent, so a failure cannot contaminate the next task through leftover state. That property is what makes repeated attempts interpretable.

2. Running the tests before proposing the change places verification inside the loop rather than after it, which is the distinction between an agent that works and one that reports.

3. The screenshot is a visual artefact attached to the claim. It is weak evidence and it is evidence, which is more than most rows offer. 4. No evaluation is published.

This is a considered go-to-market rather than a repository with a licence attached. An existing developer base gets the self-hosted version free, the buyers who do not want to operate it pay for the hosted one, and the vendor learns which is which without a sales team. That is how this category is supposed to work.

Moat: the audience they already have, plus the operational knowledge of running the sandboxes. Likely acquirer: a code-hosting platform wanting an autonomous surface it does not have to build. Position: the strongest ownership story among the self-hostable options here.

Tracker integration is what turns this from a toy into a process. Work arrives from the systems we already use and returns as a reviewable change, so the tool fits between two things procurement approved years ago rather than sitting beside them. Self-hosting also removes the data-residency conversation entirely.

The open questions are ours to answer: no identity integration is described, the sandboxes are infrastructure my team will run, and model spend lands on our keys with no per-task budget I can see. Approved with conditions: our infrastructure, scoped repository access, and a monthly spend report.

Source-available is better than closed and it is not the same thing, and I would rather the row say so plainly, which it does. I can read every line, run it on my own hardware and bring my own key through an aggregator, so operationally I have most of what I want. The delayed conversion means a fork becomes fully mine eventually rather than now.

The gaps are protocol and weights. No MCP client, so my servers stay outside the sandbox, and no local endpoint, so the one thing I cannot self-host is the model.