Copilot Code Review Settings Move Off the Pro-Only Features Page
GitHub's changelog is plain about the old arrangement. Personal Copilot code review settings used to exist only for Copilot Pro, Pro+ and Max subscribers, on the "Copilot features" page. They included one automatic review setting and no separate controls for draft pull requests or new pushes. People whose seat came from an employer's Copilot Business or Copilot Enterprise subscription had no personal code review settings at all.
The new location is profile → Copilot settings → code review. It is a separate page for code review, and GitHub says it is available on every Copilot plan. The changelog names Copilot Business and Copilot Enterprise as examples and does not list other plans or exclusions. Effort levels themselves shipped earlier and, according to GitHub's August 7 changelog, Lite and Balanced are available with Copilot Pro, Pro+, Max, Business, and Enterprise plans. Users on any other plan should check whether the page appears for them before counting on it.
The practical change for business users is control over their own pull requests. Before, a developer at a company that licenses Copilot Business could only use code review as their organization or repository had configured it. Now that developer can decide when Copilot reviews their own work and at what depth, inside whatever limits the organization sets.
Three Automatic Review Triggers Replace a Single Switch
The personal page replaces the old single toggle with separate controls that map to stages of a pull request. The main automatic-review setting starts a Copilot review when you create a pull request, when you coauthor one, or when you move one out of draft. Two further options add reviews for new pushes and for draft pull requests you create or coauthor.
These map to three separate moments:
- The main setting reviews a pull request when it opens for review, either at creation or when it leaves draft state.
- The draft setting runs reviews while a pull request is still a draft, before you've asked for human attention.
- The new-push setting runs a review again when more commits land on a pull request that is already under review.
The new-push option is the one most likely to change daily habits. Without it, an automatically reviewed pull request generally gets one pass, and later changes need a manual re-request. With it, every push can trigger a fresh review. That gives developers continuous feedback, but every run uses resources, as the effort section below explains.
Draft review is aimed at people who treat Copilot as an early reader. You get machine feedback before colleagues see the pull request, so obvious problems can be fixed before a human reviewer spends time on them. People who push half-finished drafts often may find the extra reviews noisy, and they can now leave this option off while keeping the main trigger on.
Personal Default Effort Sits Beneath the Per-Review Picker
The personal page also sets a default review effort. GitHub currently shows two choices, Lite and Balanced. The changelog says this default applies to reviews you request, including automatic reviews of your own pull requests. When you request a review manually from the "Reviewers" area of a pull request, you can still pick a different effort for that request.
GitHub's documentation describes Lite as a cost-efficient review that provides targeted feedback on glaring issues such as bugs, security vulnerabilities, and style inconsistencies. It describes Balanced as deeper analysis of complex logic, security-sensitive code, and cross-service changes, using a higher-reasoning model. These are GitHub's descriptions of intent, not independent measurements of what each level catches.
The trade-off is cost. GitHub's setup documentation states that Balanced reviews use more AI credits, and may consume marginally more GitHub Actions minutes. One developer tracking the difference in a public GitHub issue cites a GitHub estimate of roughly 4× per review (Lite vs Balanced). That multiplier comes from a single third-party write-up and should be treated as a rough guide. It does show why a personal default combined with the new-push trigger adds up: a Balanced default with review-on-every-push multiplies the higher per-review cost by the number of pushes.
A per-review choice doesn't change any stored default. GitHub's August 7 announcement said a manual effort selection only applies to that review and doesn't change the repository or organization default. The September 23 changelog says the personal default covers the reviews you request. It does not say whether that default beats a repository's configured default for automatic reviews. Admins who want a specific effort enforced on certain repositories should keep that gap in mind.
People automating reviews should also know about an API limit. The same developer's issue reports that the REST review-request endpoint takes reviewers and team_reviewers and nothing else, and GraphQL RequestReviews has no effort field. If that still holds, scripts that request Copilot reviews can't choose an effort per request. They get whatever defaults apply, which makes the new personal and enterprise defaults more important for automated workflows.
Enterprise Default Review Effort Completes the Inheritance Chain
The second change covers administrators. Authorized enterprise administrators can now set one default review effort for the whole enterprise: Lite, Balanced, or "GitHub default." Organization-owned repositories inherit it, and organizations and repositories can still set their own overrides.
Before this, the top of the chain was the organization. When effort levels became generally available in August, GitHub said organization admins can set a default review effort level that applies to all repositories in the organization. Repositories that haven't configured their own effort level inherit the organization default. The organization setting is found under organization settings → Copilot → Copilot code review. GitHub's documentation also allows repository-level overrides, noting that you can override the organization default and set a different default review effort level for automatic reviews in a repository.
The chain now runs like this:
| Level | Who sets it | What it governs |
|---|---|---|
| Enterprise | Authorized enterprise administrators | Default effort inherited by organization-owned repositories (new) |
| Organization | Organization owners/admins | Default for its repositories that haven't set their own; overrides the enterprise default |
| Repository | Repository administrators | Default for automatic reviews in that repository; overrides the organization default |
| Personal | Individual user | Default effort for reviews that user requests, including automatic reviews of their own pull requests (new for all plans) |
| Per review | Person requesting the review | Effort for that single manually requested review, chosen under "Reviewers" |
Enterprises with dozens or hundreds of organizations benefit most. Setting a baseline used to mean visiting each organization's settings. Now one enterprise setting covers every organization that hasn't picked its own value. The changelog doesn't give the enterprise navigation path or say which enterprise roles count as "authorized," so admins will need to find the setting in their enterprise Copilot settings.
The enterprise default controls effort only. Nothing in the announcement says it turns on automatic reviews. Whether reviews run on pull requests is configured separately, and the enterprise setting only affects how deep those reviews go once they run.
The September 28 Balanced Switch Makes "GitHub Default" a Live Choice
The enterprise setting has three options, Lite, Balanced and "GitHub default," and the third is about to change meaning. GitHub's August 28 changelog announced that the default effort for Copilot code review is moving from Lite to Balanced. For existing and new repositories and organizations using Copilot code review, the "Default" effort value will mean Balanced starting September 28, 2026.
GitHub's instruction for organizations that want to stay on Lite was specific. Change the setting away from Default and explicitly select Lite in repository or organization settings before September 28, and GitHub will keep that choice instead of switching it to Balanced. Third-party coverage of the August launch confirmed that Lite was the starting default, with one guide describing Lite as fast, targeted feedback on common issues such as bugs, security vulnerabilities, and style inconsistencies. This is the default.
This makes the September 23 release more urgent than it looks. An enterprise that leaves its new setting on "GitHub default" is accepting the switch to Balanced, and with it higher AI credit use per review, for every organization that hasn't set its own value. An enterprise that explicitly picks Lite now can lock in the cheaper behavior across all organizations in one step, instead of chasing each organization before the deadline. The enterprise setting didn't exist when GitHub published its August 28 guidance. Organization and repository settings are still the documented way to keep Lite, and it is a reasonable inference, not something GitHub has stated, that an explicit enterprise selection protects inheriting organizations the same way.
The move to Balanced may suit some enterprises. Teams working on security-sensitive or cross-service code are the users GitHub has in mind for Balanced. The point is that "GitHub default" is no longer neutral. From September 28 it means Balanced, and GitHub can change it again later.
What This Means for You
Enterprise administrators have the most urgent decision: choose an explicit enterprise default effort before September 28, or accept that "GitHub default" becomes Balanced. Individual developers and organization admins can take their time. The new personal page mainly adds options, and nothing changes for users who ignore it.
For individual developers on Copilot Business or Enterprise, it's worth opening profile → Copilot settings → code review. Check whether automatic reviews fit your workflow, and turn on draft or new-push reviews only if you want feedback at those stages. Organization and repository admins should check whether their current effort settings are explicit values or still "Default," because that decides whether the September 28 switch affects them.
- Personal Copilot code review settings now live at profile → Copilot settings → code review and are available on every Copilot plan, including Business and Enterprise, not just Pro, Pro+ and Max.
- Automatic review can now run separately on pull request creation or leaving draft, on draft pull requests, and on new pushes, so developers can match review frequency to how they work.
- A personal default effort (Lite or Balanced) applies to reviews you request, and you can still pick a different effort for a single manual review under "Reviewers."
- Authorized enterprise administrators can set an enterprise-wide default effort that organization-owned repositories inherit, and organizations and repositories can still override it.
- Starting September 28, 2026, GitHub's "Default" effort means Balanced, so choose Lite explicitly if you want to keep the cheaper review level.
- Balanced reviews use more AI credits and may use slightly more GitHub Actions minutes, so combining a Balanced default with review on every push costs the most.
GitHub now lets you set Copilot code review defaults at every level, from the enterprise down to a single developer's pull requests. For enterprises, the new setting arrives five days before GitHub's own default changes from Lite to Balanced. Enterprises that set an explicit value this week decide their own review depth and AI credit spending. Enterprises that don't will be running Balanced reviews wherever no organization or repository has set its own value.