Custom Copilot Tools Now Have Names in Usage Reports

The Copilot usage metrics API now reports your organisation’s custom skills, agents, Model Context Protocol (MCP) servers, slash commands and plugins under their configured names. Administrators can see which internal customisations developers actually use, then assess adoption after a rollout against the names those customisations already have.

GitHub released the change on October 22, 2026—yesterday—in its usage metrics announcement. It extends the agentic CLI customisation metrics released in September.

Which Copilot reports expose custom names?

Named entries appear in both enterprise and organisation reports: per-user 1-day and 28-day reports, aggregated 1-day reports, and day_totals within aggregated 28-day reports. The affected arrays are totals_by_skill, totals_by_custom_agent, totals_by_mcp, totals_by_slash_cmd and totals_by_plugin.

For an ingestion job consuming a GitHub API, my first checks would be fixed-size assumptions and hard-coded label sets. A consumer that accepts only the old grouping labels now needs to accept configured names as data, not reject them as unexpected values.

Copilot client coverage determines whether names arrive

Custom names come from supported CLI, app, ACP and SDK experiences. An IDE’s built-in chat telemetry does not supply them.

Before planning client updates, I’d establish which experience developers actually use. Checking a CLI dependency and checking an SDK-backed agent experience are different tasks, even though both can feed these reports.

Retrieving a named Copilot usage report

1. Confirm the report reader’s access. The announcement lists enterprise owners, billing managers, organisation owners, and custom organisation or enterprise roles granting “View Copilot Metrics”. For the enterprise endpoint below, I’d follow the more specific requirement in its documentation: enterprise owners, billing managers or authorised users with “View Enterprise Copilot Metrics”.
2. Enable the metrics policy. The API documentation requires the enterprise’s “Copilot usage metrics” policy to be set to Enabled everywhere.
3. Request the latest enterprise report. Replace ENTERPRISE with the enterprise slug and <YOUR-TOKEN> with an appropriately authorised token. This documented request retrieves download links for the latest 28-day report.

   curl -L \
     -H "Accept: application/vnd.github+json" \
     -H "Authorization: Bearer <YOUR-TOKEN>" \
     -H "X-GitHub-Api-Version: 2026-03-10" \
     https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

4. Download the returned report files. Retrieve the files identified by download_links before the signed URLs expire.

OAuth app tokens and personal access tokens (classic) need either manage_billing:copilot or read:enterprise for this enterprise endpoint. A fine-grained token needs the Enterprise Copilot metrics enterprise permission with read access. I’d verify those requirements against this endpoint, rather than assume that satisfying them also establishes access to every organisation report.

The latest report is generated daily and covers a complete 28-day period ending on the most recent processed day. Read the returned report_start_day and report_end_day; those fields identify the period retrieved, rather than leaving the ingestion job to infer it from the endpoint name.

For a dated check, use the documented daily path, /enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY, with DAY in YYYY-MM-DD form. The response supplies report_day. The enterprise endpoints document 200, 403, 404 and 500 responses. I would not let a failed request quietly become an empty usage day: “could not retrieve the report” and “no reported usage” must remain distinct.

Named Copilot reports do not backfill earlier days

Names appear only for report days processed after this release. Earlier days retain their other or custom labels.

I’d read the first appearance of a named custom agent as the point when its identity became visible in the report—not automatically as its first use.

The daily-report documentation gives October 10, 2025 as the availability starting point. Historical access is limited to up to one year from the current date. I would read those statements together: the availability date is not a promise that the entire archive remains retrievable indefinitely.

Client telemetry cannot provide exact Copilot accounting

These reports depend on client telemetry. They can undercount activity, and GitHub explicitly names outdated clients and blocked telemetry as examples of why.

I’d use a named entry to ask whether an internal customisation is gaining reported usage. I would not use it to reconcile every invocation. An absent name leaves an unanswered question: did nobody use the customisation, or did collection miss the activity? The report alone cannot distinguish those cases.

For an AI coding agent, reported usage does not assess whether the output is correct.

Configured Copilot names need an export review

Names are reported as configured, with trimming and a 128-character limit. Names that look like file paths still go under other or custom.

I’d look for labels containing internal information that should not travel with an externally shared adoption report, rather than treating the label columns as harmless context.

When matching a report to an internal catalogue, I’d use each name’s reported form, then check whether trimming or the character limit leaves any ambiguity.