GitHub Copilot Usage Metrics: Track Codex, OpenCode, MCP and Custom Agents

GitHub Copilot administrators can now see which developer clients are driving model traffic instead of treating activity outside the IDE as an accounting blind spot. On October 23, 2026, GitHub added a totals_by_client array to Copilot usage metrics reports. It can identify clients such as Codex, OpenCode, Claude Code, Zed, Copilot CLI, the GitHub app, cloud agent, code review, VS Code, and JetBrains.

The change arrived one day after GitHub started exposing configured names for customer-created skills, custom agents, Model Context Protocol (MCP) servers, slash commands, and plugins. Together, the two updates make the Usage Metrics API substantially more useful for platform teams that need to understand how agentic development is actually being adopted.

Fact versus inference: the fields, supported reports, access rules, client list, and telemetry limitations in this guide come from GitHub documentation reviewed on October 24, 2026. The dashboard design, rollout thresholds, and governance workflow are Rubic8 recommendations. They are not GitHub requirements, independent productivity benchmarks, or evidence that one client or model produces better code.

What changed in the Copilot Usage Metrics API

The new totals_by_client array appears in enterprise, organization, enterprise-user, and organization-user reports. It is available in both one-day and 28-day versions; for aggregated 28-day reports, it appears inside each day_totals record.

This is model-traffic reporting. It is different from agent app activity, which counts jobs started by agent apps such as Claude or Codex on GitHub. If an external tool uses Copilot as its model provider, totals_by_client measures its requests and tokens even when the tool does not emit normal editor telemetry.

Why this matters outside the IDE

Developer AI usage no longer fits neatly into an IDE column. A team may use VS Code for editing, Codex for a repository task, OpenCode from a terminal, an MCP server for internal data, and a custom agent for a release workflow. Before the new client dimension, some of that server-side model traffic could be missing from totals_by_ide or difficult to attribute.

The practical value is not surveillance or ranking developers. It is operational visibility. A platform team can answer questions such as:

• Which clients are actually used after an approved-tool rollout?
• Does a sudden token increase come from an IDE, a terminal agent, code review, or a cloud agent?
• Are developers selecting models directly, relying on automatic selection, or using product-selected models?
• Which internal skill or MCP integration needs documentation, support, or retirement?

These are adoption and capacity questions. The API does not prove that a request produced correct code, saved time, or improved a pull request.

Prerequisites and access

The Copilot usage metrics policy must be enabled. Organization reports can be retrieved by organization owners or a custom role with the View Organization Copilot Metrics permission. Enterprise reports are available to enterprise owners, billing managers, or an authorized custom role.

GitHub documents fine-grained read permissions for organization or enterprise Copilot metrics. Classic tokens use the scopes listed for the selected endpoint, such as read:org for organization reports. Prefer a GitHub App or fine-grained token with only the required read permission, store it in a secret manager, and never paste it into a dashboard query, screenshot, log, or online formatter.

Retrieve a 28-day organization report

The API returns temporary signed download links rather than embedding the full NDJSON report in the first response. This example uses the current REST API version shown in GitHub's documentation:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-28-day/latest" \
  -o copilot-report-links.json

Replace ORG with the organization name. The response includes download_links, report_start_day, and report_end_day. Signed links expire, so a scheduled pipeline should fetch the report immediately and store the raw file in access-controlled storage with a collection timestamp.

For daily analysis, use the one-day organization endpoint and an explicit date:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-1-day?day=2026-10-20"

GitHub says recent telemetry can take up to three full UTC days to finalize. Avoid alerting on the newest day as if it were complete. A stable pipeline can ingest daily, mark recent partitions as provisional, and refresh them after the processing window.

Inspect the client breakdown safely

A sanitized client object may look like the example below. The values are illustrative; they are not GitHub benchmarks or data from a real organization.

{
  "client": "codex",
  "request_count": 420,
  "session_count": 38,
  "token_usage": {
    "prompt_tokens": 1250000,
    "output_tokens": 185000,
    "average_tokens_per_request": 3417
  },
  "totals_by_model": [
    {
      "model": "example-model",
      "model_selection_mode": "user_selected",
      "request_count": 280
    }
  ]
}

For local inspection, jq can flatten client rows without sending report data to a third party:

jq -r '
  .day_totals[]
  | .day as $day
  | .totals_by_client[]?
  | [$day, .client, .request_count, .session_count]
  | @csv
' copilot-28-day.json

If you need to inspect a small example in a browser, first remove login names, organization identifiers, repository names, internal agent names, file paths, signed URLs, and tokens. Rubic8's JSON Formatter can make sanitized samples readable, and the JSON Validator can catch malformed JSON. Do not upload a raw Copilot report or temporary download URL to any online tool.

How to interpret client metrics without overclaiming

Requests are not prompts

GitHub explicitly says request_count counts model calls. Agentic clients often make several calls while planning, searching, editing, checking, and summarizing a single task. Dividing requests by employees or prompts can therefore create a misleading utilization ratio.

Tokens are not productivity

A higher token count may reflect a difficult task, a large context, repeated retries, inefficient prompting, or productive multi-step work. It is useful for capacity and cost allocation, but it cannot establish output quality on its own.

