GitHub expands Copilot metrics to include external tools

Expanding the visibility of AI usage

GitHub has updated its Copilot usage metrics API to provide a more comprehensive view of how people interact with its AI models. Previously, many reports were limited to activity occurring directly within integrated development environments (IDEs). Now, the system captures traffic from a wider variety of external tools.

The update specifically includes model requests and tokens from third-party clients such as OpenCode, Claude Code, Codex, and Zed. It also tracks usage from the Copilot CLI, the GitHub app, cloud agents, and code review tools. This change ensures that administrators can see a more complete inventory of how AI is being used across an entire organization.

As OpenTools reported, this new server-side client breakdown helps identify usage that might have been invisible in editor-based reports. It does not imply that every request made by these tools uses Copilot, but rather it specifically captures the traffic that flows through the Copilot model provider.

How the new metrics are structured

The new data is organized into a totals_by_client array within the existing metrics reports. This array groups traffic by the specific client sending the requests. For each client, the report provides several key data points, including successful model-request counts and distinct-session counts.

Users can also see specific measurements for prompt and output token usage, as well as the average number of tokens per request. These same measures can be inspected by model within a nested breakdown. This allows administrators to see not just which tool is being used, but which specific model is being called by that tool.

The report also distinguishes between different model selection modes. It identifies whether a model was user_selected, an auto choice, or product_selected. If a model name cannot be normalized or is not yet reported separately, it appears as unknown or other to preserve the limits of the available data.

Distinguishing requests from productivity

GitHub includes specific warnings for administrators regarding how these numbers should be interpreted. For example, the request_count field tracks model calls rather than individual user prompts. Because a single prompt can trigger multiple model calls, a high request count does not necessarily mean a tool received more instructions from a human.

Similarly, session counts are provided as a grouping method, but GitHub does not define them as a measure of completed tasks or successful work. The release clarifies that these metrics are intended to show traffic volume rather than providing evidence of code quality or specific productivity gains.

The report also differs from the activity reporting for agent apps. While agent app activity counts the jobs started by those apps on GitHub, the totals_by_client measure tracks the actual requests and tokens sent through Copilot. Administrators must keep these three distinct types of counts separate when analyzing data.

Governance and identity limitations

While the new metrics provide a broader view of traffic, they do not serve as a verified identity check. GitHub identifies clients using the integration ID sent with each request, which they describe as a best-effort grouping. This means a label in the report is not definitive proof of which specific executable, person, or approved deployment made a request.

For organizations using these metrics to inform governance, it is important to understand these limitations. The data describes observed traffic patterns rather than enforcing permissions. Access controls still require their own separate configuration and verification to ensure that only authorized users can access specific models.

Administrators can use these labels to locate usage patterns and decide where to investigate further. However, the usage array itself does not establish or enforce which models a team is allowed to use. It serves as a tool for review, while the policy-management API handles the actual rules and restrictions.

Accessing the new data

The new metrics are available to enterprise owners, billing managers, and organization owners. It is also available to users whose custom roles grant the specific permission to view Copilot metrics. To see the data, the Copilot usage metrics policy must also be enabled within the organization's settings.

The update is additive, meaning that existing fields in the API remain unchanged. If there is no usage to report for a specific client, the totals_by_client array will simply appear as empty. This empty state should not be interpreted as a claim that all development activity has stopped; it only describes the usage available for that specific report.

Existing consumers of the API can keep their current fields while adding the new client-level views. The documentation for the Copilot usage metrics API serves as the primary reference for implementation. OpenTools has noted that they have not independently tested the endpoints or measured the specific coverage of the new data.