GitHub Just Showed How Copilot Code Review Really Works, and Opened It to Admins

The Copilot code review API is here for admins

GitHub shipped a quiet but significant update to Copilot code review on November 6. The REST and GraphQL APIs can now read and write code review settings at every admin tier, closing a gap left by the October 2 API launch, which only let developers request reviews, not administer them.

Enterprise admins can now enable or disable review across the organization. Organization admins can set the default effort level and runner configuration. Repository admins control effort levels and whether a review uses custom instructions or MCP tools. For teams that run Copilot across hundreds of repositories, this turns code review from a per-repo chore into something you can configure from a script.

There is one limitation worth knowing. The enterprise and organization settings endpoints do not support GitHub Apps or fine-grained personal access tokens. Only the repository-level endpoints support both, and they need Administration read or write permission. Plan your automation around that split or you will spend an afternoon debugging authentication errors.

The four-model pipeline behind Balanced reviews

The changelog also disclosed something GitHub had never said before. A Balanced-effort Copilot code review is not a single-model pass. It runs three separate reviewer models in parallel, with a fourth model combining their findings into one comment. GitHub had not previously disclosed that architecture when it made Balanced the default effort level on September 28.

The disclosure explains a cost difference that the documentation already described without explaining. Balanced consumes more AI credits than Lite, and now we know why: four models do the work of one. It also explains why Balanced catches more. Three independent reviewers disagree with each other, and the combiner model has to resolve those disagreements into a single review. That is a real architecture, not a marketing label.

GitHub has not said whether the same structure applies to Lite reviews or only to Balanced. The Max tier, still in public preview, uses several independent review agents across models from different providers, with an aggregation agent reconciling findings. The pattern is consistent: more models, more disagreement, more reconciliation, higher cost, better results.

The changelog adds practical details. Review comments now carry attribution fields showing which skill, MCP server, or custom instructions produced a finding, plus the effort level used. The review overview comment was redesigned into a shorter format, with skipped or excluded files collapsed into one section. A new per-finding feedback control lets a reviewer flag a comment as wrong, nitpicky, or too verbose, which GitHub says it uses to improve the system. Failed or timed-out reviews now retry once automatically and can fall back to another model when the preferred one is unavailable. Billing and preview settings are now preserved when code review is toggled off and back on, fixing a prior source of silent misconfiguration.

Copilot code review metrics now show what developers actually do

A second changelog entry, dated November 5, adds outcome data to the Copilot usage metrics API. A new copilot_code_review object on repository-level reports counts comments evaluated, comments acted on, and merged pull requests where no person requested changes after Copilot's first review. Counts break down by severity, review tier, comment type, and customization.

This is the metric that matters. Earlier reports showed how often reviews ran and how often someone clicked apply on a suggestion. That missed most of the real behavior, because developers act on feedback by editing code directly, asking Copilot to fix it, or replying that the fix comes in a later pull request. The addressed rate, comments acted on divided by comments evaluated, is the first honest number for whether the reviews are useful.

The same week, GitHub added Copilot Chat and the VS Code Agents window to the Copilot impact dashboard, bringing the total to nine tracked experiences. The dashboard's "Passive users" group is now called "Chat-first users," which is a more accurate label for people whose main Copilot interaction is conversation rather than code completion.

What teams should do with this

If you administer Copilot for an organization, three actions follow from this release. First, set a maximum review effort level at the enterprise or organization tier so Max cannot run where its cost is not justified. Max averages about $10 per review against $1.50 for Balanced and $0.25 for Lite, and those costs rise with pull request size. Second, use the new metrics API to track addressed rates per repository, and treat repos with low rates as a signal to tune custom instructions rather than a reason to disable review. Third, check the attribution fields on comments your team disputes. If most bad findings come from one custom instruction file or one MCP server, you have found the problem.

The broader context is the GitHub Octoverse 2026 report, which showed agents now start 40 percent of pull requests. The same week also brought TypeScript 7.1 Beta, which restored the compiler API developers missed. Code review is where that shift meets reality. When agents write the code, someone has to check it, and GitHub is betting that a four-model review plus honest metrics is how teams keep up. The November updates make that bet measurable for the first time.