GitHub separates BYOK and custom-model usage in Copilot reports

A clearer view of who is serving the request

GitHub updated Copilot’s usage metrics API on November 3 to distinguish bring-your-own-key activity and enterprise custom models from Copilot-hosted usage. Local BYOK covers client-configured access; enterprise custom models are configured administratively and routed through GitHub.

The distinction appears in organization and enterprise reports. GitHub warns that local telemetry can undercount activity and that historical reports do not backfill the new enterprise-model flag. Existing totals remain unchanged: the new categories describe activity already included, rather than additional usage to add on top. Source: BYOK and enterprise custom models in the Copilot usage API

Why a model name is not enough for cost analysis

Our analysis: the same model label can conceal different delivery routes and billing relationships. A developer may use a hosted entitlement, a separately paid provider account or local infrastructure. Treating all requests under one name as economically identical can produce misleading comparisons.

A useful cost report should distinguish the route through which work was performed. That does not mean request counts become invoices. Provider charges, hardware expense and administrative overhead may need to be reconciled from other records.

Consider a team that moves a portion of its coding tasks to a local model. Copilot usage might remain high while external API charges fall. Whether total cost improved depends on the local resources and support required, along with whether the work still meets the team’s quality needs.

Avoid adding a subset to its parent

The most immediate reporting risk is double-counting. If a dashboard already includes all relevant client activity, adding the new BYOK breakdown as another independent total will inflate the result. The correct relationship is a partition or subset, depending on the field.

Our recommendation is to label these relationships directly in the data model. A report should make clear whether a metric is a total, a component or a distinct-user count. Adding distinct-user counts across overlapping categories can also overstate the number of people involved.

Before changing a management dashboard, compare a small sample of old and new output. Check that the grand totals remain consistent and that the new dimensions explain the existing activity. A schema change should not silently create an apparent jump in adoption.

Missing telemetry is not zero activity

GitHub’s note about local telemetry is material. An incomplete observation can show that activity occurred, but absence from that observation may not establish that no activity occurred. A reporting system should preserve that uncertainty.

For example, comparing teams with different telemetry settings could make one team look less active simply because less information is collected. That is a measurement difference, not necessarily a behavior difference. Reporting coverage alongside usage helps avoid the wrong conclusion.

The same caution applies to tokens. Where a provider does not return a complete count, an apparently efficient workflow may partly reflect missing measurement. A precise-looking chart should not imply greater certainty than the underlying records support.

Usage is not a productivity score

More requests can mean broader adoption, but they can also mean repeated attempts at a task that keeps failing. Fewer requests might reflect efficiency or simply less work. Neither direction establishes productivity without some information about outcomes.

Our recommendation is to pair usage with a small set of task-level measures: completion, review effort and defects discovered after acceptance. Aggregate them carefully enough that the measurement supports improvement rather than simplistic rankings of individual employees.

Policy review is another distinct use. Seeing a route in a report can help an organization check whether its stated model-access policy matches actual practice. It does not automatically enforce that policy or explain why an exception occurred.

The update gives platform teams better categories for understanding a mixed-model environment. The practical benefit comes from interpreting those categories correctly: separate delivery routes, preserve missing-data limits and connect usage to the quality of work delivered.

Keep the reporting change date visible when comparing periods across the release.