GitHub Copilot Adds Client Usage Metrics: What Small Teams Can Actually Compare

GitHub’s October 23 announcement introduces totals_by_client in enterprise, organization, enterprise-user, and organization-user reports, covering both one-day and 28-day versions. In aggregated 28-day reports, the array appears within each day_totals entry. GitHub describes the change as additive, with existing fields unchanged.

According to GitHub, tools using Copilot as their model provider can lack the editor telemetry needed to appear in totals_by_ide. Server-side request counting addresses that reporting gap. OpenCode is the announcement’s headline example; listed client values also include claude_code, codex, zed, copilot_cli, vscode, and jetbrains.

The scope matters: this is traffic using Copilot, not a census of everything those tools do through every provider. Our analysis is based on the official pages. We have not retrieved an organization’s report or verified coverage through controlled client requests.

Each client entry contains request_count for successful model requests, session_count for distinct sessions, and token_usage covering prompt tokens, output tokens, and average tokens per request. A nested totals_by_model breakdown adds request and token metrics by model.

GitHub explicitly warns that requests count model calls. One prompt can generate several calls, so request totals cannot be compared directly with prompt or interaction counts. A tool with more requests might be performing additional steps within a task. The count alone does not explain whether those steps were useful.

For a small team, that makes these fields useful for describing activity before judging it. Compare successful requests with successful requests over the same reporting period. Keep sessions and tokens in separate columns. Avoid naming a request column “prompts” in a spreadsheet: that small labeling error would change the meaning of every later comparison.

GitHub identifies clients using the integration ID sent with each request. Its announcement calls this a best-effort grouping, not a verified identity. Unrecognized clients appear under other. Treat that bucket as an attribution limitation; it does not establish which specific tool generated the traffic.

The model breakdown includes model_selection_mode: user_selected for directly requested models, auto for automatic selection, and product_selected when the product chooses. Selection modes not yet reported individually appear as other; values that cannot be normalized appear as unknown.

GitHub says Copilot code review and cloud agent requests use product_selected, while code review models appear as unknown. Consequently, a model distribution cannot always be read as developers’ preferences. Preserve these labels in any comparison instead of silently dropping incomplete rows and presenting the remainder as the whole picture.

The new client breakdown differs from agent app activity. GitHub’s agent app activity announcement describes a separate totals_by_3rd_party_agent array whose interaction count measures user-initiated agent app job starts. The October 23 update measures model requests and tokens from tools using Copilot. A job start and a model request describe different events.

This also deserves separate treatment from the customization reporting covered in our analysis of named customization usage metrics. When reviewing a report, first state the question: which client generated traffic, which agent app started jobs, or which customization was used? Combining those questions into one adoption score would hide their different units.

Our editorial recommendation is to maintain separate views with explicit labels. Use traffic to identify where further investigation is worthwhile, then examine the corresponding workflow before changing which tool the team supports.

A proposed first exercise is to examine an already available organization report for a defined period. Record each client’s successful requests, sessions, prompt tokens, and output tokens, retaining other and unknown where present. For a 28-day aggregate, account for the daily placement of totals_by_client rather than assuming one top-level summary.

GitHub’s REST API documentation describes report retrieval through download links and says reports are generated daily. Use the report’s stated dates when comparing periods. The announcement says an empty client array means there is no usage to report; it should not become evidence that developers never opened a particular tool.

Next, ask one concrete question, such as whether a client the team expected to use appears in the breakdown. Investigate unexpected results with the people doing the work. To evaluate usefulness, separately record completed tasks, review effort, and required corrections using the criteria in our coding-assistant evaluation guide. These are suggested checks, not results from a pilot we conducted.

This update is most relevant when a team already uses several Copilot-backed clients and its editor reports leave obvious questions unanswered. A client breakdown can provide a starting point for investigating tool usage. It does not establish code quality, task completion, or developer productivity.

Our recommendation is to add the new fields to an existing review only when they answer a concrete question. Keep the interpretation narrow: requests describe successful model calls, tokens describe reported token volume, and client names remain best-effort attribution. Choose tools using evidence about the work they help complete, with traffic metrics supplying context.