GitHub Made Code Review a Metered Utility

As of today, June 1, 2026, every Copilot code review on a private repository consumes GitHub Actions minutes. It also consumes AI Credits, GitHub's new token-based billing unit. The change was announced on April 27 with a five-week runway, and it applies to every Copilot tier: Pro, Pro+, Business, and Enterprise.

The framing from GitHub is operational: Copilot code review moved to an agentic architecture that runs on Actions, so now it bills like Actions. Reasonable on the surface. But the second-order effect is the one that matters to engineering orgs, and it's already visible in the community discussion thread (500+ comments, 952 thumbs-down reactions on the announcement post): when a quality gate costs money per invocation, people stop using it on the cases that cost the most.

What actually changed on June 1

Before today, Copilot code review drew from your existing premium request unit (PRU) allowance. A fixed pool, consumed per request, refilled monthly. Not perfect, but predictable.

Now, a single code review generates two billing events:

1. AI Credits, priced by tokens consumed according to the model's listed API rate. GitHub replaced PRUs with this new unit as part of the broader usage-based billing transition.
2. GitHub Actions minutes, drawn from your plan's included allotment (with overages billed at standard Actions rates). This is because the review agent now runs on GitHub-hosted runners under the hood.

Both costs vary by review. A small diff on a fast model costs less. A large diff, or one where the agent pulls in broad repository context, costs more. That variability is the entire problem.

The perverse incentive nobody asked for

Think about what makes a code review expensive under this model. Large diffs. Complex PRs. Repos with deep dependency graphs where the agent needs to pull in a lot of context to say something useful. In other words: exactly the PRs where review matters most.

A 20-line config change is cheap to review. A 400-line refactor touching shared interfaces is expensive. Under usage-based billing, the rational organizational response is obvious: review the cheap stuff, skip or downgrade the expensive stuff. Cap your Actions budget and let the system fail silently when it hits the limit mid-month.

This isn't hypothetical. The community thread is already full of users reporting that a single agentic code review can consume a significant percentage of their monthly credit allotment. One Pro+ subscriber ($39/month, 7,000 AI Credits) reported burning 1,156 credits on a single review request. Another reported hitting 54% of their monthly quota from one interaction. When the meter is running that fast, the first thing any budget-conscious team will do is restrict which PRs get reviewed.

GitHub even tells you how to cope. Their FAQ literally suggests "using lightweight models for quick questions" and "splitting up planning and implementation requests" to stretch your credits. They're coaching you to make the review shallower so it costs less. That's the incentive structure laid bare.

A quality gate with a variable monthly bill isn't a quality gate

Code review serves a specific function in a CI/CD pipeline: it's a gate. Every PR passes through it. The gate catches bugs, logic errors, security issues, and style drift before they reach production. The value of the gate comes from its consistency. It works because it's applied uniformly.

The moment that gate has a variable cost attached, it stops being a correctness mechanism and becomes a cost optimization problem. Engineering managers start asking questions like: "Which repos should we enable Copilot review on?" and "Can we skip review on draft PRs to save credits?" and "Should we set a diff-size threshold above which we don't trigger the reviewer?"

Those are all reasonable cost-management decisions. They're also all ways to let bugs through. The billing model has turned a technical question ("should this code be reviewed?") into a financial one ("is this code worth reviewing?"). Those are very different questions with very different answers.

Two decisions, one direction

This billing change didn't happen in isolation. Earlier this year, GitHub introduced fast-model routing for Copilot code review, where the system automatically selects lighter (cheaper) models for certain reviews to reduce GitHub's own infrastructure costs. That decision optimizes for GitHub's cost structure. This billing change optimizes for GitHub's cost structure again, but this time pushes the optimization pressure onto the customer.

The pattern: GitHub made two consecutive architectural and pricing decisions that both degrade review consistency. Fast-model routing means the quality of any given review depends on which model happened to be selected. Usage-based billing means the coverage of review across your repo depends on your budget. Neither decision makes the review better. Both make it cheaper for GitHub to operate.

That's not cynicism. It's what happens when the company providing your quality tooling is also the company most exposed to the compute costs of that tooling. The incentives don't align.

Why flat-rate review exists

This is why Tenki prices code review at a flat rate per review. Not per token. Not per minute of compute. A single, predictable price regardless of diff size, context depth, or model cost.

The architectural reasoning is simple: if the cost of reviewing a 400-line PR is the same as reviewing a 20-line PR, there's no financial incentive to skip the big one. Review coverage stays uniform. The quality gate stays a quality gate.

Tenki absorbs the variable compute costs on its side. A complex review costs Tenki more to run than a simple one, but the customer pays the same. That's a deliberate choice: the entity providing the quality gate shouldn't create financial pressure to weaken it.

It also makes budgeting trivial. If your team merges 200 PRs a month, you know what review costs. No monitoring dashboards for credit burn rate. No mid-month conversations with finance about whether you can afford to keep the reviewer enabled.

The billing model is the product decision

When teams evaluate AI code review tools, the conversation tends to focus on model quality, language support, and integration depth. Those matter. But the billing model determines how the tool gets used in practice, and usage patterns determine outcomes.

A per-token code review tool will get used less on the PRs that need it most. That's not a failure of the engineering team. It's rational behavior under the incentive structure the vendor created. The best model in the world doesn't help if your budget says you can't run it on the PR that introduces a new authentication flow.

GitHub's community discussion has over 545 participants and the sentiment is overwhelmingly negative. Users are reporting that Pro+ plans ($39/month) run dry in days of normal usage. One commenter put it clearly: "I did not subscribe to Copilot to babysit token consumption. I subscribed to a coding assistant." Another: "This is no longer a predictable development tool. It feels like a metered billing trap."

That's the correct read. A quality gate that gets cheaper as it gets shallower isn't a quality gate. It's a variable expense with a quality problem attached.