Client names are best-effort

GitHub identifies clients using the integration ID attached to requests. Unrecognized values appear as other. Treat the dimension as directional attribution, especially when a proxy, SDK wrapper, or newly released client is involved.

Selection mode needs context

auto means automatic model selection, while product_selected means the product chose the model. Code review and cloud agent requests are product-selected; GitHub notes that code review models may be reported as unknown. Do not interpret unknown as an unauthorized model.

Track skills, custom agents, MCP servers, commands, and plugins

The October 22 update complements client reporting by replacing many generic other or custom labels with configured names. The relevant arrays are:

• totals_by_skill for skill invocations;
• totals_by_custom_agent for custom-agent starts;
• totals_by_mcp for MCP server connection and reconnection attempts;
• totals_by_slash_cmd for slash-command invocations;
• totals_by_plugin for skill invocations associated with a plugin.

GitHub increased each list to as many as 25 entries per record; remaining activity is combined into a trailing other entry. Configured names are trimmed to 128 characters. Values that look like file paths remain grouped under other or custom, which reduces the risk of leaking a local path into a shared report.

Two counting details matter. First, an MCP interaction is a connection or reconnection attempt, not each tool call through an existing connection. Second, plugin interactions are already included in skill interactions. Adding totals_by_plugin to totals_by_skill would double-count that activity.

Coverage gaps to expect

Named customization reporting depends on a supported client path. GitHub lists Copilot CLI interactive and prompt modes, the Copilot app, Agent Client Protocol integrations such as JetBrains, and the Copilot SDK. Prompt mode, the app, and ACP integrations require Copilot CLI 1.0.97 or later; SDK-based reporting requires Copilot SDK 1.0.21 or later.

Names are not reported from an IDE's built-in chat telemetry. Older clients, blocked telemetry, and rollout timing can undercount activity. Historical report days processed before the release keep their previous generic labels; the API does not retroactively reconstruct configured names.

This is why a dashboard should show data freshness, client-version coverage, and the share of other or unknown values. Without those indicators, a clean chart can imply more precision than the telemetry supports.

A practical dashboard model

Start with four panels instead of a single leaderboard:

1. Client adoption: sessions and active reporting days by client, with other shown explicitly.
2. Consumption: requests and prompt/output tokens by client and model-selection mode.
3. Customization adoption: skill, custom-agent, MCP, slash-command, and plugin interactions, with distinct counts beside top entries.
4. Data quality: provisional days, unknown values, missing arrays, and client/version coverage.

Then connect the operational view to outcomes stored elsewhere: pull-request cycle time, review rework, escaped defects, deployment failures, or developer surveys. Keep correlation separate from causation. A team that handles harder repositories may consume more tokens and also have longer review times without the AI tool causing either result.

Privacy and governance checks

Per-user Copilot reports are organizational telemetry and should be handled accordingly. Limit access to people who need it, document the reporting purpose, choose an appropriate retention period, and aggregate before sharing broadly. Review local employment, privacy, and works-council requirements where applicable.

Customer-defined names can also reveal internal project or system language. GitHub recommends reviewing names before reports leave the organization. A safe export process can map sensitive names to stable aliases, exclude user-level rows, remove signed URLs, and publish only aggregate periods that meet a minimum cohort size.

For tool governance, combine observation with explicit policy. The Usage Metrics API tells you what was recorded; it does not approve a client or model. The related Rubic8 guide to the GitHub Copilot Model Policy API covers automated policy retrieval and updates.

Rollout checklist

1. Enable the Copilot usage metrics policy at the required scope.
2. Create a read-only GitHub App or fine-grained token for metrics.
3. Fetch one-day and 28-day organization reports manually.
4. Store raw NDJSON with report dates and collection timestamps.
5. Confirm totals_by_client is present and tolerate an empty array.
6. Check client versions before investigating missing customization names.
7. Refresh recent days after the three-full-UTC-day processing window.
8. Keep request_count, prompts, interactions, sessions, and users as separate measures.
9. Review customer-defined names before any external or executive report.
10. Add outcome data only with a documented definition and cautious interpretation.

Final take

The October updates turn Copilot usage reporting from an IDE-centric summary into a more useful map of agentic development. Administrators can now separate model traffic from clients such as Codex, OpenCode, Claude Code, Copilot CLI, and cloud agents, then inspect which internal skills, agents, MCP servers, commands, and plugins are gaining traction.

The most useful implementation is a governance dashboard, not a developer scorecard. Measure adoption, consumption, coverage, and data quality; keep requests distinct from prompts; and pair telemetry with outcome evidence before making productivity claims.

Official sources

• GitHub Changelog: Usage metrics API adds usage from tools like OpenCode — October 23, 2026
• GitHub Changelog: Custom skills, agents, and MCP servers in usage metrics API — October 22, 2026
• GitHub Docs: REST API endpoints for Copilot usage metrics
• GitHub Docs: Reconciling usage metrics across dashboards, APIs, and reports

Last reviewed: October 24, 2026. GitHub may update fields, client coverage, API versions, permissions, or report behavior after publication.