pr-review policy controls both.
There is no fixed credit cost or universal maximum for a review. One review may use a single credit while another uses much more because pull request size, complexity, and selected review lanes vary. Use actual reviews in Dashboard Activity to decide whether the value and cost are right for your team.
Start with the reference policy
The reference daemon is a conservative starting point. It reviews a pull request when it first becomes ready for review, then waits for an explicit request before reviewing it again. It begins with two lanes: correctness and repository guidance. Keep those defaults for a few representative reviews before changing them. You will get a better result by tuning observed usage than by trying to predict one universal credit amount.Check credit usage in Activity
Open Dashboard > Activity and:- Choose a time range with representative pull requests.
- Filter to GitHub, Daemon, and
pr-review, or search for the repository. - Compare the number of review entries and the Credits value for each one.
- Follow the source links to see which pull requests were small, large, simple, or complex.
- Many review entries usually point to review frequency.
- A smaller number of expensive reviews usually points to pull request complexity or the lanes selected for those changes.
Choose how often reviews run
Review frequency is the most direct cost control. Configure it withwatch in .agents/daemons/pr-review/DAEMON.md.
Explicit reviewer requests and
@CharlieHelps comments add to review frequency, so team habits around them affect usage alongside the automatic policy.
Review only substantial updates
Add a push condition towatch with a concrete, observable threshold for when an update merits another review. Your threshold might use change size, a material behavior change, or changes under high-risk paths. Choose a condition your team can predict, and avoid vague wording that could match every push.
Review every commit
Add this condition when the additional coverage is worth the additional usage:Reduce the work in each review
The work required for one review depends mainly on the pull request and the lanes Charlie selects.Keep lane applicability narrow
Every installed lane must be considered. Each lane selected for the current pull request adds focused investigation and contributes candidates to the final review. Write clear applicability guidance so specialized lanes run only where they can add useful judgment. For example, a migration-safety lane should skip pull requests that do not change schemas, migrations, stored data, or compatibility behavior.Remove low-value or overlapping lanes
More lanes are useful only when they contribute distinct review value. If two lanes repeatedly inspect the same concerns, clarify their boundaries or combine them. Remove a lane when its accepted findings no longer justify its credit use or overlap with other perspectives. Do not use a finding cap as the first cost control. Charlie performs the review work before deciding which findings qualify, so a cap can hide useful feedback without meaningfully reducing the work already done.Keep pull requests reviewable
Large or cross-cutting pull requests require more context and investigation. Split changes when that also improves your team’s normal development and review workflow. Do not weaken the evidence bar for large pull requests. If a specialized lane is expensive on broad changes, narrow when that lane applies instead of asking Charlie to review less carefully. See Configure > Configure review lanes to edit applicability, add or remove lanes, and reduce overlap.Decide what to change
Change one control at a time. Merge the policy update to the default branch, allow a few minutes for Charlie to load it, then compare the next set of representative reviews in Activity.
Next steps
- Configure for complete cadence and lane-authoring guidance.
- Troubleshooting if Activity or GitHub output does not match the policy.
- PR review overview for the full setup and migration path.