PRUs Are Gone, and Credits Are Now a Budget
On June 1, 2026, GitHub moved every Copilot plan to usage-based billing and replaced the flat per-request PRU (premium request unit) with GitHub AI Credits. One credit converts to $0.01, and the monthly allotments are 1,500 for Pro, 7,000 for Pro+, and 20,000 for Max. What gets deducted is no longer a count of requests but token usage, converted to credits at each model's published rate. So the same review costs different amounts depending on which model read how large a diff.
Code Review Now Also Burns Actions Minutes
From the same day, Copilot code review consumes not just credits but Actions minutes. A workflow that assumed a flat rate and wired "auto-review on every PR" is now running two meters at once — credits and CI execution time. In a setup where every opened PR triggers a review job, the job spends Actions minutes, and the review itself burns credits, both budgets bottom out together at the end of a busy sprint.
Per-User Consumption Finally Becomes Measurable
On June 19, GitHub added a per-user ai_credits_used field to the Copilot usage metrics API and shipped user-level budget controls alongside it. Until then, teams could only see the org-wide total and guess who was spending what; now consumption breaks down per user, surfacing top spenders and anomalous spikes. The first move in any redesign is getting that field onto a dashboard.
Redesigning CI Review for the Metered Era: A Trigger, Model, and Budget Checklist
(a) Pin the budget to numbers before writing code. Track three control metrics: credits per review, per-user daily credits at P95, and a projected budget-exhaustion date. As a starting point, keep a standard PR review at or under 8 credits ($0.08), hold per-user daily P95 below 5% of the monthly allotment (75 credits/day on Pro's 1,500), and require the exhaustion date — remaining credits divided by the trailing 7-day average burn — to always land after the next billing date. Fire an alert the moment any one of the three breaks.
Without those lines, usage-based billing only reveals itself as a month-end invoice. Max's 20,000 credits equal $200, so converting the whole team's burn rate daily into "how many days until this cap is gone" turns an overage from an accident into a predictable event.
(b) Three patterns torch money right after the switch. First, triggering an AI review unconditionally on every PR, so a typo fix or a one-line doc change still has the top-rate model read the full diff. Second, pinning the most expensive flagship as the default review model even though it is overkill for most small changes. Third, keeping per-user consumption off the dashboard, so one or two large refactors drain the team's credits by mid-month while nobody learns the cause until the bill arrives.
The recovery mechanism is the user-level budget control that opened on June 19. Set per-user and per-team budget caps, and when the projected exhaustion date moves ahead of the billing date, respond automatically by narrowing review triggers or downshifting the model a tier. Send a personal budget warning to a spiking spender first, so the whole org's reviews don't stall at once.
(c) Narrow trigger conditions by diff size and path. Skip review on PRs that change fewer than 10 lines or touch only docs and lock files (*.md, *.lock, package-lock.json), and promote only PRs that alter src and core-logic paths. For oversized PRs above 1,500 lines, cap the work: summarize the changed files, then excerpt-review just the risky paths instead of reading the whole thing in one pass.
Assign models in tiers matched to change size. Run a first-pass review with a lightweight, low-cost model on small and medium diffs, and declare a downshift rule in code that escalates to a top-tier model only on high-risk PRs — security paths, migrations, or changes above 1,000 lines. Since tokens are credits, feeding the review prompt only the changed hunks and adjacent context, rather than the whole repository, lowers cost per review on its own.
Lock the log schema down as part of the redesign. Record PR number, trigger reason, model used, credits consumed, Actions minutes, and user ID, and you can aggregate credits per review and per-user P95 on one dashboard. Collect ai_credits_used along the user dimension daily, and spike detection becomes a standing rule rather than a manual hunt.
(d) Run the improvement loop weekly. Revisit the highest-consuming reviews and the most-triggered paths, and push any PR type whose credits-per-review exceeded the cap into the skip list or the downshift rule. When the exhaustion date keeps landing on the billing date week after week, raise the share routed to lightweight models. If none of that shows up in the metrics, what you built is dashboard decoration, not a rule.
Takeaways at a Glance
In a CI where the flat rate is gone, cost is controlled by three levers: triggers, models, and budgets. Narrow the review scope by diff size and path, downshift the model by change risk, and put per-user ai_credits_used and the exhaustion date on a dashboard — then credits per review and P95 stay inside a predictable band within the Max cap of 20,000 credits ($200).
References
Updates to GitHub Copilot billing and plans — GitHub Changelog
AI credits consumed per user now in the Copilot usage metrics API — GitHub Changelog