GitHub’s new Copilot reporting field gives administrators another way to examine model traffic, but its labels require care. In an October 23 announcement, GitHub introduced totals_by_client for reporting model traffic from tools outside the IDE, such as OpenCode. The central distinction is between a reported client grouping and verified evidence of which application—or person—sent a request.
What the new field reports
According to GitHub, entries contain a client label, successful model-request counts, sessions, token totals, and model breakdowns with selection-mode fields. Coverage includes enterprise, organization, enterprise-user, and organization-user reports for 1-day and 28-day periods.
GitHub distinguishes this model traffic from agent-app activity, which counts jobs started by agent apps. It also says request_count measures model calls, not prompts. Administrators should therefore keep the unit explicit when describing a result: a call total does not establish how many instructions someone typed.
Access still depends on policy and permissions
The REST API reference describes daily and 28-day endpoints that return report download links. It documents enterprise and organization access permissions and says the Copilot usage metrics policy must be enabled everywhere for an enterprise to enable those endpoints.
For administrators preparing to use the reports, the practical starting point is to confirm the intended reporting scope, policy prerequisite, and documented access permissions. Those access questions should remain separate from interpreting the downloaded data. Our related coverage of Copilot’s model policy API examines the distinction between configured controls and effective access.
A client label needs corroboration
GitHub says client identification relies on an integration ID sent with requests. It describes the grouping as best-effort rather than verified identity, and allows grouped or unknown values. That qualification limits how confidently a label can support an attribution decision.
Our recommendation is to treat an unexpected label as a question to investigate. Compare it with your own integration records before using it to make a governance or tool-support decision. This is an operational precaution, not a verification feature GitHub has announced.
The same caution applies to individual accountability. A category in a usage report should not, by itself, become a conclusion about a particular employee’s actions. GitHub’s announcement offers no independent validation of attribution accuracy.
Documentation leaves field-specific questions open
As of October 25, 2026, KST, the reviewed API reference and public example schema did not show the new field. That omission does not disprove availability; the reason and timing of documentation updates remain unknown.
GitHub’s general metrics guide describes API, dashboard, and NDJSON delivery. It says detailed metrics largely depend on IDE telemetry, while server-side signals can identify active users without populating every dimension. Those general limits do not specify how every caveat applies to this addition.
Its reconciliation guidance also identifies scope, aggregation windows, and freshness as reasons reporting surfaces can differ. Unknown values may appear in API and export data. Administrators comparing reports should account for those documented differences before treating a mismatch as evidence of missing tool activity.
Use activity counts within their limits
GitHub’s interpretation guidance frames metrics as adoption and engagement signals. It cautions that comparisons can reflect differences in users, teams, work, or project complexity, rather than proving productivity impact.
The editorial implication is straightforward: use client-level counts to organize follow-up questions, then corroborate consequential conclusions. They do not independently establish charges, useful work, or code quality. Greater visibility can inform an investigation without settling identity or outcomes.
Sources
- GitHub announcement — October 23, 2026.
- REST API reference.
- General metrics guide.
- Reconciliation guidance.
- Interpretation guidance.
- Example schema.
Undated documentation reviewed October 25, 2026, KST.