GitHub Copilot adds review API controls and a Balanced default

A coding assistant can finish a change before anyone has inspected its consequences. GitHub’s October 2, 2026 update makes it easier to connect Copilot review to that inspection step: your workflow can request a review through REST or GraphQL and choose its effort. We checked the announcement and configuration on October 5. GitHub’s release entry.

This is review automation, rather than a new code-generation model. A creator maintaining a website could request feedback after a change is ready to inspect, instead of remembering a separate review step each time. Choosing that trigger is a workflow decision; the announcement does not establish that more requests produce better code.

The default changed before the API announcement

GitHub says API support is generally available to Pro, Pro+, Max, Business and Enterprise. It also confirms that Default effort switched to Balanced on September 28. An explicitly selected Lite setting was retained. The API announcement date and the default’s effective date should not be treated as one October 2 rollout. Availability and effective dates.

Current documentation describes Lite as a standard review and Balanced as deeper analysis of complex logic, security-sensitive code and changes across services. Balanced uses more AI credits and may use slightly more GitHub Actions minutes. Max review effort is still marked Coming soon; the similarly named subscription does not make that effort option available. Review settings and usage tradeoffs.

That makes the existing settings worth inspecting before adding repeated API triggers. A personal choice is only part of the picture when repository or organization configuration also applies. No exact per-review cost or independently measured detection advantage is established here.

Start with a review you can judge

For an illustrative check, take one small pull request that changes newsletter validation. Write down the expected behavior: a valid address works, an invalid address is rejected, and the confirmation flow remains intact. Request a review, then compare its comments with those requirements and your actual verification results. We have not run this experiment.

A useful comment identifies a reproducible problem or a missing check. A confident description of the code is less useful if the form still fails. Keep human review and application checks in the release process; API-triggered feedback is another input to that decision.

Next action: inspect the current effort setting, request one bounded review and record its useful findings and usage before expanding. The AI output evaluation guide gives acceptance checks, while the Codex workflow guide explains how to make an agent’s change reviewable.