GitHub has made Copilot code review requestable through its REST and GraphQL APIs. Teams can now start an AI review from a script, workflow or internal tool, and choose the review effort for each request. The useful opportunity is not to review every pull request automatically. It is to build a risk-aware review gate that starts the right review, records what happened and still leaves the merge decision with a person.
GitHub announced the API support on October 2, 2026. The same update confirmed that Balanced is now the default effort level for repositories and organizations that remain on GitHub's Default setting. The default switch took effect on September 28, 2026. Explicit Lite selections were preserved. Before rollout, verify current plan eligibility, permissions, pricing and API fields in GitHub's documentation because these details can change.
What changed in the GitHub Copilot code review API
The product change has two operational parts:
- A review can be requested through supported REST or GraphQL APIs.
- The request can include an effort choice, allowing a workflow to match review depth to the change.
GitHub documents copilot-pull-request-reviewer[bot] as the reviewer identity for REST review requests. The general review-request endpoint can trigger notifications and secondary rate limiting when called too quickly. Treat retry behavior, deduplication and audit logging as part of the implementation, not as optional polish.
The default also matters. Balanced performs deeper analysis than Lite and can consume more AI credits and slightly more GitHub Actions capacity. A team that previously relied on Default should inspect its current organization and repository settings instead of assuming its former cost and latency profile remains unchanged.
Use a risk router, not a universal trigger
A reliable automation begins with a small decision table. Do not let an AI model decide its own oversight level from an untrusted pull request description. Use deterministic repository metadata and human-owned rules.
| Change signal | Suggested route | Human control |
|---|
| Documentation, copy or isolated test changes | Lite review | Maintainer reviews substantive comments |
| Application logic across several files | Balanced review | Code owner checks findings and tests |
| Authentication, billing, permissions or secrets | Balanced plus specialist review | Named owner must approve |
| Generated files or known noisy paths | Skip or narrow the review | Existing checks remain required |
| Missing ownership, unclear scope or failed checks | Stop and request clarification | No automated merge |
This is a starting framework, not a universal policy. Calibrate it against your repositories, incident history and regulatory obligations.
A five-step implementation pattern
1. Define the eligible pull requests
Write the inclusion rules before writing the API call. Decide which repositories, branches, authors and pull request states qualify. Exclude drafts unless your team intentionally wants early feedback. Add a clear stop condition for missing ownership, sensitive data or an unusually large change.
2. Classify risk with deterministic signals
Use path patterns, labels, changed-file counts and existing ownership rules. For example, changes under authentication or payment paths can require Balanced review plus a named human owner. Avoid inferring developer competence or intent.
3. Request one review idempotently
Before requesting Copilot, check whether the same pull request and head commit already received a request. Store a record containing repository, pull request number, head SHA, route, effort, request time and result. A retry should not produce duplicate reviews.
4. Preserve the human merge gate
Copilot feedback is an input to review, not proof that a change is safe. Required checks, code-owner rules and human approval should remain intact. If Copilot reports no issues, reviewers still need to verify the change against the acceptance criteria and test evidence.
For a human-only approval gate, leave the setting that lets Copilot approvals count toward merge requirements disabled. Verify the repository's auto-approval settings explicitly rather than assuming an AI review cannot satisfy an approval rule.
5. Measure signal, cost and rework
Run a controlled pilot before expanding. Track accepted findings, incorrect findings, duplicated comments, review latency, AI credit use, Actions minutes and human review time. Compare similar pull requests, not unrelated teams or repositories.
Example: a controlled pilot
Consider a hypothetical product team with two repositories. It enables API-triggered reviews only for pull requests labeled ready-for-ai-review. Documentation-only changes route to Lite. Application changes route to Balanced. Authentication and billing paths add a mandatory security-owner review.
For four weeks, the team records each Copilot request against the head commit and asks maintainers to classify each finding as useful, incorrect or already covered by another check. These figures are illustrative, not a benchmark. The team expands the workflow only if it can show useful signal without unacceptable noise, cost or delay.
Operational checklist
- Confirm current Copilot plan eligibility and organization policies.
- Verify the current REST or GraphQL request format in GitHub Docs.
- Use the minimum token permissions required by the endpoint.
- Route effort through deterministic, documented rules.
- Deduplicate requests by pull request and head SHA.
- Keep branch protection, tests and human approval in place.
- Log the selected effort and request outcome.
- Add backoff for rate limits and a manual fallback.
- Review cost, latency and finding quality after a bounded pilot.
- Stop the automation if it creates duplicate requests, bypasses ownership or cannot be audited.
What the API does not prove
API availability does not mean an automated review catches every defect, replaces a security review or makes a pull request ready to merge. Balanced is deeper than Lite, but it is not a guarantee of correctness. GitHub also notes that runner configuration and account policy can affect the available experience.
The durable advantage is orchestration: a team can request review at the right point, apply a consistent risk policy and preserve an evidence trail. The quality of the system still depends on clear scope, reliable tests and accountable human judgment.
Sources
Verified October 3, 2026.
Keep building
