Find bugs and slow code, and get a pull request with the proof

Perfloop reads your repos and proposes hypotheses. You choose which Cases to work. A change must pass its checks and independent verification before it can become a pull request.

The workflow

1. Connect your repos in Setup. A model build reads them, and hypotheses worth testing appear as Cases.
2. Open a Case and select Work this case. Your coding agent can also submit a branch for review through the MCP server.
3. Perfloop writes the change and a test or benchmark that shows the effect, and runs the builds and tests for the code it touches. It then measures a performance claim against the original code, or checks that a correctness claim holds.
4. The Case page shows the verdict and the evidence behind it.

The loop and the MCP server explain each step.

Public Cases

• Tigris TAG: removing a cache-completion wait reduced the median cacheable GET-miss handler time from 101.2 ms to 0.57 ms. Verified and merged upstream.
• RoaringBitmap: bitwise set operations made the BSI batch-equality query benchmark about 30.6× faster and reduced allocated bytes by 72.3%. Verified and merged upstream.
• Zoekt: sorting once after collecting search results reduced median search time by 96.1% across 128 repos with 64 interleaved file matches each and no display limit. Verified and merged upstream.
• Dolt: closing a keyless index scan early could leave its producer goroutine blocked on a full channel. Validated by a different change, merged upstream.

What it cannot do

Perfloop opens pull requests, and issues for results better filed as an issue. It cannot approve, merge, or deploy. A proven result opens nothing until a member selects Approve & open PR or Approve & open issue in Inbox, unless that repo's Pull requests control is on. When your repo's rules hold a result, the hold shows on its Case page instead. A hypothesis the evidence disproves is recorded as refuted, and its record stays. Start with the Quickstart.