GitHub Copilot metrics now capture OpenCode and other clients beyond the IDE

GitHub has expanded its Copilot usage metrics API to report model traffic from tools such as OpenCode, Claude Code, Codex and Zed. The change gives administrators a server‑side view of requests and tokens that could be missing from editor‑based reports when an external tool uses Copilot as its model provider. It does not mean that every request made by those tools uses Copilot: the report covers their traffic through Copilot, according to [GitHub’s October 23 changelog](https://github.blog/changelog/2026‑10‑23‑usage‑metrics‑api‑adds‑usage‑from‑tools‑like‑opencode). The new `totals_by_client` array groups that traffic by the client sending the requests. GitHub also lists Copilot CLI, the GitHub app, cloud agent, code review, VS Code and JetBrains among the possible client values. Integrations it does not recognize are grouped under `other`. For an organization choosing which coding tools to support, that supplies a more complete usage inventory than an IDE‑only breakdown. It supplies no evidence by itself that one tool produces better code or saves more work.

The array is available in enterprise, organization, enterprise‑user and organization‑user reports, in both the 1‑day and 28‑day versions. In an aggregated 28‑day response, look inside each `day_totals` entry for `totals_by_client`. Each client entry contains successful model‑request counts, distinct‑session counts, prompt and output token usage, and average tokens per request. The same request and token measures can then be inspected by model in the nested `totals_by_model` breakdown. [GitHub describes the fields and report scope here](https://github.blog/changelog/2026‑10‑23‑usage‑metrics‑api‑adds‑usage‑from‑tools‑like‑opencode). The model breakdown includes `model_selection_mode`, distinguishing a directly requested model (`user_selected`), an automatic choice (`auto`) and a choice made by the product (`product_selected`). Modes not yet reported separately fall under `other`; values GitHub cannot normalize appear as `unknown`. Copilot cloud agent and code review report product‑selected models, and code review’s model name appears as `unknown`. Keeping those buckets in a dashboard preserves the limits of the data instead of silently assigning traffic to a guessed model.

GitHub explicitly warns that `request_count` counts model calls, not prompts. A single prompt can lead to multiple calls, so a tool with a higher request count has not necessarily received more user instructions. Session counts provide another grouping, but the changelog does not establish them as a measure of completed tasks or successful work. [The release explains the counting distinction](https://github.blog/changelog/2026‑10‑23‑usage‑metrics‑api‑adds‑usage‑from‑tools‑like‑opencode). The new client breakdown also differs from GitHub’s agent app activity reporting. Agent app activity counts jobs started by agent apps on GitHub; `totals_by_client` measures requests and tokens sent through Copilot from a client. A job count, a prompt count and a model‑call count should therefore remain separate in a report. Token volume is useful for understanding traffic, but this release does not provide a conversion from those fields to a bill, productivity gain or code‑quality result. Those conclusions need their own compatible billing or outcome evidence.

The API identifies clients using the integration ID sent with each request. GitHub calls that a best‑effort grouping rather than a verified identity. Administrators can use the labels to locate usage patterns and decide where to investigate, but should not treat a label as proof that a particular executable, person or approved deployment made a request. [GitHub’s client‑identification limitation is explicit](https://github.blog/changelog/2026‑10‑23‑usage‑metrics‑api‑adds‑usage‑from‑tools‑like‑opencode). That matters when usage reporting informs governance. The new array describes observed traffic; access controls still need their own configuration and verification. OpenTools’ [coverage of GitHub’s Copilot model‑policy API](https://opentools.ai/news/github‑copilot‑model‑policy‑api‑enterprise‑controls) explains the separate policy‑management change. The two can support the same administrative workflow—review usage, then review policy—but the usage array itself does not establish or enforce which models a team may use.

GitHub says the reports are available to enterprise owners and billing managers, organization owners, and users whose custom organization or enterprise role grants `View Copilot Metrics`. The Copilot usage metrics policy must also be enabled. Teams should check both the requesting role and that policy before diagnosing an access problem as missing client traffic. [The October 23 release lists the access requirements](https://github.blog/changelog/2026‑10‑23‑usage‑metrics‑api‑adds‑usage‑from‑tools‑like‑opencode). The schema change is additive: existing fields are unchanged, and `totals_by_client` is an empty array when there is no usage to report. An empty array should not be turned into a claim that all development activity stopped; it describes the usage available to that report. Existing consumers can retain their current fields while adding client‑level request, session and token views, with `other` and `unknown` kept visible. The [Copilot usage metrics API documentation](https://docs.github.com/rest/copilot/copilot‑usage‑metrics) is the next reference for implementation; OpenTools has not independently tested the endpoints or measured their coverage.