GitHub Copilot code review adds REST and GraphQL admin APIs and an addressed rate

GitHub has opened the settings of Copilot code review to programmatic management. In a changelog entry dated November 6, 2026, the company said that code review settings can now be managed through its REST and GraphQL APIs at every level of the hierarchy, from enterprise policy down to individual repositories, and that review responses now expose attribution fields, the review effort used and the customizations Copilot cited for each comment. The same release reworks the review overview that appears on pull requests, shows the AI credits a review session consumed, and adds a bypass list to the rule that requests Copilot reviews automatically.

A day earlier, on November 5, 2026, GitHub extended the Copilot usage metrics API with a new copilot_code_review object in repository-level reports. Its counts let administrators compute what GitHub calls the addressed rate: the share of evaluated Copilot review comments that developers acted on, whether by applying a suggestion, asking Copilot to make the fix, editing the code themselves or replying that the fix will land in a later pull request. A second metrics update flags users whose editors send no telemetry or run versions below the minimums that the metrics pipeline supports.

Taken together, the two releases give engineering managers and platform teams three things they lacked: a way to configure Copilot code review as code across many organizations, a per-review view of cost in AI credits, and a measure of whether review comments change what gets merged. The changes apply to Copilot code review on the Copilot Pro, Pro+, Max, Business and Enterprise plans, while the metrics fields are available in enterprise and organization reports to owners, billing managers and holders of the View Copilot Metrics permission.

··········

COPILOT CODE REVIEW SETTINGS NOW MANAGEABLE THROUGH REST AND GRAPHQL APIS.

Until this release, the controls for Copilot code review lived in the settings pages of enterprises, organizations and repositories, plus rulesets that request reviews automatically. GitHub now exposes those settings through its REST and GraphQL APIs and keeps the same inheritance model the web interface uses. Enterprise administrators can enable or disable code review for all organizations, or leave the choice to organization administrators. Organization administrators can manage enablement, the default review effort and the runner configuration, though settings the enterprise manages cannot be overridden lower down. Repository administrators can manage the review effort and whether reviews use custom instructions and MCP tools.

The API uses the same effort levels as the web interface. GitHub currently offers three of them, Lite, Balanced and Max, with Max introduced in public preview on October 28 as a multi-agent review for higher-risk changes. The company's documentation says Balanced reviews use more AI credits than Lite and may consume marginally more GitHub Actions minutes, which makes the default effort setting a cost decision as much as a quality one.

Authentication differs by level, and this will shape how teams automate the settings. Enterprise, organization and organization runner endpoints do not accept GitHub Apps or fine-grained personal access tokens. Repository endpoints accept both, with the Administration permission set to read for reading settings and to write for updating them, while classic personal access tokens need repository admin access.

........

Level	What the API can manage	Accepted credentials
Enterprise	Enable or disable code review for all organizations, or delegate the choice	No GitHub Apps or fine-grained tokens
Organization	Enablement, default review effort, runner configuration	No GitHub Apps or fine-grained tokens
Repository	Review effort, use of custom instructions and MCP tools	GitHub Apps and fine-grained tokens (Administration read or write); classic tokens with repo admin access

........

The changelog entry does not list the endpoint paths or the GraphQL mutation names, and it points to the REST and GraphQL documentation for those details. Teams that plan to manage settings with infrastructure-as-code tools will need to check those reference pages before wiring the calls into their pipelines, since the credential limits above rule out a single GitHub App for enterprise-wide automation.

··········

WHAT COPILOT CODE REVIEW RESPONSES NOW REVEAL ABOUT EACH REVIEW.

The second part of the API update concerns the reviews themselves. Reviews and comments created by Copilot can now be identified through explicit attribution fields, which removes the need to recognize them by author name or comment format in scripts. When the data is available, responses also show the review effort that was used and which skills, MCP servers and custom instructions Copilot cited as sources for a given comment.

