GitHub announced on October 23, 2026 that the Copilot usage metrics API can now report model traffic by client. The new totals_by_client array covers tools such as Codex, Claude Code, Copilot CLI, VS Code, JetBrains, cloud agent, code review, and OpenCode. For QA teams, that changes a familiar governance question: not just how much AI is used, but which path generated the traffic behind a test or release workflow.
What GitHub added
According to GitHub, each client entry can include successful model request count, distinct session count, prompt and output token usage, average tokens per request, and a model-level breakdown. The breakdown also records whether a model was user-selected, automatically selected, or product-selected. GitHub says the data is available in the enterprise, organization, enterprise-user, and organization-user one-day and 28-day reports.
This is model traffic, not a measure of prompts or a direct measure of developer productivity. GitHub explicitly notes that one prompt can result in several model calls. Treat the report as operational evidence to investigate, not as a scorecard for individual engineers.
Why this matters for QA engineers
Automation teams increasingly use several AI-assisted routes: an IDE agent to draft Playwright checks, a CLI tool to analyze a failed CI run, or a cloud agent to prepare a pull request. Client-level telemetry can reveal whether an approved tool is actually being used, whether a rollout changed the mix of model calls, and where a sudden token spike originated.
- Baseline a pilot: capture client, model-selection mode, request count, and token volume before enabling a new AI workflow.
- Correlate with quality signals: compare the client mix with flaky-test rate, escaped defects, review rework, and CI duration. Do not infer quality from usage alone.
- Investigate unexpected clients: validate that they are approved integrations and that their access, data handling, and retention settings match policy.
- Keep a human gate: use metrics to prioritize sampling and audits; retain code review and test-evidence requirements for generated changes.
A practical QA rollout check
Start with a small test-automation cohort and choose a fixed observation window. Export the relevant one-day or 28-day Copilot usage report, then group totals_by_client by client and model_selection_mode. Record expected tools before the pilot begins. If a client appears unexpectedly, first confirm its integration identity and business approval; GitHub describes client identification as a best-effort grouping based on the integration ID sent with a request.
Next, review a sample of AI-assisted test changes from each expected client. Check assertions, selectors, test data, environment assumptions, and the CI evidence attached to the pull request. A rise in traffic can be legitimate, but it should be explainable alongside the release workflow and not replace functional validation.
Access and reporting caveats
The Copilot usage metrics policy must be enabled. Access is limited to the appropriate enterprise or organization owners, billing managers, or users granted the documented metrics permission. GitHub also states that totals_by_client is additive and is empty when no usage is available. Build dashboards to handle empty arrays and new client values rather than assuming a fixed list.
For a reliable QA audit trail, preserve the report date range, policy configuration, exported data, and the release or test-quality signals reviewed with it. That makes future comparisons meaningful when tools, models, or adoption patterns change.