In May 2026, the GitHub Blog published GitHub Copilot is moving to usage-based billing, announcing that Copilot is making a major shift from "per-seat billing" to "token consumption billing." With Copilot Code Review also modified to consume GitHub Actions minutes, the "pay for what you use" model has officially become standard.
In custom development, this marks the end of the era when budgets could be predicted at "$19/month × number of seats." In this article, we outline custom development standard rules for visualizing and governing Copilot usage on a per-project basis to prevent cost explosions.
What changed
The four key points of the new billing system are:
| Item | Old system | New system |
|---|---|---|
| Base billing | From $19 / seat / month | Free seats + token consumption |
| Code Review | Unlimited | Actions minutes consumption |
| Agent mode | Higher tiers only | Based on token consumption |
| BYOK (external models) | Enterprise only | Opened more broadly |
| Monthly reports | Aggregated only | Breakdown by project and model |
The consumption of minutes by Code Review is a point easily overlooked in custom development. In projects requesting automatic reviews from Copilot for every pull request, dozens of hours of Actions minutes may be quietly consumed every month.
This is the latest manifestation of the trend toward frequent Copilot plan revisions discussed in GitHub Copilot Individual Plan Changes, representing an area where operational design must be reviewed continuously when utilized in custom development.
Three tiers of token governance built for custom development
When managing token consumption in custom development, structuring it across three tiers—"Budget," "Visualization," and "Control"—simplifies design.
[Tier 1: 予算(Budget)]
├ 案件単位の月次トークン上限
├ 80% 到達アラート → Slack
└ 100% 到達 → 自動でモデル降格
[Tier 2: 可視化(Visibility)]
├ 開発者単位 / 案件単位 / モデル単位の消費ダッシュボード
├ 週次レポートの自動生成
└ 顧客向け月次明細
[Tier 3: 制御(Control)]
├ 高コストモデルは事前承認制
├ Code Review の自動実行は条件付き
└ BYOK(自前モデル)の利用範囲合意
"Automatic model downgrading" in Tier 1 is an especially cost-effective mechanism; by automatically switching from fast, expensive models to lower-cost models when limits are reached, you can systematically prevent incidents where budgets explode at month-end.
This shares the philosophy of "treating model selection as an operational parameter" discussed in Integrating Vibe Remote Agents into Custom Development with Mistral Medium 3.5, where the crux of cost management in custom development lies in designing model differentiation.
Template for "Copilot terms of use" to write into project contracts
In the era of usage-based billing, custom development contracts must explicitly define the scope of Copilot usage and cost allocation in writing. The key points to cover as contractual clauses are shown below.
| Clause | Details | What the client should verify |
|---|---|---|
| Cost allocation | Explicitly state monthly caps in the contract; negotiate overages | Reasonableness of the cap |
| Target models | List models used in the project | Acceptance of expected costs |
| Code review automation | Criteria for PRs eligible for automated review | Consent to minutes consumption |
| BYOK usage | Permissibility of using custom models | Clarification of data sovereignty |
| Exclusion from training | Exclude code from training data | Plan confirmation |
| Monthly breakdown | Share consumed tokens by model | Ensure transparency |
In particular, if you do not explicitly state "rules for consultation when exceeding caps," additional billing will occur at the end of the month without an agreement on supplementary invoicing, causing a breakdown in the relationship of trust.
Mechanism for visualizing consumption per developer
While you can check consumption per developer in the GitHub Copilot organization management console, it often lacks the granularity needed for custom development. The metrics worth adding to a project dashboard include the following:
- Developer × daily token consumption
- Share by model (GPT-5.5 / Claude / Gemini / proprietary)
- Share by task type (completion / chat / Auto Mode / Code Review)
- Token consumption per PR → ratio to lines of code (cost efficiency)
- Anomaly detection (+200% week-over-week, etc.)
You can visualize these through a combination of GitHub Audit Log + BigQuery + Looker Studio, and putting it into a cycle of reviewing weekly together with developers lets you quickly notice anomalies. This is a theme that should be combined with the concept covered in Vitest 4.1's AI Agent Reporter—"visualizing the quantity and quality written by AI."
Five common pitfalls
Finally, we share common pitfalls in custom development during the era of Copilot usage-based billing.
Pitfall 1: Assuming automated Code Review is free
If you leave Code Review automatically applied to all PRs based on assumptions from the old pricing scheme, there are cases where Actions minutes are consumed at a scale of 100 hours per month. Narrow it down with conditional automated reviews (main branch only, PRs with specific labels only).
Pitfall 2: Leaving Auto Mode running during lunch breaks
If you leave Auto Mode running during your lunch break, it can consume 10% to 30% of your monthly budget in a single lunch hour. Introduce a rule to automatically stop it if there is no activity for 10 minutes via idle detection.
Pitfall 3: "Actual cost calculation mistakes" with BYOK
When configuring Copilot to use your own OpenAI API key, payments to OpenAI will be incurred separately from Copilot billing. Include the total of both in the project's budget management.
Pitfall 4: Monthly reports being viewed only by developers
In an operational setup where only developers look at consumption reports and PMs or management do not, budget overruns will be discovered at the end of the month. Set up a dashboard that can always be viewed by all three parties: PMs, executive management, and the client's PM.
Pitfall 5: Using individual plans in client repositories
Using a developer's individual Copilot plan in a client's private repository undermines the management of training exclusions and data sovereignty. Enforce the rule of assigning Business / Enterprise seats from the contractor's side for each project.
Summary — From "per-seat billing" to "usage design"
GitHub Copilot's shift to usage-based billing is a change that fundamentally transforms the cost structure of custom development. Previously, discussions were simply about "whether to introduce Copilot or not," but moving forward, the design and operation of "which model to use, for what tasks, and to what extent" will dictate profit margins.
The answer to how much to restrict usage and which tasks to delegate to which models depends on the number of repositories, PR velocity, and who bears the cost under the contract. Because this is not a one-size-fits-all matter, the first step is to reconcile your Actions minutes with the monthly Copilot breakdown to grasp what is driving consumption. If you cannot determine measures from the breakdown alone, or are stuck at the stage of formalizing client contract clauses, describe your current situation in the inquiry form. We will help you analyze it.









