Every pull request reviewed and checked

Each repository has an automatic review mode in Settings → Review: Off, Once (the first review when a PR opens) or Every push. You can also start a review from the pull request page in Capy, by commenting @capy review on the pull request, or through the API.

Each finding names a failure scenario and carries a category (Bug, Risk, Maintainability or Refactor), a severity, a confidence, and a file and line. Findings at or above the repository’s posting threshold post as inline GitHub review comments.

No. Re-reviews are incremental: only code changed since the last reviewed head is in scope, with the whole PR as context. Findings marked irrelevant are never re-flagged, and when a finding is resolved Capy resolves its GitHub thread.

Capy runs your app on its cloud machine, opens the change in a browser, clicks through it, and attaches screenshots or a video to the pull request. For mobile apps it can install your build on a cloud iPhone or Android phone.

Write them in your repository’s AGENTS.md files. The review agent enforces those rules as findings, on the same footing as logic bugs, and you can also list patterns it should never flag.

The thread that owns the pull request gets the verdict and triages it: it marks false positives irrelevant, confirms fixed issues as resolved, and fixes high-severity issues before it reports the PR ready. You can override any triage decision.

Reviews bill your organization’s Capy credits for the model and the machine. They don’t use the subscriptions and keys you connect in Settings → Models, and a higher review effort costs more.