The News, Explained
On October 23, 2026, GitHub announced broader reporting of Copilot model usage from external tools such as OpenCode. The API lets software retrieve usage reports. A new totals_by_client array groups traffic by the tool sending model requests, covering tools that use Copilot as their model provider. Source
The existing totals_by_ide view relied on editor telemetry: usage records sent by development editors, or IDEs. External tools that did not send those records were missing from that view. GitHub says counting model requests on the server fills this gap. Comparisons using the new data therefore need to account for its broader observation scope. Source
Calls, sessions and job starts
A client is the tool sending requests to the model. Each client entry includes successful model calls, distinct sessions, and prompt and output tokens with an average per request. Tokens are pieces of text used to process model input and output. These measures describe different units: Source
| Field or metric | What it counts | Basis for interpretation |
|---|---|---|
request_count | Successful model calls | One user prompt can lead to several calls |
session_count | Distinct sessions for that client | Read separately from request count |
token_usage | Prompt/output tokens and average per request | Compare processing volume within the same period and scope |
| Agent app job starts | Agent app jobs initiated by a user | A job-start event distinct from a model call |
The first three rows describe the new client view; the last describes existing agent app metrics. In those existing metrics, the nested user_initiated_interaction_count counts job starts, while the top-level field with that name counts explicit prompts from other supported telemetry. GitHub warns against adding the two or treating them as interchangeable. Source Source
For a hypothetical example, suppose one prompt leads to three model calls. If all three succeed, they contribute 3 to request_count. This illustrates the unit being counted; the example does not establish how many model calls a real request will generate. Source
Model selection, labels and access
The model breakdown also identifies how a model was selected. user_selected means directly requested, auto means chosen automatically, and product_selected means chosen by the product. Modes not yet reported individually appear as other; values that cannot be normalized appear as unknown. Copilot code review and cloud agent use product_selected because the product chooses the model. Code review model names are reported as unknown. Source
Client labels come from the integration ID sent with each request. Examples include opencode, vscode and copilot_cli; unrecognized clients are grouped under other. GitHub describes this as best-effort grouping rather than verified tool identity. That identification method limits what a report label can establish about the tool. Source
The array is available in enterprise, organization, enterprise-user and organization-user reports, in both 1-day and 28-day versions. Aggregated 28-day reports place it within each day_totals entry. Reports are generated daily, and the latest 28-day period ends on the most recent processed day. Comparisons can use matching reporting scopes and completed periods. Source Source
Access requires the Copilot usage metrics policy to be enabled. The API reference requires the enterprise policy to be set to Enabled everywhere for enterprise endpoints. Eligible viewers are enterprise owners and billing managers, organization owners, and custom roles with the relevant metrics-viewing permission. The change adds fields while preserving existing ones. totals_by_client is an empty array when there is no usage to report. Source Source
OYOPICK’s Take
As teams use Copilot beyond development editors, visibility into previously missed model traffic could help them decide where tool support is needed. The evidence here concerns coverage and processing volume. For a before-and-after assessment, we would first align the newly captured usage paths and reporting periods, then assess actual work outcomes separately.
The fact that client names come from supplied integration IDs should also shape operational decisions. Those labels can help identify tools needing support; stronger actions such as restricting access warrant comparison with the organization’s integration settings. Clearer reporting of coverage changes and client-identification provenance could help turn more visible usage into more dependable tool governance.