Enterprise takeaway: Copilot usage reports can now show more of the tools, model requests and customizations behind developer activity, but they still cannot tell you how many useful tasks were completed. GitHub announced two related metrics changes on October 22 and 23, 2026. Together they make it easier to see where usage occurs; they do not turn request counts into productivity or security evidence.

That distinction matters to engineering and FinOps leaders. A team can double its model requests because it is doing more useful work, because an agent now makes several calls per task, or because an integration is repeatedly retrying. The same increase has three different management implications.

What changed in the October 2026 reports

On October 23, GitHub added a totals_by_client array to enterprise, organization and user-level one-day and 28-day usage reports. It can attribute model traffic to clients such as Copilot CLI, editor integrations, agent applications and tools that use Copilot as a model provider. Each client entry includes successful model-request counts, distinct session counts, token usage and a model-level breakdown. Client labels are based on integration identifiers and should be treated as best-effort grouping, not authenticated proof of the calling application’s identity.

On October 22, GitHub expanded visibility into named custom skills, agents, MCP servers, slash commands and plugins. Eligible reports can show up to 25 entries per customization list, rather than five, and include customer-defined names when supported client versions report them. Some activity remains grouped under other or custom. Names are not retroactively added to earlier reporting days.

Four numbers that answer four different questions

Metric What it tells you What it does not prove
Model request count Successful model calls by reported client Number of human prompts or finished tasks
Token usage Prompt and output token volume reported by client/model Exact invoice cost without pricing and billing rules
Session count Distinct reported client sessions Unique people or productive work sessions
Customization interactions Events such as skill invocations or MCP connection attempts Tool executions, security approval or business outcomes

GitHub explicitly warns that a single prompt can generate multiple model requests. It also distinguishes MCP connection and reconnection attempts from calls made through an already connected server. A plugin interaction may already be counted as a skill interaction, so adding the two figures together can double-count activity. These are not accounting technicalities; they change the meaning of an executive dashboard.

Build a three-layer measurement model

Our recommended approach is to separate traffic, work and outcomes. The first layer uses available platform telemetry: requests, sessions, tokens, model selection and customization events. The second uses application records: which approved task was attempted, how many retries occurred, what tools were called and whether a human had to intervene. The third uses business evidence: a pull request merged after review, a defect fixed without regression, a support case resolved or a deployment completed.

Consider a coding assistant asked to update a dependency. It may make eight model requests, start one session and invoke a custom skill twice. Those counts are useful for capacity and cost analysis. They do not establish that the dependency was updated safely. A code review, passing tests and a confirmed deployment are different evidence. CorpExcellence’s earlier article on measuring durable agentic fixes explains why generated changes should not be confused with successful remediation.

Use model-selection data carefully

The new client breakdown includes model_selection_mode, which can distinguish a model explicitly chosen by a user, selected automatically, or selected by the product. For Copilot code review and cloud-agent requests, GitHub says the mode can be product_selected; some code-review model values are unknown. That is a useful clue for governance, but not a complete causal explanation of a model’s usage or cost.

For FinOps, calculate observed token intensity by workflow only when your application records can reliably join requests to tasks. Keep prompt and output tokens separate where pricing differs. Avoid assigning a dollar amount from telemetry alone without checking current contractual prices, discounts, credit treatment and any caching or billing-specific rules. The related economics of enterprise AI discussion is a reminder to compare cost against actual value, not raw activity.

Where the new telemetry can mislead

GitHub’s documentation notes that client telemetry can undercount activity when versions are outdated or telemetry is unavailable. For named customization reporting, prompt mode, the app and Agent Client Protocol integrations require Copilot CLI 1.0.97 or later, while SDK integrations require version 1.0.21 or later. Built-in IDE chat telemetry does not supply those names. An absent name may therefore reflect coverage limitations rather than lack of adoption.

Data also arrives with processing delay, and per-user, enterprise and organization reports have different aggregation rules. GitHub’s field reference and interpretation guide should be consulted before combining report shapes. Do not treat client labels as verified identities, telemetry as a security audit log, or customization interaction counts as permission to access a system.

A 30-day measurement plan

  1. Week one: enable the appropriate metrics policy, document eligible report scopes and capture baseline client and model traffic.
  2. Week two: inventory client versions and telemetry coverage; mark unknown or missing fields explicitly.
  3. Week three: join a small set of approved workflows to independent task records such as reviewed pull requests or closed incidents.
  4. Week four: compare tokens per verified outcome, retries per completed task and human review minutes. Review exceptions before changing access or procurement decisions.

Keep this as a small controlled experiment, not an enterprise-wide ranking of individual developers. Metrics designed to measure software traffic can create misleading incentives when used as a substitute for engineering quality. For a broader operating view, pair the numbers with software lifecycle controls and the skills required to review generated code.

The useful question is cost per verified result

The October releases close some important visibility gaps. Leaders can now ask which clients drive requests, which models consume tokens and which customizations are being invoked. The next step is not to reward higher counts. It is to learn which combinations produce reliable, reviewable work at an acceptable total cost.

References

Related posts:

  1. The Real Cost of an AI Agent: Measure Dollars per Completed Task, Not per Token
  2. RAG or Long Context? A Decision Framework for Accuracy, Cost, and Latency
  3. When Should an Enterprise Self-Host an AI Model? A Break-Even Framework
  4. How AI Fits into the Enterprise Technology Stack