← FinOpsAid blog
Copilot can approve pull requests now. Two meters run when it does.
GitHub gave Copilot code review approval authority on September 1, 2026 — an approval that counts toward a repository's required-approvals rule. It's off by default, which is the right default. The cost mechanic is unusual: a review bills AI credits for tokens and GitHub Actions minutes for the agent infrastructure, so a per-user credit budget caps only half of it.
A bot vote that satisfies a merge gate is a governance change. A feature that bills to two different products at once is a cost problem. Copilot code review approvals are both, and the second one is easier to miss because nothing in the announcement mentions money.
It's off by default. That's the correct default, and it means you get to make this decision deliberately instead of discovering it.
What changed
On September 1, 2026, GitHub gave Copilot code review the ability to approve pull requests (GitHub Changelog, September 2026). Two things came with it.
Every Copilot code review now includes an approval assessment in the overview comment, signalling whether the PR looks ready. And where enabled, Copilot can submit an actual approval that counts toward the repository's required-approvals rule.
The controls are sensible. Approvals are off by default and configurable at enterprise, organization and repository level. The feature is in public preview for Copilot Pro, Pro+, Max, Business and Enterprise. And an approval is dismissed when new commits are pushed after it — which turns out to be the detail that decides what this costs.
Two meters run per review
GitHub's billing documentation is specific about how code review is charged, and it names two products: "token consumption is billed in AI credits, and the agentic infrastructure... consumes GitHub Actions minutes" (GitHub Docs, Models and pricing, retrieved 2026-09-09).
That's unusual. Most Copilot features land on one line of the invoice. This one lands on two, under two different products, with two different budget mechanisms behind them.
Cycle count is illustrative; the two-meter billing is documented. Charging model from GitHub Docs, Models and pricing; approval-dismissal behaviour from the September 1, 2026 changelog. Both retrieved 2026-09-09.
There's a second signal about relative expense worth reading carefully, because it's easy to quote out of context. For customers still on legacy request-based billing — annual subscribers who stayed on it after June 1, 2026 — GitHub set Copilot code review at a model multiplier of 13, so one review deducts 13 requests from the monthly quota. Most organizations are on usage-based billing now and pay per token instead. But a multiplier of 13 is GitHub pricing its own feature as an expensive one, and that judgement carries across billing models even though the arithmetic doesn't.
The cost scales with pushes, not pull requests
This is the part to plan around. Copilot's approval is dismissed when new commits are pushed, and a dismissed approval has to be re-earned. If your repository runs Copilot review automatically on push, a PR that takes four rounds of feedback produces four reviews.
So the natural unit of cost here isn't the pull request. It's the review cycle. And review cycles are a function of how your team works — small PRs merged clean cost one cycle, long-lived PRs with iterative feedback cost as many as they take.
That inverts the usual advice, mildly. Squashing work into fewer, larger PRs would reduce cycle count while making each review more expensive in tokens. Splitting work into many small clean PRs raises the cycle count while making each one cheap. Neither is obviously better, and the answer depends on the shape of your review culture rather than on a setting.
What you can control directly is whether re-review is automatic. If it's triggered manually, the cost tracks deliberate requests instead of every push.
Your per-user budget only covers half of it
Here's where the two-meter design actually bites. AI credits, as a bundled product, can be budgeted at enterprise, organization, cost center or per-user level — and a per-user budget is the one scope GitHub always hard-stops. Actions minutes are a separate metered product with their own budget scopes.
So the wall you put in front of a developer's credit consumption does not stand in front of the Actions minutes the same feature consumes. Cap one, and the other keeps metering. That's not a defect, it's just a consequence of a feature straddling two products — but it means "we've budgeted Copilot per user" is not a complete answer for this one.
If you enable approvals broadly, the Actions half needs its own budget at organization or repository level. We covered the credit side's enforcement mechanics in GitHub budgets can now expire, and the Actions side's habit of hiding in a pooled total in Actions costs hiding in plain sight.
The governance question is separate, and it's the bigger one
Cost is the tractable half. The harder question is whether an automated approval should count toward a required-approvals rule at all.
A required-approvals rule exists to make sure a human looked. Letting Copilot satisfy it means the rule now guarantees something different — that a review happened, not that a colleague read the change. For a lot of repositories that's an acceptable trade for velocity on low-risk changes. For anything touching auth, billing, or data handling, it probably isn't.
The configuration granularity is the good news: enterprise, organization and repository level, off by default. That's enough to say yes for the docs repo and no for the payments service, which is the only sensible answer at any real scale. And it's a public preview, so treat today's behaviour as subject to change rather than as a foundation.
Our finding: if you enable this, the number you'll want is review cycles per pull request — and it's harder to get than you'd expect, including from us. Our own pulls connector is deliberately scoped to open pull requests created within a short window, because GitHub's list endpoint carries neither review counts nor comment counts, so enriching every PR costs two extra API calls each. At a hundred PRs across eighteen repositories that's most of a 5,000-request hourly installation budget for one connector. We chose per-day open-PR visibility over a backfilled PR history, and the honest consequence is that we can't reconstruct how many review cycles a closed PR consumed. GitHub's per-user AI credit figure won't tell you either — it's a single daily number with no feature breakdown. The measurable proxy is push frequency on active PRs, which you already have.
Before you enable approvals
- Leave it off where a human approval is the point. Auth, billing, data handling, infrastructure. The default is already off; don't change it there.
- Decide whether re-review is automatic. This is the single biggest lever on what the feature costs, because it decides whether you pay per push or per request.
- Budget the Actions half separately. A per-user AI credit budget doesn't reach it. Set an organization or repository budget for Actions if approvals go on broadly.
- Find out where the review's Actions minutes land on your usage report. GitHub documents that the agentic infrastructure consumes them; confirm how they're attributed in your own breakdown before you scale this, not after.
- Enable it somewhere low-risk first and read both meters for a cycle. A docs repo or an internal tool gives you a real consumption figure at a real review cadence.
- Write down what your required-approvals rule now means. If a bot can satisfy it, the rule's guarantee changed, and the people relying on it should know.
Where FinOpsAid fits
FinOpsAid reads your org read-only and shows both meters in one place — per-user AI credit consumption against your allowance, and Actions minutes by workflow and repository — so a feature that bills to two products doesn't have to be reconciled across two screens. See how to read the GitHub Actions page for the minutes side and how to read the Copilot page for credits. How to read the pull requests page explains the open-PR scoping described above, including what it deliberately doesn't capture. Standing limits: nightly sync, and GitHub's Copilot and billing metrics lag roughly two to three days, so this is a meter reading rather than live monitoring.
Frequently asked questions
Does Copilot code review cost extra?
Yes, on two meters. GitHub's documentation says token consumption is billed in AI credits and the agentic infrastructure consumes GitHub Actions minutes. For customers still on legacy request-based billing, code review carries a model multiplier of 13, so one review deducts 13 requests from the monthly quota.
Can a Copilot approval satisfy a required review?
Where enabled, yes — GitHub says Copilot can submit an approval that counts toward the repository's required-approvals rule. Approvals are off by default and configurable at enterprise, organization and repository level, and an approval is dismissed if new commits are pushed after it was given.
How do I stop Copilot approving pull requests?
Do nothing. Approvals are off by default. If they've been switched on, the setting is configurable at enterprise, organization and repository level, so you can disable it broadly and re-enable it only where an automated approval is acceptable. The feature is in public preview.
Sources
- GitHub, "Copilot code review can now approve pull requests", retrieved 2026-09-09, https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests
- GitHub Docs, "Models and pricing for GitHub Copilot", retrieved 2026-09-09, https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing
- GitHub Docs, "Requests in GitHub Copilot", retrieved 2026-09-09, https://docs.github.com/en/copilot/concepts/billing/copilot-requests
- GitHub Docs, "Setting up budgets", retrieved 2026-09-09, https://docs.github.com/en/enterprise-cloud@latest/billing/how-tos/set-up-budgets
If you want both meters on one screen before you turn approvals on, connect your GitHub org — read-only and free during beta — or explore the demo dashboard first.