Autonomy and limits.

What Perfloop may start on its own, per repository, and the limits that stop work. The five policies are in Setup under Automatic work. None of them lowers the proof bar, and none lets Perfloop merge.

Repository policy

An Admin changes these five policies in Setup and selects Save, which appears with Discard once a row changes. On a phone, expand a repo name to show its five policies. For PR defaults, open the repo's Settings under its code host on Connections. Each policy label explains its control on hover, focus or tap. A dash means that repo has no choice for the policy.

Perfloop never approves or merges.

On GitLab, Pull requests and PR feedback apply to merge requests Perfloop opens. PR review reviews other merge requests.

• System model. Keep current rebuilds the system model on Perfloop's schedule. Manual: you or a coding agent start builds. Keep current by default, and Manual in a workspace created at signup. While nobody uses the workspace, scheduled builds come less often; opening Perfloop, a coding agent call, or case work restores the normal schedule.
• Case work. Keep working lets Perfloop pick from Cases and work them. Wait: you or a coding agent start each case. Wait by default. Once started, work continues within its authorized limits when a candidate is rejected. A rejected candidate does not refute or finish the case. A completed pull request proposal waits for approval without starting more Case work. New feedback can start work under your PR feedback policy.
  • Wait. Perfloop picks no new case on its own. You select Work this case or your coding agent calls workCase.
  • Keep working. Perfloop picks ready Cases and works them, a limited number at a time across the workspace.
• PR feedback. Handle lets feedback on a pull request Perfloop opened start a Session, posts answers, and pushes verified repairs to that pull request. A failed check starts one by itself; a comment or review starts one when its author can push to the repository. With Ask, answers wait in Inbox and repairs follow Pull requests. Handle by default, and Ask in a workspace created at signup.
• Pull requests. Ask holds each proposal in Inbox. Open opens the pull request for a validated case without a member decision. Ask by default. On Connections, open the repository's Settings and turn on Draft PRs to open them as drafts; off, the default, opens them ready for review. This choice is available under Ask and Open alike. Switching permission keeps that choice. An Inbox approval's Open as lets you change it for its pull request. Perfloop does not change the state of a pull request it already opened.
• PR review. On GitHub.com, GitHub Enterprise Server, Cursor Origin and GitLab, On reviews PRs opened or committed to after you turn it on. Off by default. On Cursor Origin, if Setup asks for review permission, approve the App again. Reviews post unproven Hypotheses tied to the changed code. A finding on lines the PR changed is a comment on those lines; the others are in the review summary. Select Open in Perfloop on a finding to open its Case page, and Work this case there to test it at the reviewed commit. Reviews use Usage. A partial review says so; its findings do not cover the whole change. The Usage page lists each review as Diff review, linked to its PR.

Where pull requests open

Perfloop opens pull requests in the repo you connected, including when it is a fork. On Connections, open the fork's Settings: PRs to upstream is off by default. An Admin can turn it on to send future proposals to its parent; that still needs permission to publish there. Changing the target does not move a pull request already opened.

When a GitHub repository requires an issue before a pull request, Perfloop uses an existing issue or drafts one from the repository's template, and the pull request cites it. Some results are better as an issue, such as a measured problem the maintainers should handle themselves; Perfloop then proposes one issue instead. Both follow the Pull requests setting: with Ask, Inbox shows them for one member decision.

Stop work ends only the running Session and keeps the case's evidence. Automatic work can start another Session later. Close case holds future work. Reopen case makes it available again. Turning a control off stops later automatic starts. It does not cancel a Session or build already admitted.

Member sign-off is a separate workspace choice, off by default, described under The pull request. An Admin turns it on by selecting themselves with a complete profile; any Admin can turn it off.

Research

One cadence per workspace: off, every hour, every day, every week, or a number of seconds. A new workspace that can run research starts at every day; a workspace created at signup starts off. Each turn runs one research Session on one active Initiative and is billable. An Initiative takes cadence turns only after its first research Session, which a coding agent starts with startResearch whatever the cadence is. setResearchCadence changes the cadence; zero turns it off.

Usage and work limits

Usage is the prepaid balance every Session draws on. When it is out, no new Session starts, whatever the controls say; a proven candidate can still open its pull request. Setup names the automatic work that Usage cannot fund. The Usage page shows the balance, every Session's use, and each day's Initiative checks.

Each case has a Case limit, shown on the case page as Used / Case limit. A case whose work stopped at or near its limit waits in Inbox for an Admin to set a new total, continue it without a limit, or close the case. The new total must leave room for real work; Inbox refuses a smaller total and names the smallest one. Until an Admin raises or removes the limit, or a new Usage period starts, no new work starts on that case, including PR feedback, repair and Work this case. If maintainer comments on its open pull request still need answers, Perfloop posts a short comment there to say work has stopped.

An Admin can also raise or remove an open Case's limit through a coding agent at any time, without starting work. Raising a limit adds no Usage and approves no pending work. A budget stop does not settle PR feedback; work can continue when Usage and the Case limit permit it.

A workspace can run a limited number of Sessions at once. At that limit, a Session you or a coding agent start is refused with WORK_LIMIT_REACHED; retry when work finishes. Adding Usage does not free a place. Automatic work tries again on its own. Customer saves of automatic Case concurrency cannot exceed this maximum. A refused save leaves the saved count unchanged. Lowering a limit does not cancel work already admitted.

New work needs a positive Usage balance. Work already in progress can cost more than the balance left. Unpaid Usage carries into the next Usage period. New funds first cover that shortfall.

Usage names each pull request review by its number and title, as one link. An older review shows its number alone until Perfloop reads the title from the code host. Branch reviews show the branch name and repository, with a link to the reviewed code comparison when the code host supports it.

Billing terms

Automatic top-up charges the saved card the amount you set when the balance is below your threshold. It repeats while the balance stays below, up to your monthly limit per calendar month in UTC. Each top-up counts in the month it starts, at its own amount, even if payment completes later. The limit resets at the start of each UTC month. New funds first cover any shortfall; more than one top-up can be needed before the balance is positive.

In Usage, select Set up or Edit, choose the card and amounts, then select Save to give consent. Self-serve consent starts when you save and runs until an Admin turns it off. A change in Admins does not end it. Removing the card or ending the account stops new top-ups. An eligible first charge can start within minutes.

A signed agreement can instead limit new top-ups to an active Usage period. Those top-ups cannot start on the period's last UTC date; a one-day period allows none. Unused Usage expires at the end of that period, so a late top-up can expire within a day. A top-up does not renew or extend the period. Earlier purchases keep their accepted terms.

An Admin can select Turn off in Usage at any time. A successful response stops new top-ups immediately, without waiting for the payment processor. A payment in flight can still charge the card. A charge accepted while your successful withdrawal is being saved or afterward adds no Usage. Contact billing support for a manual refund; refunds are not automatic. Usage already added keeps its accepted terms.

If automatic payments are paused, contact billing support. Saving consent does not retry an outstanding payment. If that payment is still pending when you save, top-ups stay paused.

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

Questions: hello@perfloop.ai