Copilot code review in October: who pays, how deep it looks, and what it skips

GitHub changed Copilot code review three times in two weeks. Since 28 September the default review depth is Balanced, which uses more AI credits than Lite. On 2 October reviews became available through the API. On 8 October organisations gained the option to pay for reviews themselves instead of drawing on each member's Copilot quota, and to stop people using licenses from outside the organisation to trigger them. Together these make Copilot code review something to configure deliberately, with a budget, rather than a feature left on its defaults.

What changed

The 2 October changelog covers two things. Reviews can now be requested through the REST and GraphQL APIs, with an optional effort level per request, so scripts and internal tools can start them. And Balanced became the default effort level for new and existing repositories and organisations on 28 September, as announced in August. Anyone who had explicitly chosen Lite kept it.

The 8 October changelog adds two controls:

• Who pays. A new setting, "Choose how members with a Copilot license are billed", has two options. Member, the default, bills the member's own Copilot entitlement, and "if the member's quota is exhausted, the code review fails". Organization bills the organisation that owns the repository; it requires AI Credits paid usage to be enabled, and a budget is optional.
• Who can ask. "Only allow Copilot code review to be triggered by authorized users" requires review requests to come from people with a Copilot license provided by your organisation or enterprise. A personal license, or one from another organisation, then can't start a review. Set at organisation level, repository admins can't turn it off.

One small discrepancy: the changelog places the billing setting under Copilot, Policies in organisation settings, while the configuration guide lists it on the Copilot, Code review page. Check both if you can't find it.

What a review costs

The code review documentation gives estimates. A review "typically consumes an estimated $0.05 USD to $1 USD worth of AI credits with Lite effort, and $0.25 USD to $5 USD worth of AI credits with Balanced effort". Larger pull requests and longer custom instructions cost more, and the ranges may change as models change.

That is only one of two cost components. The agentic parts of a review, such as gathering context from the whole repository, run on GitHub Actions and use Actions minutes, which the estimates exclude. Larger hosted runners cost more per minute; self-hosted runners use no Actions minutes.

To see what the default change means, take an illustrative 1,000 reviews a month. At the documented ranges that is $50 to $1,000 of AI credits on Lite and $250 to $5,000 on Balanced, before Actions minutes. "Review new pushes", which reviews each new push to a pull request Copilot is already reviewing, multiplies the count.

Who gets charged

The documentation sets out attribution:

• An automatic review is charged to the pull request's author; a manual request to whoever made it.
• Pull requests opened by Copilot cloud agent are charged first to the human co-author, and to the organisation if that person can't be billed.
• Pull requests from other bots, or reviews a bot requests, go straight to the organisation.
• On Business and Enterprise, organisations can let members without a Copilot license use code review on GitHub.com. Their usage is billed to the organisation as additional paid usage.

Budgets stop reviews. If usage is billed to a person, reviews are blocked when that person hits their budget; if billed to the organisation, when the organisation, cost centre or enterprise limit runs out. Other AI credit features stop at the same point.

Effort level, and what Balanced buys

Lite is described as a standard review with "fast, targeted feedback on common issues". Balanced "routes pull requests to a higher-reasoning model for longer analysis of complex logic, security-sensitive code, and cross-service changes". GitHub's own guidance is to use Balanced for security-sensitive code and multi-service changes, and Lite for routine work.

The level is resolved in a fixed order: a level chosen on the request, then one already used on that pull request, then the requester's setting, then the repository's, then the organisation's, then the built-in Balanced default. A developer's personal choice therefore beats the repository setting. The overview comment on each pull request shows which level was used.

The configuration guide also lists a third level, Max, labelled "Coming soon" and "not available yet". Don't plan around it until it ships.

Three things to know before trusting the review

It doesn't read every file. Dependency management files, such as package.json and Gemfile.lock, log files and SVG files are excluded. A pull request that adds a dependency gets no Copilot comment on the manifest change. That matters now that research shows poisoned rule files can steer agents to the wrong package: dependency changes still need a human or a dedicated tool.

Its instructions come from the branch under review. Copilot reads custom instructions, agent instructions and skills from the head branch, not the base branch, which GitHub presents as a way to test changes to them. It also means a pull request can change the instructions its own reviewer follows. Review changes to those files with care.

Approvals can count, if you let them. Every review includes an approval assessment. When Copilot approvals are enabled, a Copilot approval can satisfy required-approval rules the same way a teammate's would, and new commits dismiss it. The feature is in public preview. At enterprise level the default is disabled everywhere.

Two further points: model switching isn't supported, and code review may use models that aren't enabled on the organisation's Models settings page, which only controls Copilot Chat. The GitHub and Playwright MCP servers are enabled for reviews by default, through a repository setting you can turn off.

What it means for engineering leaders

Code review is becoming a metered service with several payers. Left on defaults, its cost lands on individual quotas, where a busy month means reviews start failing for the busiest authors. Moving the bill to the organisation makes cost visible in one place and stops reviews competing with members' other Copilot use, at the price of needing a budget that someone owns.

Practical takeaways

• Decide who pays. If code review is part of your process, bill the organisation and set a budget sized from the documented per-review ranges.
• Choose the effort level per repository: Balanced for security-sensitive and multi-service code, Lite elsewhere. Remember a developer's own setting overrides the repository's.
• Turn on "Only allow Copilot code review to be triggered by authorized users" if contractors or outside contributors bring their own licenses.
• Leave Copilot approvals off for required reviews until you have compared its approvals with human ones on your own pull requests.
• Keep a human or a dependency tool on manifest and lockfile changes, and protect instruction and skill files with CODEOWNERS.
• Review "Review new pushes" and draft-review settings; they multiply review counts.