Usage metrics API adds usage from tools like OpenCode

GitHub updated its Copilot usage metrics API to capture model activity originating from developer tools outside traditional IDE setups, according to GitHub Changelog's report. The update introduces a new array named totals_by_client across enterprise, organization, enterprise-user, and organization-user reports, bridging visibility gaps left by tools such as OpenCode that historically bypassed standard editor telemetry channels.

This release targets enterprise owners, organization administrators, billing managers, and platform engineers tasked with tracking AI infrastructure consumption and software licensing costs. By tracking consumption at the server layer rather than relying on editor-side reporting, the service surfaces exact model requests, session totals, and token expenditures across diverse programming clients and autonomous agent tooling.

What Usage metrics API shipped

GitHub expanded the Copilot usage metrics API with the totals_by_client array across both 1-day and 28-day versions of its consumption reports. In the rolling 28-day data sets, the array appears inside each day_totals entry. Each record in totals_by_client represents an individual client tool and groups its activities under specific keys: client, request_count, session_count, token_usage, and totals_by_model. The client attribute isolates the specific environment sending API traffic, identifying tools like opencode, claude_code, codex, zed, copilot_cli, github_app, cloud_agent, code_review, vscode, and jetbrains. When an incoming request lacks a standardized classification, GitHub groups the activity under other.

The token_usage object details prompt tokens, output tokens, and the calculated average tokens per request. Inside totals_by_model, administrators receive an identical breakdown of requests and tokens split per model, paired with a model_selection_mode indicator. This mode reveals how the model was invoked: user_selected when an engineer designates the model, auto when an automated heuristic selects it, or product_selected when the hosting platform mandates the backend engine. Unrecognized selection mechanisms default to other, while unnormalizable values are logged as unknown.

What changed for builders in Usage metrics API

Developers and administrators analyzing Copilot consumption can now audit the complete pipeline of tools consuming enterprise seat allocations rather than just IDE extensions. Previously, third-party code editors and standalone agent processes that did not report telemetry left server-side consumption unrecorded within the legacy totals_by_ide schema. The server-level tally isolates request volume and distinct token consumption per application, distinguishing between standard user-driven editor queries and background traffic generated by tools like Zed or Claude Code.

This mechanism differs fundamentally from agent app activity summaries, which only count distinct background jobs initiated by GitHub-hosted agent integrations. The totals_by_client schema records direct model network traffic, tracking exact requests and token allocations regardless of which tool executes the command. Teams can now evaluate tooling adoption and base software governance decisions on real network consumption rather than unverified user feedback.

How to install or upgrade Usage metrics API

Accessing the upgraded schema requires querying the GitHub REST API endpoints for Copilot usage metrics using administrative credentials. Organization and enterprise owners, billing managers, or users assigned custom roles with the View Copilot Metrics permission can fetch reports using GitHub CLI or cURL. The organization or enterprise must have its Copilot usage metrics policy explicitly enabled before queries return valid payload structures.

gh api \
  -H "Accept: application/vnd.github+json" \
  /orgs/ORG/copilot/usage

gh api \
  -H "Accept: application/vnd.github+json" \
  /enterprises/ENTERPRISE/copilot/usage

The resulting JSON payloads now populate the totals_by_client array alongside pre-existing metrics fields. When automated reporting scripts parse the output, the additive payload provides immediate access to model routing and token consumption breakdowns without requiring manual endpoint migrations or infrastructure redeployments.

Gotchas and compatibility in Usage metrics API

The update maintains backward compatibility by treating totals_by_client as an additive schema change. Existing reporting fields remain untouched, and the API returns an empty array for totals_by_client if no qualifying external client usage occurred during the reported window. However, administrators must note that client classification relies on the integration ID transmitted in each request header. Because clients report their own integration IDs, GitHub classifies this naming scheme as a best-effort grouping rather than a cryptographically verified client identity.

Furthermore, request_count metrics represent raw model calls rather than user-facing prompt interactions. A single developer interaction or automated prompt cycle can trigger multiple backend model invocations, meaning engineering leads should not evaluate request_count against raw prompt tallies. Specific automated tools also carry reporting limitations: Copilot code review and Copilot cloud agent requests automatically report product_selected because the internal engine dictates model assignment, while Copilot code review models are recorded with an unknown identifier.

What to watch after Usage metrics API

Engineering organizations should incorporate the totals_by_client array into internal cost-allocation pipelines to observe changes in developer tool selection. Because developers increasingly interact with model APIs through dedicated terminal harnesses, external code review utilities, and terminal editors, monitoring the distribution of user_selected versus auto modes will reveal whether developers prefer controlling their model choices directly or letting system defaults dictate routing.

Platform teams must monitor how unclassified utilities appearing under the other bucket evolve over successive release cycles. As third-party tools adopt standardized integration headers, administrators can verify whether unrecognized traffic shifts into formal categories like opencode or copilot_cli. Tracking these movements will help teams optimize enterprise licensing contracts, retire dormant tooling integrations, and establish accurate usage baselines across corporate software engineering departments.