GitHub has expanded the Copilot usage metrics API to include activity from agentic CLI customizations. The reports can now expose usage for skills, custom agents, MCP servers, slash commands, and plugins, giving enterprise and organization administrators more data for reporting, adoption analysis, and governance workflows.
The change matters primarily to teams that maintain their own reporting integrations. The new information is available in API reports rather than the Copilot dashboard, and it comes with important interpretation limits: several fields represent only top activity entries, MCP counts measure connection attempts rather than tool calls, and plugin-associated skill activity overlaps with skill totals.
What changed in the Copilot metrics API
According to GitHub’s announcement, customization activity is now represented in several Copilot usage report formats. The fields are documented for per-user one-day and 28-day reports, aggregated enterprise and organization one-day reports, and day_totals records in aggregated 28-day reports.
The relevant top-activity arrays are:
totals_by_skilltotals_by_custom_agenttotals_by_mcptotals_by_slash_cmdtotals_by_plugin
Reports also include distinct-use fields for measuring how many different items recorded activity:
distinct_skill_use_countdistinct_custom_agent_use_countdistinct_mcp_use_countdistinct_slash_cmd_use_countdistinct_plugin_use_count
The documented schema examples show these fields in user-level records and aggregated enterprise day_totals records. The same fields are stated to apply to organization reports.
How to interpret the new fields
The arrays should not be treated as complete inventories. The supplied interpretation guidance says each array can contain up to five entries with the highest interaction counts for that record. An item that does not appear in a top-five array may still have been used.
That distinction is important when building adoption dashboards. A top-five list can help identify commonly used skills, agents, MCP servers, commands, or plugins, but it should not be used by itself to calculate the total number of customizations in use or to prove that an unlisted item has zero activity.
The interaction counts also have category-specific meanings. Skill counts represent skill invocations, custom-agent counts represent custom-agent starts, slash-command counts represent slash-command invocations, and plugin-associated counts represent plugin-associated skill invocations. MCP counts represent connection or reconnection attempts, including failed attempts. They do not represent the number of tool calls made through an already connected MCP server.
There is also an overlap between plugin and skill reporting. Plugin-associated skill activity is included in skill interaction counts, so teams must not add plugin totals and skill totals together as though they were independent activity measures.
At enterprise or organization scope, distinct counts count an identifier once at the aggregate scope rather than once for every user. This makes them useful for measuring breadth of customization activity, but they should be kept conceptually separate from interaction totals.
Customer-defined names are grouped
The reports do not expose every customer-defined customization name. GitHub-provided names can appear as recognized names, while customer-defined skills, custom agents, MCP servers, and plugins are grouped under other. Customer-defined slash commands are grouped under custom.
As a result, the API can support aggregate reporting about customer-defined activity without providing a complete named catalog of those customizations. Administrators should account for that behavior when designing dashboards, ownership reports, or standardization workflows.
Endpoints and access requirements
The REST API reference documents these enterprise report endpoints:
GET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-1-day?day=DAYGET /enterprises/{enterprise}/copilot/metrics/reports/enterprise-28-day/latest
For organization user reports, the documented paths are:
GET /orgs/{org}/copilot/metrics/reports/users-1-day?day=DAYGET /orgs/{org}/copilot/metrics/reports/users-28-day/latest
The usage metrics policy must be enabled for the relevant enterprise or organization. Enterprise access is documented for enterprise owners, billing managers, and authorized users with the View Enterprise Copilot Metrics permission. Organization access includes organization owners and users with View Organization Copilot Metrics permission.
Token requirements depend on the endpoint and token type. The enterprise documentation lists manage_billing:copilot or read:enterprise for OAuth apps and classic personal access tokens, while GitHub App tokens require the Enterprise Copilot metrics read permission. Organization access uses read:org for OAuth apps and classic personal access tokens, or the Organization Copilot metrics read permission for supported fine-grained tokens.
Examples in the REST documentation use the version header X-GitHub-Api-Version: 2026-03-10. The API returns report-download information, including signed URLs with limited expiration periods, so integrations should retrieve and process report files before those links expire.
What this means for engineering teams
Teams that already parse Copilot usage reports will need to update their schemas and processing logic. New arrays and distinct-use fields should be handled explicitly, including empty arrays, zero values, and null or absent customization fields where documented.
For governance, named recognized customizations appearing across many users may indicate candidates for standardization or enablement. At the same time, a large number of other values may indicate broad use of customer-defined items without revealing their individual names. That signal can be useful for deciding where additional internal inventory or policy processes may be needed, but the API itself does not provide those hidden names.
MCP data requires particular caution. A high count may reflect repeated connection attempts or failures rather than successful server use or tool-call volume. Similarly, plugin and skill metrics need separate presentation because their activity can overlap.
What you should do
- Update report schemas and parsers to accept the five
totals_by_*arrays and fivedistinct_*_use_countfields. - Label top-five arrays as partial rankings rather than complete lists of used customizations.
- Keep interaction totals separate from distinct-use counts in dashboards and exports.
- Do not add plugin interaction totals to skill interaction totals.
- Describe MCP activity as connection or reconnection attempts, including failed attempts, rather than tool usage.
- Verify the usage metrics policy, endpoint permissions, API version header, and report-download handling in each integration.
- Restrict downloaded reports and signed links to the administrative workflows and roles that need them.
Availability and remaining limits
The new fields are documented as available in the listed enterprise and organization report formats. Copilot usage metrics generally reached availability across enterprise, organization, and user-level API reporting in February 2026, but the supplied documentation does not establish a separate rollout schedule or backfill date for these CLI customization fields.
The general enterprise documentation says reports are generated daily and that historical data can be accessed for up to one year from the current date. However, the supplied evidence does not confirm that this retention period applies specifically to the new customization fields. It also does not provide a plan-by-plan availability matrix.
For now, the safest implementation is to treat the fields as documented report data, build parsers that tolerate incomplete or unavailable values, and avoid assuming that every historical report contains them.
