Performance.

Perfloop looks for work your code can avoid while keeping the result right. Each proposed improvement needs a measurement against the original code.

What it looks for

Repeated work, avoidable copies and allocations, unnecessary round trips, and algorithms whose cost grows faster than the work requires. Perfloop reads your selected repos and builds a model of their services, workloads and code paths. Connected telemetry can show which paths matter under real load. Without it, Perfloop can use your benchmarks or a workload it runs itself.

How it proves a change

A Case states the workload and the metrics the change should improve. Perfloop runs the original code and the change under the same rules in the same environment, with repeated samples and checks for regressions. The repository's checks must pass. An independent verifier tries to disprove the change; the agent that proposed it does not grade it.

What you receive

A proven change can become a pull request with its measurements and the checks that ran. When an issue is the appropriate contribution, Perfloop can propose one instead. The Case keeps the result and its evidence, including work that did not prove an improvement. Publication follows your repo's controls and review requirements. Perfloop cannot approve, merge or deploy.

Limits

A benchmark proves a result for its tested workload, not every production condition. A local workload profile is not production telemetry. A post-merge production check runs only when the change declares one and the needed telemetry is connected. Work stays within your selected repos, available Usage and Case limits. Perfloop does not replace your profiler or observability tools.

Start with the Quickstart. The loop reference explains the evidence and result on each Case.

Also in this section: Quickstart, Bugs, Security, The loop, Case states, Pull requests, Steering and learning, Initiatives, Autonomy and limits, Members, and The MCP server.