Skip to main content
AI Development

Copilot usage metrics now count Claude Code and OpenCode

Copilot reports now break out model requests by tool, including OpenCode, Claude Code and Codex. Use them for tool decisions, not as prompt counts.

Sean McLellan profile photo

Sean McLellan

Lead Architect & Founder

5 min read
Diagram titled Where Copilot model traffic now shows up. Five tool tiles, OpenCode, Claude Code, Codex, Zed and VS Code, point to a box labeled Copilot model requests, which points to a totals_by_client panel listing request_count, session_count and token_usage.
Constructed diagramConstructed diagram based on GitHub's October 23, 2026 changelog. Not product UI.

GitHub added a totals_by_client array to the Copilot usage metrics API on October 23, 2026. It reports Copilot model requests, sessions and tokens for each tool that sent them, including OpenCode, Claude Code, Codex and Zed. Teams that use Copilot as the model provider behind tools outside the IDE can now see which of those tools carry the traffic before deciding which ones to support.

The catch is in what the numbers count. request_count counts model calls, not prompts, and GitHub says the client label is a best-effort grouping, not a verified identity. Treat the new data as evidence for tool and governance decisions, not as a productivity score or a per-person audit trail.

What changed in the Copilot usage metrics API?

The API now reports usage from tools it previously missed. GitHub says many of these tools don't send editor telemetry, so their usage never showed up in totals_by_ide. The new breakdown counts requests on the server instead.

totals_by_client appears in the enterprise, organization, enterprise-user and organization-user reports, in both the 1-day and 28-day versions. In the aggregated 28-day reports it sits inside each day_totals entry. GitHub calls the change additive: existing fields are unchanged, and the array is empty when there's nothing to report. Dashboards that read totals_by_ide keep working.

Each entry carries four things:

  • client: the tool that sent the requests. GitHub lists opencode, claude_code, codex, zed, copilot_cli, github_app, cloud_agent, code_review, vscode and jetbrains as examples. Unrecognized clients are grouped under other.
  • request_count: successful model requests from that client.
  • session_count: distinct sessions from that client.
  • token_usage: prompt tokens, output tokens and average tokens per request.

A nested totals_by_model repeats those metrics per model and adds model_selection_mode. That field says whether the person picked the model (user_selected), Copilot Auto picked it (auto), or the product picked it (product_selected).

How totals_by_client differs from the metrics you already have

Diagram titled Two ways Copilot counts tool usage. The totals_by_ide column says it counts editor telemetry, tools without it go missing, and the field is unchanged. The totals_by_client column says it counts requests on the server, reports requests, sessions and tokens per tool, and its client label is best-effort.
Constructed diagramConstructed diagram based on GitHub's October 23, 2026 changelog. Not product UI.

Copilot reports now have three views of "which tool", and they answer different questions.

Scroll sideways to see all 3 columns.

FieldWhat it countsGood for
totals_by_ideEditor-reported activityIDE adoption trends you already track
totals_by_clientModel requests and tokens, counted on the server, per toolWhich tools use Copilot as a model provider, and how heavily
totals_by_3rd_party_agentJob starts and sessions for agent apps on GitHubAdoption of agent apps such as Claude and Codex running in GitHub workflows

GitHub draws the last line itself. The agent app activity breakdown, added in August, counts jobs started by agent apps on GitHub. totals_by_client measures model traffic from any tool that uses Copilot. A developer running Claude Code in a terminal against Copilot shows up in the new field. A Claude agent app job started from GitHub shows up in the agent app array.

If you already adjusted your trend lines when Copilot app activity joined the existing totals, this change is gentler. It adds a field rather than changing what an old one means.

What the numbers can't tell you

Each limit below comes from GitHub's own notes, and each one rules out a tempting use.

  • Requests aren't prompts. One prompt can trigger several model calls. A tool with a high request_count may be chattier, not more used. Don't compare this field with prompt or interaction counts.
  • The client label isn't proof of identity. GitHub identifies a client by the integration ID sent with each request. GitHub says to treat it as a best-effort grouping, and unrecognized tools fall into other.
  • Code review and cloud agent hide the model choice. Requests from those clients report product_selected, and Copilot code review models are reported as unknown.
  • Missing data isn't zero. An empty array means no usage to report. As with the VS Code Agents fields, keep "no data" and "zero" apart in your importer.

Who can read the new data?

Enterprise owners, billing managers and organization owners can read the reports. So can anyone with a custom role that grants the View Copilot Metrics permission. The Copilot usage metrics policy must be enabled. The REST documentation says the policy must be set to "Enabled everywhere" for the enterprise.

For automation, a fine-grained token needs the "Organization Copilot metrics" organization permission (read). Classic personal access tokens and OAuth app tokens need the read:org scope. The endpoints return signed download links to NDJSON report files, and those links expire.

Why it matters for teams running several coding tools

BaristaLabs' interpretation: this closes a real gap for teams that let developers bring their own agent or editor. Until now, usage through OpenCode, Claude Code or Codex on a Copilot subscription could look like no usage at all. That made it hard to tell whether a tool deserved a support policy, a security review or a polite retirement.

With per-tool requests and tokens, a platform lead can rank tools by actual traffic and token volume. Token volume is the closer proxy for model cost, though GitHub's note doesn't tie the field to billing. Pair it with the Copilot model-policy API and you can check whether the tools people use match the models you allow.

BaristaLabs recommends one bounded exercise before anyone builds a dashboard. Pull the latest 28-day organization report, total request_count and tokens by client, and review the top five tools with their owners.

curl -sL \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-28-day/latest"
# Download each URL in download_links (they expire), then:
jq -s '[.[].day_totals[]?.totals_by_client[]?]
  | group_by(.client)
  | map({client: .[0].client, requests: (map(.request_count) | add)})
  | sort_by(-.requests)' report-*.ndjson

This is a sketch. We haven't run it against a live report, and the report layout may need a different path. Don't sum session_count across days, because a session can span more than one day. For each tool in the table, write down three things: who owns support for it, whether its models fit your policy, and when you'll look again. Anything sitting in other deserves a question before it gets a policy.

Sources and scope

These sources describe the new fields and access rules. They don't give adoption figures, list every recognized client, or say how the new fields relate to Copilot billing.

Copilot governance

Decide which Copilot tools you support

Bring one 28-day Copilot usage report. BaristaLabs can help you read the per-tool breakdown, separate it from agent app activity, and set a support policy your team can keep.

Start with the organization that has the most tools outside the IDE.

Turn this idea into a pilot

Which workflow should go first?

Use the readiness check to compare impact, effort, risk, owner, and next step before requesting a review.

  • 3-5 minutes
  • Deterministic score
  • No sensitive data
Check workflow readiness

Practical AI Workflow Notes

Want more practical AI operations ideas?

Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.

A useful next step if you’re still exploring and not ready to request a 20-minute workflow assessment.

Occasional emails. Practical workflow guidance only. Unsubscribe anytime.