That last field is the most useful for teams that have invested in repository guidelines. A platform team that maintains custom instructions for security rules, or an MCP server that gives Copilot access to internal documentation, can now see which comments drew on those sources instead of inferring it from the text of the review. Combined with the customization breakdown in the usage metrics described below, it gives a first way to judge whether a custom instruction file is producing comments that developers accept.

GitHub also shows the AI credits consumed by a code review agent session. Since the October 28 release, the company has said that Max reviews take longer and use more AI credits than Lite or Balanced, but administrators had no per-review figure to compare the levels. The new display gives them one, although the changelog does not say whether the credit figure is also returned through the API.

··········

THE REDESIGNED COPILOT CODE REVIEW OVERVIEW AND NEW REVIEW RULES.

The overview comment that Copilot posts on a pull request has been compacted. Review effort and the feedback survey move into a footer, files that were skipped or excluded by content exclusion rules are grouped in a single "Files not reviewed" section with filenames and linked reasons, empty sections are omitted, and long lists show an overflow count. When a developer gives a review a thumbs-down, they can now add a reason, such as an approval assessment they disagree with, a comment that is too verbose, or findings that are wrong or nitpicky.

Repeated reviews of the same pull request also behave differently. On later reviews, findings unrelated to the latest changes are collapsed and then hidden, which reduces the volume of repeated comments on long-running pull requests. GitHub states that Balanced reviews now use three reviewer models, with another model combining their findings into one review. That brings part of the multi-model design introduced with Max to the default effort level, although GitHub has not named the models involved.

The repository rule "Automatically request Copilot code review" now supports a bypass list, so selected actors do not receive automatic reviews. This is useful for bot accounts and release automation, where an automatic review adds credit consumption without adding value. Organization and repository settings pages also received clearer wording and layout.

The bug fixes address reliability problems that administrators had to work around. Billing and preview settings are preserved when code review is turned off and on again. Failed or timed-out reviews are retried once automatically, and Copilot can switch to another eligible model when the preferred one is unavailable. Reviews no longer report a false failure just after starting and then discard their results, and reviews in progress during a service update get more time to finish. Review surveys no longer appear for organizations that opted out of feedback collection.

One fix concerns billing rules. When an organization turns on "Block reviews requested with an external Copilot license", GitHub Actions, Dependabot and apps owned by the organization or enterprise can again request reviews on pull requests authored by bots, provided the organization pays for the review.

··········

COPILOT CODE REVIEW METRICS: THE NEW FIELDS AND THE ADDRESSED RATE.

The November 5 update adds a copilot_code_review object to each repos-1-day row of the enterprise and organization repository-level usage metrics reports. Repository-level Copilot usage metrics became generally available in July, and until now they showed how often Copilot code review ran and how often its ready-to-apply suggestions were applied. The new fields cover the other ways developers respond to a review.

........

Field	What it counts
total_comments_evaluated	Copilot review comments checked for a developer response
total_comments_addressed	Evaluated comments the developer acted on
review_comments_by_severity	Both counts by severity, such as high, medium and low
review_comments_by_review_tier	Both counts by tier: lite, balanced and max
review_comments_by_comment_type	Both counts by type, such as bug, security and custom
review_comments_by_customization	Both counts by custom instructions, skills, MCP servers or none
total_merged_no_human_change_request_after_review	Merged pull requests with no human change request after Copilot's first review

........

GitHub defines the addressed rate as total_comments_addressed divided by total_comments_evaluated. As an illustration with hypothetical numbers, a repository with 240 evaluated comments in a month, of which 168 were addressed, would have an addressed rate of 70%. If 30 of 40 evaluated security comments were addressed, the security addressed rate would be 75%, and the breakdown by review tier would show whether Max reviews, which cost more AI credits, produce comments that developers act on more often than Balanced ones.

The counting rules matter for anyone building a dashboard on these fields. Comments are evaluated when their pull request merges, so they are counted on the merge day rather than the day Copilot posted them. Copilot usually does not evaluate comments on pull requests opened by bots, such as the Copilot cloud agent, although those pull requests still count toward the merged-without-change-request total. Counts are zero and arrays are empty for repositories with no Copilot code review activity that day. The older pull_requests.total_copilot_applied_suggestions field keeps its narrower meaning and counts only ready-to-apply suggestions that someone applied.

