GitHub's Default code review setting moves to Balanced on September 28

GitHub will change what Default means for Copilot code review on September 28, 2026. Existing and new organizations and repositories that leave the review effort on Default will use Balanced instead of Lite.

This is not just a label change. GitHub says Balanced uses a higher-reasoning model for longer analysis, consumes more AI credits, and may use marginally more GitHub Actions minutes. Engineering leaders should resolve inherited settings before the date, then verify the selected effort, findings, and usage on representative pull requests rather than accepting the new baseline by accident.

What exactly changes on September 28?

GitHub's August 28 announcement says the review effort value Default will resolve to Balanced starting September 28. The change applies to existing and new repositories and organizations using Copilot code review.

An explicit Lite setting will remain Lite. GitHub tells administrators who prefer that behavior to move away from Default and select Lite before the change. The announcement does not say that every repository must use the same level.

The setting has two layers. An organization default applies to repositories that have not selected their own effort level. A repository default controls automatically requested reviews in that repository. For a manually requested review, the requester can choose the effort level from the reviewer control on the pull request.

That inheritance is the operational issue. A repository that appears unchanged can begin using Balanced because its local setting still delegates to an organization value named Default. The decision belongs at the repository class or repository level, not in a blanket assumption that one account-wide label reflects every codebase.

How do Lite and Balanced differ?

GitHub's code review documentation describes Lite as a fast, targeted review for common bugs, security vulnerabilities, and style inconsistencies. It describes Balanced as longer analysis using a higher-reasoning model for complex logic, security-sensitive code, and cross-service changes.

Those descriptions are product guidance, not an independent quality benchmark. They do not establish how many useful findings either level will produce in your repositories, how often either will be wrong, or whether a longer review will reduce human review time.

The usage difference is clearer. GitHub says Balanced uses more AI credits than Lite and may consume marginally more GitHub Actions minutes. Its current documentation estimates that a review typically uses $0.05 to $1 in AI credits with Lite and $0.25 to $5 with Balanced. Those ranges may change as models evolve, increase with pull request size and custom instructions, and exclude Actions minutes.

Do not turn the endpoints into a guaranteed multiplier. The ranges are estimates rather than a quote for a particular pull request, and the actual work mix matters. They are useful for identifying which review volumes deserve measurement, not for predicting an invoice from pull request count alone.

Which repositories should keep Lite explicitly?

A team has a defensible reason to select Lite when a repository receives frequent, routine, low-risk changes and fast feedback matters more than exhaustive analysis. Examples may include documentation, generated artifacts, or narrowly scoped maintenance repositories, but the classification should follow the files and deployment consequences actually present.

Lite should not mean “no human review.” Copilot comments remain recommendations. Branch protection, code ownership, tests, and accountable merge approval still decide whether a change ships.

Balanced is the more plausible candidate for repositories dominated by complex logic, security-sensitive paths, or cross-service changes because those are the uses GitHub names. That still needs a local acceptance check. A product description cannot show whether the additional findings are relevant, correct, non-duplicative, and worth the usage for your pull requests.

Some repositories will not fit one permanent level. A routine repository can receive an authentication change, while a critical service can receive a trivial documentation fix. Because manual requesters can select an effort level, teams can retain a conservative automatic baseline and choose deeper review for a specific pull request when the change warrants it.

How should administrators resolve inherited settings?

Start with settings, not invoices. Record the organization review effort and identify repositories that override it, inherit it, or still display Default. The migration risk sits in the unresolved group.

Next, classify those repositories by the work they normally receive: routine and bounded, mixed, or regularly complex and security-sensitive. This classification is BaristaLabs guidance, not a GitHub requirement. Give each class an engineering owner who can approve an explicit Lite, Balanced, or intentionally inherited setting.

For repositories with automatic review, sample representative pull requests before and after the setting choice. Keep the pull request type, review instructions, and human acceptance criteria as stable as practical. The pull request overview comment shows the effort level used, according to GitHub, so preserve that alongside the findings and usage record.

Measure more than comment count. Record which findings were actionable, which duplicated existing checks or human comments, which were incorrect, how much reviewer time they required, AI credits, and relevant Actions minutes. A deeper review that posts more comments is not automatically more valuable; a cheaper review that misses a release-blocking issue is not automatically efficient.

Keep this change separate from GitHub's other announcements

The same GitHub post announces changes to Copilot Business and Enterprise seat billing and a later unified policy for Copilot on the web, mobile, and cloud agent. Those updates have their own dates, scopes, and administrative decisions.

They do not prove anything about Lite or Balanced review quality. Mixing all three changes into one migration task can hide ownership: finance should review seat billing, Copilot administrators should review the unified experience policy, and engineering owners should resolve code review effort by repository scope.

For this review decision, the date to act on is September 28. Select Lite explicitly where routine review and fast feedback are the intended baseline; allow or select Balanced where the repository's change risk justifies testing deeper analysis; and leave Default only when inheriting the new behavior is deliberate.

Verify the effective level instead of trusting the label

Before September 28, export or record the organization and repository settings that determine automatic review effort. After the change, inspect the overview comment on sampled pull requests to confirm the level that actually ran. Then reconcile the usage evidence with those same repositories and review types.

That closes the gap between configuration intent and operating behavior. It also complements the controls in our guide to Copilot's head-branch review instructions: effort level governs how deeply Copilot reviews, while repository instructions, setup, runners, and network policy govern what shapes the run.

BaristaLabs helps engineering teams connect AI settings to workflow evidence through AI consulting. If your repositories inherit one review baseline but carry different change risks, bring one repository group to a focused settings and evidence review.

Sources

• GitHub Changelog: Upcoming changes to GitHub Copilot policies and billing
• GitHub Docs: About GitHub Copilot code review