A review appears to use Balanced, but the repository setting still says Lite—or the comments do not match what your team expected.

Fastest fix: verify the effective effort level separately for organization defaults, repository defaults, manual requests, and automatic requests. Then replay the same Apple-project pull requests and compare quality, latency, and usage before deciding whether to keep Balanced or set an explicit policy.

This guide is for engineering leads choosing a review policy, repository maintainers checking pull request behavior, and platform administrators tracking organization settings, usage, and Mac development workflow impact.

Last updated September 20, 2026; policy details checked against the GitHub Changelog, Copilot Code Review documentation, and GitHub’s policy and billing documentation. The announced change is scheduled for September 28, 2026. Recheck the current documentation and your own effective settings after that date; an announcement does not prove the change has taken effect across your environment.

Treat Balanced as a policy change to verify

GitHub has announced that the default effort level for Code Review will change from Lite to Balanced on September 28, 2026. That date is a planned default change, not evidence that every request in your organization will use Balanced. Explicit organization or repository settings, request type, and configuration can affect what a particular review does. Use the official announcement on policy and billing changes as the dated reference, then verify your environment after the scheduled transition.

For acceptance, keep four questions separate:

  • Organization default: What does the organization policy specify, and which repositories inherit it?
  • Repository default: Does the repository have an override or a local configuration that changes the effective policy?
  • Manual request: What effort level applies when a developer explicitly asks for a review?
  • Automatic request: Does a review triggered by your workflow follow the same policy as a manual request?

Do not mark the rollout complete because one setting page displays Balanced. Record the setting, the request path, and the observed review behavior together. The Code Review setup documentation is the place to check the supported configuration controls. If the UI, configuration, and resulting review appear to disagree, preserve the pull request and request details, confirm whether an explicit setting applies, and escalate the discrepancy rather than silently treating one view as authoritative.

A useful acceptance record includes the repository, request type, effective policy source, displayed effort level, review result, and timestamp. Keep access to that record limited to people who need to administer or audit the workflow. If your team also needs to review who can configure Copilot, use the SSHMac help center as a starting point for support and setup questions.

Score review quality against known outcomes

A more intensive setting is not automatically a better fit for every team. You need to know whether the comments help reviewers find real defects without burying them in duplicates or low-value suggestions. Use the same set of historical pull requests or deliberately selected real changes for Lite, Balanced, and any explicit policy you are considering. Keep the sample and review conditions consistent; otherwise, a different result may reflect a different change rather than the effort level.

Classify each review outcome into four buckets:

  • Valid finding: The comment identifies a real defect, risk, or concrete issue that the team agrees needs attention.
  • Duplicate suggestion: The comment repeats a finding already raised by another comment or by the developer.
  • False positive: The comment presents a problem that does not apply to the code or its context.
  • No comment: The review produces no useful comment on the change.

Track both the count and the examples behind each bucket. A single total such as “comments per pull request” hides whether a review found an important defect or generated several redundant suggestions. For a finding to count as valid, ask the owner to confirm the issue in the code or its behavior. For a suspected false positive, retain the relevant context so that another reviewer can determine whether the finding was simply misunderstood.

The review exclusions matter here. Before interpreting “no comment” as a quality failure, check whether relevant files were excluded. GitHub documents how files excluded from Copilot Code Review are handled. A source file that never enters the review is not evidence that the model missed a defect in a reviewed file. Record exclusions alongside each sample, especially when your pull request contains generated files, scripts, or project configuration.

Avoid claiming that Balanced improves quality by a particular percentage unless you have a repeatable, documented test that supports that figure. The acceptance decision should instead state what your team observed, what it considers an acceptable finding, and which known risks remain uncovered.

Measure latency without confusing it with quality

Capture the review start time, first-comment time, time the result is complete, and the time a developer spends triaging comments. These are separate signals. A review that produces an early comment but continues later is not necessarily complete, and a fast response is not proof of a useful one.

For a fair comparison, use equivalent pull requests and record the trigger path. Note when a developer requested the review, when an automatic review began, and whether the pull request was waiting on other checks. Where the workflow makes it possible, keep unrelated delays—such as a slow build or a delayed reviewer response—separate from the Code Review timeline.

Then compare the results with your team’s own release and review needs. If developers wait for useful comments before taking the next step, review completion time may matter. If reviews run asynchronously, the more relevant issue may be whether they finish before a human reviewer’s decision. Set your own limits from your workflow; do not infer that the default change will make every team slower or more accurate.

For Mac development teams, this distinction is important when a pull request changes Xcode project files or automation. Code Review can provide an additional review signal. It does not run the project’s build, execute its tests, validate signing, or confirm behavior on an Apple device. Keep the timeline for those checks visible rather than attributing their delays or results to the review policy.

Watch usage at the right scope

Balanced may affect how usage is recorded or consumed, but a team should not infer a price or quota from the effort-level label. Review the current policy announcement and billing guidance, then inspect your own usage data. The GitHub billing reports documentation explains how to consult billing reports; use the reporting scopes available to you to compare organization, repository, and user activity.

Keep the usage comparison tied to equivalent review samples. Record the number and type of requests in each sample, whether they were manual or automatic, and which policy applied. If overall usage rises after the default changes, check for more pull requests, repeated requests, or a workflow change before attributing the difference to Balanced.

Monitor for unusual growth using your own budget controls and review cadence. A meaningful alert is one that points to a specific scope or behavior your administrator can investigate. Avoid copying a cost estimate from another team: repository activity, policy scope, and current billing rules may differ. When the report and the policy documentation do not appear to align, preserve the relevant billing period and request records and verify the current interpretation with GitHub’s documentation.

