Skip to content
NewsProduct launch

GitHub exposes Copilot code review's four-model pipeline and opens admin settings to the API

· by

The short version

GitHub's November 6 changelog reveals that Balanced-effort Copilot reviews already run three separate reviewer models merged by a fourth, and adds REST and GraphQL control of code review settings for enterprise, org, and repo admins.

GitHub exposes Copilot code review's four-model pipeline and opens admin settings to the API

A Balanced-effort Copilot code review was never the single-model pass most developers assumed it to be. GitHub's November 6 changelog disclosed that a Balanced review now runs three separate reviewer models in parallel, with a fourth model combining their findings into one comment, per GitHub's changelog. The same update gives enterprise, organization, and repository admins REST and GraphQL control over code review settings for the first time, closing a gap left by the October 2 API launch that only let developers request reviews, not administer them.

What happened

GitHub's changelog entry lists three changes. First, the REST and GraphQL APIs can now read and write Copilot code review settings at each admin tier: enterprise admins can enable or disable review org-wide, organization admins can set the default effort level and runner configuration, and repository admins control effort and whether a review uses custom instructions or MCP tools, per GitHub's changelog. A setting an enterprise locks down can no longer be overridden below it. Second, review comments now carry attribution fields showing which skill, MCP server, or custom instructions produced a finding, plus the effort level used, when that metadata exists. Third, the review-overview comment itself was redesigned into a shorter format: skipped or excluded files collapse into one "Files not reviewed" section, empty sections disappear, and a new per-finding feedback control lets a reviewer flag a thumbs-down comment as wrong, nitpicky, or too verbose, which GitHub says it uses to improve future findings.

Buried in the "other improvements" list is the four-model detail: "Balanced effort reviews now use three reviewer models, with another model combining their findings," per GitHub's changelog. GitHub had not previously disclosed that architecture when it made Balanced the default effort level on September 28.

The cost conversation from October now has an API to match

Pondero covered the September 28 default switch to Balanced and the new AI-credit cost that came with it in an October 4 report. That piece noted the one gap in the original API launch: a developer could request a review and set its effort level through the API, but an admin still had to click through separate enterprise, organization, and repository settings pages to see or change the override chain. This update closes that gap. GitHub's API configuration guide specifies that the enterprise and organization settings endpoints, including the organization's runner endpoint, don't support GitHub Apps or fine-grained personal access tokens; only the repository-level settings endpoints support both, and they need Administration: read or Administration: write permission. An admin scripting a bulk audit of effort-level settings across an organization's repositories can now do it with a classic personal access token and repository administrator access, instead of opening each repository's settings page by hand. The new attribution fields give that same admin a way to see, per comment, whether a finding came from a custom instruction file or an MCP server, which matters for anyone trying to figure out which configuration choice produced a particular flagged issue.

Context

The disclosed four-model Balanced pipeline helps explain why Balanced consumes more AI credits than Lite, a cost difference GitHub's documentation already described without detailing the model count behind it. The changelog's bug-fix list also notes that failed or timed-out reviews now retry once automatically and can fall back to another model when the preferred one is unavailable, and that billing and preview settings are preserved when code review is toggled off and back on, a prior source of silent misconfiguration.

What to watch next

GitHub has not said whether the three-reviewer-plus-combiner structure applies to Lite reviews or only Balanced, nor whether the still-unreleased "Max" effort level, listed as "Coming soon" in GitHub's documentation, will add a fifth model to the pipeline. Admins who scripted around the October API gap should check whether their tooling now needs updating to use the new settings endpoints instead of a UI workaround.

Sources