Copilot Code Review Gets an API and a Balanced Default

You can now ask Copilot for a pull request review from a script instead of a button. GitHub's October 2 changelog says the Copilot code review API works through both REST and GraphQL, with an optional effort level on each request. It is generally available on Copilot Pro, Pro+, Max, Business and Enterprise.

The same post confirms a quieter change that will hit your bill first: Balanced is now the default effort.

What shipped in the Copilot code review API update

• API requests. Reviews can be requested through the REST and GraphQL APIs, so scripts, workflows and internal tools can trigger them. Each request can optionally set an effort level.
• Balanced default. GitHub announced on August 28 that the Default setting would use Balanced. It took effect on September 28 for new and existing repositories and organizations. Repositories that had explicitly picked Lite kept Lite.
• Two levels. Lite and Balanced are the generally available names, replacing the Low and Medium preview names. Per the August changelog, Lite targets straightforward changes and Balanced gives deeper analysis from a higher-reasoning model.

What the announcement leaves out

The changelog gives no endpoint paths, no name for the effort parameter, no billing details and no rate limits. When I checked, I also couldn't find an effort field in the REST reference for review requests. I won't guess at one here.

One cost note does exist elsewhere. The Copilot code review configuration docs say Balanced reviews use more AI credits and may use marginally more GitHub Actions minutes than Lite.

Request a Copilot code review from a workflow

The Copilot code review docs already describe a REST route: request copilot-pull-request-reviewer[bot] as a reviewer. The review requests reference documents the endpoint, POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers, with a reviewers array of logins.

gh api --method POST \
  "repos/<owner>/<repo>/pulls/<pull_number>/requested_reviewers" \
  -f "reviewers[]=copilot-pull-request-reviewer[bot]"

This sends no effort level, so the configured default applies. Whether the new per-request option rides on this same call isn't documented in the sources I read.

Here is the same call as a gate on release pull requests:

name: copilot-review-on-release-pr
on:
  pull_request:
    types: [opened, ready_for_review]
    branches: ["release/**"]
jobs:
  request-review:
    runs-on: ubuntu-latest
    steps:
      - name: Request Copilot review
        env:
          GH_TOKEN: ${{ secrets.REVIEW_TOKEN }}
        run: |
          gh api --method POST \
            "repos/${{ github.repository }}/pulls/${{ github.event.pull_request.number }}/requested_reviewers" \
            -f "reviewers[]=copilot-pull-request-reviewer[bot]"

REVIEW_TOKEN is a secret name you choose, holding a token that can write to pull requests. I haven't confirmed whether the default GITHUB_TOKEN can make this request, so test on a throwaway PR. Don't trust the HTTP status alone: check that a review request actually appears on the PR timeline.

What it means for service and release teams

Reviews can join your change process. A release PR or an internal change ticket can now trigger a review without anyone clicking Reviewers.

The audit trail is built in. Timeline events and the pull request overview comment show which effort level ran. Copy that into your change record.

Your automation cost just went up. Automated triggers on a Balanced default consume more credits than they did on Lite. High-volume repositories may want Lite set on purpose.

Settings stack. Enterprise admins can set a default, and organizations and repositories can override it. In an organization or repository it lives under Settings, Copilot, Code review. Personal settings cover reviews you request, and you can pick a different level for a single manual review without changing the repository default.

Monday morning checklist

1. Open your org's Code review settings and choose Lite or Balanced deliberately.
2. Run the REST call above on a throwaway PR and confirm the review shows up.
3. Wait for the effort parameter and the GraphQL mutation to appear in GitHub's API reference before building on them.
4. Watch AI credit and Actions minute usage for a week.

Re-reviews have a catch: Copilot doesn't re-review new pushes unless automatic review with "Review new pushes" is on, and it may repeat comments you already resolved.

If you ship AI-assisted changes on a schedule, a review you can trigger and log from your own pipeline is worth more than one that depends on someone remembering to click.