GitHub has added per-user AI credit consumption to the Copilot usage metrics API. The new field, ai_credits_used, appears in user-level reports and shows the total AI credits a user consumed across Copilot activity.
The update is small but operationally important. Copilot admins already need to know who is using the product, where adoption is growing, and whether teams are getting value from the developer assistant. Credit consumption adds a budget signal next to those adoption metrics.
GitHub says the field is available in both single-day and 28-day user-level reports at the enterprise and organization levels. It is available to enterprise administrators and organization owners who can access Copilot usage metrics through the REST API.
The metric is useful, but intentionally coarse
The most important limitation is in GitHub’s own notes: ai_credits_used is an overall per-user total. It is not currently broken down by feature, model, or surface. GitHub also says the field is a metrics signal for analyzing consumption, not a billed total; billing remains the place to check invoicing.
That means admins should not overread the number. A user with high AI credit consumption may be doing valuable work, may be experimenting inefficiently, or may be using a task that routes through more expensive model behavior. The API field does not answer which one.
It does, however, tell teams where to look. If a group has strong Copilot adoption and rising credit usage, leaders can compare that against engineering outcomes: faster reviews, more tests, fewer support escalations, shorter cycle time, or better developer satisfaction. If usage rises without an outcome story, the team needs a workflow review.
Copilot is becoming an admin surface
GitHub’s June changelog has been full of Copilot updates: model availability, code review changes, agent finder, auto mode, and enterprise settings. The AI credits field fits that pattern. Copilot is no longer just a code-completion feature that a developer turns on locally. It is a managed platform with models, agents, billing signals, permissions, and policy questions.
That shift changes the buyer. Individual developers still care about speed and code quality. Engineering leaders care about which tasks Copilot handles reliably. Platform and finance teams care about whether usage scales predictably and whether the company can explain the bill.
The new metric helps the last group without solving the whole problem. Per-user consumption is enough to find outliers and trends. It is not enough to decide which Copilot surfaces or model choices are responsible for the cost.
What admins should do with it
The first useful report is not a leaderboard of “expensive users.” It is a comparison of AI credits, active days, and meaningful work signals. A senior engineer who consumes many credits while closing complex migrations may be using Copilot exactly as intended. A low-usage team may need enablement. A high-usage team with no clear output improvement may need guardrails or workflow training.
Admins should also compare 1-day and 28-day windows. The single-day view can catch spikes after a new rollout or incident. The 28-day report is better for normal budgeting and adoption planning.
The missing dimension is task-level attribution. Teams will eventually want to know whether credits are going to chat, code review, CLI, agentic pull requests, model-specific routing, or other surfaces. GitHub does not expose that here. Until it does, admins should treat ai_credits_used as a starting point for investigation, not a complete answer.
The broader enterprise pattern
The Copilot change landed one day after OpenAI announced new ChatGPT Enterprise usage analytics and spend controls. The two updates point in the same direction: enterprise AI is becoming measurable in credits, budgets, and admin APIs.
That is healthy if it makes adoption more accountable. It becomes counterproductive if companies reduce AI value to raw credit minimization. The right question is not “who spent the least?” It is “which AI-assisted workflows produced enough value to justify their cost, and which ones need better routing or training?”
For readers tracking Microsoft’s developer-tool strategy, see our Microsoft company tracker and AI model leaderboard.
