A dashboard can count skills, sessions, and model requests without measuring a completed change. Keep those units separate when assessing Copilot adoption or review quality.
October 22: more visible custom tool names
GitHub’s October 22 release adds configured names for skills, custom agents, MCP servers, slash commands and plugins in the usage metrics API. Lists expand from five to 25 entries, with remaining activity grouped into an other entry.
These names come from supported client telemetry. Outdated clients, unsupported experiences, or blocked telemetry can produce incomplete coverage. Earlier report days are not backfilled with the newly available names.
GitHub filters names that look like paths, but configured names can still reveal internal project details. Review exports before sharing them outside the organization.
October 23: requests grouped by client
The next release adds totals_by_client. It includes successful model requests, sessions, token usage, and per-model breakdowns.
Client identification uses the integration ID sent with a request. GitHub describes it as a best-effort grouping. It is not a verified identity for the tool or person behind the request.
Keep these server-side model request counts separate from custom-name telemetry and older agent-application job counts. A user message can lead to several model requests; a request is not a completed task.
Review findings belong in a different measurement
This article originally covered review effort and agent adoption. Earlier review updates added ways to inspect findings and their status. Those states remain useful when interpreted with the actual pull request.
A finding marked resolved means that the review workflow considers it addressed. Check the fixing commit, relevant tests, and any later reopening before treating the state as verified remediation.
Record the review effort and repository policy that applied. Changing the selected review behavior can alter findings or latency without a corresponding change in the quality of the submitted code.
Build two reports with compatible time windows
I would maintain an adoption report for supported clients and customizations, plus an outcome report for accepted changes. Compare them only where the population and reporting windows match.
- Record client versions and known telemetry gaps.
- Label each unit: interaction, session, request, token, or finding.
- Keep missing data distinct from a measured zero.
- Track accepted fixes, reopened findings, and escaped defects.
- Include reviewer time and correction work in the outcome record.
For a new skill rollout, compare the same team before and after release while documenting other workflow changes. Improved reporting coverage can create more named activity even if actual use stays flat.
Check access before designing a shared dashboard
GitHub requires the Copilot usage metrics policy and an eligible role, including a custom role with the View Copilot Metrics permission. Verify report access before distributing a dashboard.
Retain the report date and field definitions with exported data. A future schema change should not silently turn an old series into a different measurement.
Use the counts to locate workflows worth investigating. Productivity evidence comes from the work delivered and the effort required to review and correct it.
Our GitHub AI Scan guide covers advisory and scan boundaries. The Decisions API article shows how to pair model usage with known task outcomes.
Sources
- Named customizations, coverage, access and historical limits
- Client request and token definitions
- Earlier review auto-resolution behavior
Which dashboard number can you connect to an accepted change and a checkable review result?
Checked October 25, 2026. Prepared with AI-assisted research and drafting, with claims checked against the linked sources. MustHave.ai has not performed the proposed product tests.
