Michael JohnsonWhen a developer accesses Copilot through a third-party tool, standard IDE statistics may not show where requests came from. On October 23, 2026, GitHub added the totals_by_client field to the Copilot usage metrics API, grouping model usage by client, including OpenCode, Claude Code, Codex, and Zed. For administrators, this offers a way to see some activity beyond the editor and have more informed discussions about internal AI usage policies.
What the new breakdown includes
Each entry in totals_by_client specifies the client, the number of successful model calls, the number of sessions, and prompt and output token volumes, along with their average counts per call. The nested totals_by_model breaks these metrics down by model and shows the selection mode: the user selected the model directly, automatic selection was used, or the product selected the model.
The field has been added to daily and 28-day reports for enterprise, organization, and user-level views. In the aggregated 28-day report, client-level details are available for each day. The change is additive: existing fields remain, and the array is empty when no data is available. GitHub described the details in its announcement of the new usage metrics breakdown.
What questions the data can answer
A team can compare the volume of requests and tokens coming through different tools, then decide which integrations to support or include in corporate policies. For example, a growing share of OpenCode in the report may suggest that developers are using Copilot as a model provider outside the IDE. Comparing clients and models can help determine which models are generating most of the actual load.
For budget analysis, it is useful to start with tokens and call counts, then check them against the applicable pricing terms. request_count counts model calls, not user prompts: a single prompt can generate multiple calls. This field is therefore useful for analyzing load on the model service, but not for directly counting developer interactions.
How to incorporate the metric into your workflow
- Check access. The Copilot usage metrics policy must be enabled. Reports are available to authorized enterprise or organization owners, billing managers, and roles with permission to view the relevant metrics.
- Compare equivalent periods. Use a daily report to check changes after enabling a tool, and a 28-day report to assess sustained activity patterns. Separate calls, tokens, and sessions within each report: these are different measures of load.
- Set review thresholds. For example, flag a client whose share of tokens or calls has risen noticeably compared with its own previous period. Choose thresholds based on your requirements and baseline activity; GitHub does not specify a universal threshold.
- Compare the report with access settings. The new breakdown can inform discussions about tool support and management. Reports describe recorded usage; they do not replace permission checks or an inventory of integrations.
The official Copilot usage metrics API documentation describes reports, permission requirements, and available breakdowns. Before automating, check the current schema for the report you need and use the appropriate access permissions.
What the client label means
GitHub identifies the client using the integration ID that the tool sends with a request. The company explicitly describes this grouping as approximate identification: the value helps aggregate traffic, but does not by itself confirm a user’s identity or an application’s authenticity. Unrecognized clients are placed in the other group, while values that cannot be normalized may appear as unknown.
There are also specific exceptions: Copilot code review and Copilot cloud agent calls receive the product_selected selection mode because the product chooses the model; for code review, the model may appear as unknown. This is important to keep in mind when comparing model breakdowns across tools.
The practical takeaway: totals_by_client fills a gap in tracking Copilot server-side calls from external tools and gives administrators new data for analyzing load and making support decisions. To build a reliable picture of usage from this breakdown, compare it with permissions and other internal sources, and treat client names as traffic categories—not as verified identities.