GitHub’s Copilot reports now include model traffic from more clients, including OpenCode. Useful for understanding usage; not a shortcut to measuring whether the work got better.
What you need to know
- Copilot usage reports now have a totals_by_client breakdown.
- Model calls are not the same unit as prompts or finished tasks.
- Client identification is best-effort; usage is not an independent quality score.
A fuller picture of where the requests come from
GitHub announced an addition to the Copilot usage metrics API on 23 October: reports can now group model traffic by client, including tools such as OpenCode. The new breakdown includes requests, sessions and token usage. This helps administrators see activity that was not captured by editor-only reporting. The announcement covers organisation and enterprise reporting; it is not a new public measure of every developer’s productivity.
Do not compare different units as though they were the same
GitHub explicitly distinguishes model calls from prompts: one prompt can lead to several calls. It also describes client identification as a best-effort grouping. Those details matter when somebody turns a dashboard into a league table. A developer dealing with a difficult bug may generate more traffic than a colleague doing routine work. Without the task context, the larger number tells you very little about who achieved a better result.
The question your usage dashboard cannot answer alone
Suppose two teams produce the same number of accepted changes, but one spends far longer correcting generated code. Their request totals might look similar while their experience is quite different. That is an illustrative example, not a GitHub result. Our recommendation is to pair usage with a small set of outcomes you can actually check: accepted work, errors found in review, regressions and time spent fixing the draft.
Use the extra detail to ask better questions
Start by finding unexplained changes in your own workflow rather than ranking individuals. Did the team move to a different client? Did a repeated task become more complicated? Are retries producing traffic without useful output? Take a small sample of completed tasks and inspect it with the people doing the work. Keep the measurement proportionate, explain what is being collected and avoid publishing personal comparisons without the appropriate internal review.
Before you change a subscription
Ask the administrator to check the official metrics policy and access requirements, then make sure your report labels explain their units. Request counts, token totals and quality evaluations belong beside one another, not in place of one another. The AI Wiki entries on tokens, evaluation and benchmarks explain those differences. The cover is an original AI-generated conceptual illustration of measurement, not a dashboard or a representation of real customer data.
HUBAI VIEWCompare completed work and correction effort alongside usage. More requests can mean more activity, more retries or a harder task—not automatically more value.
Buyer decision signal: Usage reporting · announced 23 October 2026
What to verify next
1Label requests, sessions and tokens separately.
2Do not equate traffic with completed work.
3Review a representative sample of actual results.
4Explain internal measurement and protect personal information.
Read the evidence
Capabilities, availability and prices can change. HubAI keeps analysis separate from the underlying official material.
01GitHub Changelog · client usage metrics · 23 October 2026Open source ↗
Business
Business