Important: A lower usage figure is not an acceptance win if it comes from missing reviews, excluded files, or a workflow that no longer runs. Compare usage with completed review coverage and finding quality.

FAQ: effective settings and project checks

Balanced timing

The announced default change is scheduled for September 28, 2026. Until you verify the current policy after that date, treat Balanced as the announced target rather than an already effective setting for every repository or request. Compare the applicable organization and repository policies with actual manual and automatic reviews.

Setting the effort level

Use the current configuration documentation to identify the controls available to your organization and repository. Record the policy source for each request path, especially where a developer can make an explicit request. Confirm the result in a controlled pull request; a saved setting alone does not demonstrate which level an actual review used.

Usage impact

Do not assume Balanced has a fixed usage or cost impact. Compare equivalent requests in your own billing reports and separate review-policy effects from changes in pull request volume or workflow behavior. Recheck the current billing guidance if the policy changes or your report shows unexpected growth.

Xcode project acceptance

Use known changes that cover project dependencies, signing scripts, tests, and CI configuration. Compare Code Review findings against expected risks, but keep Xcode builds, test execution, signing, and release validation as separate checks. A review comment is not proof that the application builds or works on a device.

Run a controlled Apple-project regression

Choose a sample that represents actual risk in your repositories, not a collection of easy source-only edits. Include changes to dependency declarations, signing scripts, test code, and CI configuration where those changes exist in your project. Pair each sample with a short expected-results note written by a maintainer who understands the change. This gives reviewers a baseline for judging valid findings and missed concerns.

Run the sample under the relevant request paths and policies. Record which files were in scope, the effort level shown or applied, whether the review ran manually or automatically, and the four quality outcomes. If results differ, inspect the actual comments and configuration before changing the team default. Do not add a special case merely because one review produced a comment your team dislikes; identify whether the issue comes from policy scope, file exclusion, request context, or the review itself.

Keep platform validation outside the acceptance score for Code Review. Follow the project’s established build and test process. Apple’s documentation on testing a release build and creating an app archive for distribution describes separate release and distribution work. These checks remain necessary even when a review finds no issue. Code Review is a review aid, not a replacement for Xcode build results, test execution, signing validation, or device acceptance.

I cannot report a site-specific regression result here: this article has no verified SSHMac Apple-project pull request sample, review-output set, usage record, or team acceptance data to cite. Do not treat any example in this checklist as a measured SSHMac result. Your team should populate the record with its own evidence before deciding whether the default is acceptable.

Make the rollout decision from evidence

Use these decision branches after the regression. The result should be a policy decision with a named owner and a clear reason, not a general opinion that one effort level “feels better.”

  • Keep the inherited Balanced default if the effective policy is consistent across the intended repositories, valid findings meet your team’s needs, false positives and duplicate suggestions remain manageable, and usage and latency fit your operating limits.
  • Set an explicit effort level if the inherited default conflicts with a documented repository requirement, or if equivalent samples show that another available setting better fits that repository’s review workload. Record why the override exists and who will revisit it.
  • Limit the rollout to a pilot if your team lacks a representative sample, cannot separate review time from other workflow delays, or has not established an owner for usage monitoring. Expand only after the missing evidence is available.
  • Pause or roll back the affected policy if the review path is inconsistent, usage behavior is unexplained, or comments create a level of review noise your team cannot safely triage. Keep the control narrow; a problem in one repository is not, by itself, a reason to disable Code Review organization-wide.

Give each policy decision a recheck trigger. Revisit the evidence after the scheduled default transition, a relevant policy or model change, a change in billing rules, or a material change in the Apple-project workflow. The recheck is not a claim that each event will change quality; it prevents an old acceptance decision from silently becoming the team’s permanent assumption.

The comparison below helps translate the evidence into an operating choice. It is not a claim that one option performs better in every repository.

Operating choice What you accept Evidence to retain Reconsider when
Inherited Balanced default The configured default applies to the intended request paths Effective policy, request type, sample findings, timing, and usage records A repository’s results or operating limits diverge from the team’s needs
Explicit repository policy A repository needs a deliberate setting instead of relying on inheritance Reason for the override, owner, regression sample, and review date The project or its review requirements change
Limited pilot Evidence is incomplete, so exposure stays narrow Pilot scope, known gaps, findings, timing, and usage observations The sample becomes representative and an owner can approve expansion

Keep Mac validation available without overbuying

Your current workflow may rely on a developer’s primary Mac, a shared Mac that is difficult to reserve, or CI results alone. Those approaches can create real limits: the primary machine may be occupied, shared access can delay hands-on reproduction, and CI output does not always give a maintainer a convenient interactive environment for investigating an Xcode change. None of these issues means you should rent a Mac for permanent, uninterrupted workloads; a team with steady heavy use or a need for physical interfaces may be better served by its own managed hardware.

For a time-bounded regression, however, having a separate Mac environment can make it easier to inspect the same pull request, run the project’s Xcode checks, and keep the review experiment apart from a developer’s everyday setup. That is useful when the team needs temporary capacity for a policy transition or parallel validation, not as a substitute for Code Review or CI. You can review the available Mac environment through SSHMac, then decide whether a short-term rental fits your test window; if you need a sustained, stable workload, compare the rental cost and access requirements with owning and managing a dedicated Mac instead.

Start with a small set of historical pull requests, verify the four policy scopes, and keep Balanced only when quality, latency, usage, and Apple-platform checks meet your team’s criteria. If a finding or cost signal fails, change the narrowest relevant policy and rerun the same regression rather than disabling review across the organization.