GitHub Adds API Requests to Copilot Code Review
REST and GraphQL entry points let teams start Copilot reviews from their own workflows, while Balanced becomes the inherited default unless Lite was explicitly selected.
Edited by Tyronne Panaino
GitHub announced on October 2 that Copilot code review can now be requested through supported REST and GraphQL APIs. Eligible developers can also choose the review effort level for each API request, giving Copilot Pro, Pro+, Max, Business and Enterprise users a way to start reviews from scripts, workflows and internal tools rather than only from GitHub's visible pull-request controls.
The change matters to platform-engineering and software-governance teams because the point that initiates an AI review can now sit inside an existing delivery system. GitHub also says Balanced became the default effort level on September 28 for new and existing repositories and organizations using Copilot code review, except where an administrator or user had explicitly selected Lite.
Review requests move into programmable workflows
The GitHub changelog establishes two separate changes. First, supported REST and GraphQL operations can start a Copilot review. Second, the caller can optionally set the effort level for that individual request.
That combination makes several controlled workflows possible. A team could request review after its own readiness check, connect the request to an internal release process, or expose a reviewed action in a developer portal. Those are practical uses of the new entry point, not promises that every automation should request a review on every change. Teams still need to decide which repositories, events and users may trigger the operation.
The announcement does not publish API rate limits, latency targets, audit examples or a comparison of findings produced by API-triggered and interface-triggered reviews. It therefore supports the availability claim, but not a conclusion that programmable requests improve detection quality or shorten delivery time.
Balanced is now the default, not a locked setting
GitHub says Balanced took effect as the default review effort on September 28. An explicit Lite choice remains in place, and administrators or users can change the setting at the enterprise, organization, repository or personal level they manage. A lower level can override an inherited choice from above.
That hierarchy is important when interpreting a review result. A company-wide default does not prove that every repository used Balanced, because organization and repository overrides may differ. Similarly, an API caller's per-request choice can make an individual review different from the standing default. Teams that need a reliable record should capture both the request parameters and the effective repository configuration.
The source identifies the supported plans and configuration levels, but it does not independently evaluate false positives, missed defects, security coverage or the additional cost of deeper review. Balanced describes the selected effort path; it is not evidence that a review is complete or that tests and human review can be removed.
What teams should verify next
The first operational checkpoint is whether the API operation is available to the intended account and permitted by its Copilot policy. The next is observability: teams should confirm where the initiating identity, chosen effort level, review result and any failure are recorded. A controlled pilot can then compare turnaround time, useful findings and rework against similar pull requests reviewed through the existing interface.
Those measurements would show whether the programmable path improves a particular engineering process. Until then, the supported conclusion is narrower: GitHub has made Copilot code-review requests programmable and has changed the inherited default effort while preserving explicit Lite selections and downstream overrides.
Status
Confirmed. GitHub documents general availability of API-triggered reviews and the Balanced default for the named Copilot plans. Internal confidence is medium because availability and behavior come from one official vendor source, and no independent review-quality or reliability evidence was fetched in this run.
Sources
Update note: Last reviewed 2026-10-03. We will revise this post if GitHub documents material API limits, changes the effort hierarchy or publishes outcome evidence.
Sources
Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.