··········

TELEMETRY GAPS IN THE COPILOT USAGE METRICS API.

The second metrics update, also dated November 5, explains why some users appear active in reports but lack details such as lines of code, feature breakdowns and model breakdowns. A per-user client_telemetry_present field is false when Copilot saw the user's activity but received no usage events from their editor. A per-user usage_metrics_requirements field marks each of the user's IDEs and Copilot extensions as met, unmet or unknown against the minimum supported versions. Daily counts, missing_client_telemetry_user_count and below_usage_metrics_minimum_user_count, summarize both conditions.

GitHub lists outdated editors or extensions, disabled IDE telemetry, and proxies or firewalls that block events as common causes. A user can meet every version minimum and still lack telemetry, for example behind a blocking proxy. The documentation warns against adding the two counts together, because a user can appear in both, and against summing counts across days to estimate unique users. Null or omitted values mean the data is unavailable and should not be read as false or zero, and days before the release carry no values.

··········

WHAT CHANGES FOR GITHUB COPILOT ADMINS AND DEVELOPERS.

Developers see the changes in the pull request itself: a shorter overview comment, a list of files Copilot did not review with the reasons, fewer repeated findings on later reviews, and the option to explain a thumbs-down. Teams that rely on Balanced reviews get three reviewer models by default, and failed reviews are retried once without user action.

Administrators gain more work and more control. The access rules and plan coverage are summarized below.

........

Item	Who and where
Copilot code review updates	Copilot Pro, Pro+, Max, Business and Enterprise
Settings API, enterprise and organization	Enterprise and organization admins; no GitHub Apps or fine-grained tokens
Settings API, repository	Repository admins; GitHub Apps and fine-grained tokens allowed
Code review and telemetry metrics	Enterprise owners, billing managers, organization owners, View Copilot Metrics role
Metrics prerequisite	Copilot usage metrics policy enabled

........

A practical sequence for an organization that already uses Copilot code review starts with the usage metrics policy: once it is enabled, the daily repository reports begin to fill the new code review fields from the release date forward. The second step is to check the telemetry fields, because users with missing telemetry will make the remaining metrics incomplete. The third is to compare the addressed rate by review tier and by customization before changing the default effort, since Balanced and Max consume more AI credits than Lite. Organizations that bill reviews to the organization rather than to members also need AI credits paid usage enabled, according to GitHub's configuration documentation.

The background on review effort levels and approvals is in our coverage of GitHub Copilot code review Max and generally available approvals. Enterprises reviewing how AI credits are billed can also read our report on GitHub Enterprise Copilot access with no seat charge and AI credits billed from the first request, and the model routing behind several Copilot features is covered in our article on GitHub Copilot Fusion.

··········

GITHUB COPILOT CODE REVIEW APIS AND METRICS: CONFIRMED FACTS AND OPEN QUESTIONS.

The facts GitHub has published are specific. Copilot code review settings can be managed through REST and GraphQL at the enterprise, organization and repository levels, with enterprise policies taking precedence and with credential limits above the repository level. Review responses carry attribution, effort and cited-customization data when available. Balanced reviews use three reviewer models and a combining model, sessions show their AI credit consumption, failed reviews are retried once, and the usage metrics API now reports evaluated and addressed comments by severity, tier, type and customization, plus telemetry and version gaps per user.

Several points remain undocumented in the changelog entries. GitHub has not listed the endpoint paths there, has not named the models used for Balanced reviews, and has not said whether the AI credit figure for each review is available through the API or only in the interface. The addressed rate also depends on GitHub's own classification of what counts as acting on a comment, and comments are recorded only when a pull request merges, so abandoned pull requests and most bot-authored ones fall outside the measure. For teams deciding between Lite, Balanced and Max on cost grounds, the new fields provide the first data to compare them, with those limits in mind.

··········

FOLLOW US FOR MORE.

·····

DATA STUDIOS

·····

datastudios.org