AI, in your work.

More visibility into usage outside the editor

On October 23, GitHub announced `totals_by_client` for the Copilot usage metrics API. Server-side counting captures traffic from tools such as OpenCode that could be missing from the IDE breakdown. GitHub’s announcement.

For technical leads, the benefit is being able to investigate which tools account for usage even when work happens outside the usual editor. That visibility supports better questions about the team’s needs; by itself, it does not establish that a tool produces better results.

What the breakdown contains

Each entry represents a client. These are the main metrics described in the announcement.

Availability, permissions, and dates

The new field covers enterprise and organization reports and their respective user reports, in both one-day and 28-day versions. In 28-day aggregate reports, it appears within each `day_totals` entry, so comparisons should preserve that daily dimension. Announcement and report structure.

Access is available to enterprise owners and billing managers, organization owners, and people with custom roles granting `View Enterprise Copilot Metrics` or `View Organization Copilot Metrics`, depending on the scope. Documented permissions.

The `Copilot usage metrics` policy must be enabled. GitHub specifies `Enabled everywhere` for enterprises and `Enabled` for standalone organizations. API authentication also requires the appropriate permissions for the resource being queried. Enabling the policy and REST reference.

The daily report covers a processed date; the 28-day report covers the latest complete reporting window available. GitHub says data can take up to two full UTC days after each day closes to become available. Comparisons should use the dates recorded in the report. Reporting windows and data freshness.

Two essential limits

One prompt can trigger several model calls. GitHub also identifies clients through the identifier supplied by the integration: the grouping is approximate, rather than a verified identity. Limits in the announcement.

The practical implication is to keep request counts and interaction counts separate. A client label should also be treated as a signal to investigate, without turning it into proof that only authorized tools are in use.

Hypothetical example: fewer calls, more tokens

This Nexo example compares two clients over the same period. The figures are invented, and tokens represent the sum of input and output.

Client B makes half as many calls while consuming more tokens. That difference warrants examining the tasks, context sent, and models used; these numbers cannot establish which client delivers more value.

Nexo’s interpretation: separate usage, adoption, and outcomes

Our interpretation is that the new breakdown provides a better starting point for reviewing the team’s tools and support needs. To assess their usefulness, we suggest combining three perspectives:

• Usage: compare requests and tokens across equivalent periods and scopes.
• Adoption: examine how many people use the tools and how consistently, without equating sessions with users.
• Outcomes: compare trends with work quality, delivery times, and the team’s experience before attributing productivity gains.