On July 20, GitHub added management of AI credit pools directly to the cost-center billing UI. Copilot Business and Enterprise users can also see credits used in the current billing cycle. The primary source is the July 2026 GitHub Changelog.
Visibility is useful, but a visible budget can still fund low-value work. Teams need a stop rule tied to accepted outcomes.
Do not budget “credits per developer.” Define a workload unit first:
accepted task = a change that passes repository checks,
is reviewed, and remains unreverted for seven days
Your definition may differ, but it must exclude generated work that never ships.
For each cost center, record:
| Field | Example |
|---|---|
| Workload | dependency-update pull requests |
| Monthly credit pool | 10,000 |
| Baseline | human-only completion time |
| Success measure | accepted tasks |
| Guardrail | security findings and reverts |
| Review date | end of billing cycle |
Then calculate:
credits_per_accepted_task = credits_used / accepted_tasks
A group with high usage but few accepted tasks should not automatically receive a larger pool. It should investigate prompts, task selection, review friction, or tool fit.
or reduce an experiment when any condition is true:
This prevents a common failure: celebrating adoption while downstream review and repair absorb the benefit.
A depleted pool can mean two very different things:
The billing UI reveals scarcity. The task ledger reveals value. Product teams need both.
At the review date, choose one action:
Do not change weights after seeing results. Set the rule before the billing cycle starts.
GitHub's exact credit accounting, eligible features, and plan behavior may change. Verify current documentation for your organization. The example values above are illustrative, not measured ROI or a claim about Copilot performance.
The new control answers “How much can this cost center spend?” Your operating model still needs to answer “What outcome makes that spending worth continuing?”