Introduction of BYOK usage metrics in GitHub Copilot API
GitHub’s Copilot usage metrics API now distinguishes bring your own key (BYOK) activity from Copilot-hosted model usage. The BYOK usage metrics give organizations a clearer account of how developers use their own provider keys, local models and administrator-configured custom models. It adds visibility to activity already included in existing totals, rather than introducing a new category of requests to those totals.
According to GitHub’s announcement, the reports cover two different arrangements: local BYOK configured by developers in their clients, and enterprise custom models configured by administrators in GitHub settings. Both appear in enterprise and organization reports, at the user and aggregate level, in 1-day and 28-day reports.
The distinction matters because model names alone did not reliably separate these arrangements. GitHub says local and custom models often share names with Copilot models, causing BYOK usage to blend into Copilot-hosted totals. The added fields make it possible to distinguish the way a model is used, even when its name does not establish that difference.
For enterprise readers, the central question is what these metrics can establish about governance and usage. They provide a basis for checking observed BYOK activity against organizational policy and separating Copilot-hosted consumption from requests served elsewhere. They also have specific limits: local reporting depends on client telemetry, while enterprise custom model requests are observed server-side. That difference affects how confidently organizations can interpret the resulting counts.
This is therefore a reporting change with practical implications for oversight. It does not, by itself, establish that a particular model is more productive, less expensive or compliant with an organization’s rules. Those judgments require interpreting the usage data in its operational context.
Details on Local BYOK configuration
Local BYOK is configured by developers in their client. GitHub describes requests from Copilot CLI or the GitHub Copilot app as going directly to the developer’s provider key or local model. The category covers both a developer’s own provider key and local models served by tools such as Ollama, Foundry Local, LM Studio and llama-server.
The label “local BYOK” consequently should not be read as meaning that every request runs on a local model. It also encompasses the developer’s own provider key. Keeping that scope in mind is necessary when interpreting local BYOK counts as evidence of where requests are served.
Three groups of fields expose this activity:
| Field | What it reports | Report level |
|---|---|---|
used_local_byok | Whether a user made at least one local BYOK request in Copilot CLI or the Copilot app that day | User |
totals_by_local_byok | Session, request, prompt and token counts, broken out by BYOK kind and surface | User and aggregate |
daily_active_local_byok_users, weekly_active_local_byok_users, monthly_active_local_byok_users | Distinct users with local BYOK activity for the day, calendar week and calendar month | Aggregate |
Within totals_by_local_byok, the byok_kind values are local_managed, local_user, local_auto and remote_user. The surface values are copilot_cli and copilot_app. These identifiers provide breakdowns within local BYOK activity; the announcement does not supply definitions for each BYOK kind, so their names should not be expanded into undocumented behavioral guarantees.
The fields answer different questions. used_local_byok establishes whether an individual had recorded activity on a particular day. The totals describe recorded volume, while the active-user fields describe distinct participation over their specified calendar periods. A boolean indicating activity is not a measure of how heavily someone used BYOK, and a request count is not a distinct-user count.
The calendar definitions also matter. GitHub identifies weekly and monthly active users by calendar week and calendar month. Those definitions should be retained when explaining a dashboard, alongside the separate fact that reports are available in 1-day and 28-day forms.
Local BYOK reporting has an explicit measurement limitation. Its fields rely on client telemetry and undercount when telemetry is disabled. Token counts can also undercount because some local providers do not report token usage. Local counts must therefore be treated as a lower bound. An absence of recorded activity cannot establish that no local BYOK activity occurred, and incomplete token reporting limits comparisons based on token volume.
Overview of Enterprise custom models
Enterprise custom models follow a different configuration and observation path. Administrators configure them in GitHub settings, and requests route through GitHub to the organization’s provider. This distinguishes them from developer-configured local BYOK, both in who establishes the configuration and in how GitHub observes requests.
The API adds is_custom_enterprise_model, a boolean on each totals_by_client[].totals_by_model[] entry. It is true when the request used a custom model configured for the enterprise or organization. Because GitHub observes these requests server-side, the field covers every client, including IDEs.
This client coverage is an important boundary between the two reporting mechanisms. The documented local BYOK surfaces are Copilot CLI and the Copilot app. Enterprise custom model reporting, by contrast, is not limited to those surfaces. A reader comparing the categories needs to account for that difference rather than assuming they describe identical sets of clients.
When the same model is used both as a Copilot-hosted model and as a custom model, it appears as two entries. That preserves separate counts despite the shared model identity. Custom model entries include actual request and token counts, and GitHub says their server-side observation avoids the client-telemetry limitation affecting local BYOK.
Model identification still has limits. Custom model names use the existing normalization, and unrecognized names appear as unknown. A custom model flag therefore identifies the configuration category without guaranteeing that every model will have a recognizable name in the report. Local BYOK usage is not broken out by model name at all.
Together, these details define what comparison is possible. Enterprise custom model reporting supports a model-entry distinction between custom and Copilot-hosted use. Local BYOK reporting offers kind and surface breakdowns, but not a model-name breakdown. Treating both as equivalent model inventories would overstate what the announcement documents.
Impact of separating BYOK from Copilot-hosted totals
The clearest analytical gain is that an existing usage total can now be interpreted with more context. GitHub says local BYOK is already a subset of totals_by_cli and totals_by_copilot_app, while custom model usage is already included in totals_by_client. Existing totals are unchanged.
That accounting relationship is essential for anyone building reports. Adding the newly exposed BYOK counts to their encompassing totals would count the same activity again. The fields describe components of already reported usage. They are useful for distinguishing how requests were served, rather than for increasing the headline volume simply because more detail is available.
GitHub identifies governance as one use of that detail: organizations can see recorded activity involving developers’ own provider keys, local models and enterprise custom models, then check it against their BYOK policy. This supports oversight, but the announcement describes visibility rather than automatic enforcement. A report can inform a policy review without proving that every relevant request was observed, particularly for local BYOK.
The same separation can improve the interpretation of spending. GitHub says organizations can distinguish Copilot-hosted usage from usage billed by their own provider or run on free local models. This helps prevent a cost-per-user analysis from attributing all recorded consumption to what Copilot itself serves. Usage counts nevertheless do not supply provider prices or establish a monetary saving; the announcement provides no pricing comparison.
GitHub also presents the metrics as a way to group users by BYOK or custom model usage and compare them against existing Copilot usage metrics. That is an analytical opportunity, not a demonstrated efficiency result. The supplied evidence contains no benchmark showing that either group performs better. Any interpretation must also preserve the local token-count limitations and the different client coverage of the reporting paths.
Historical comparisons require another qualification: there is no backfill for is_custom_enterprise_model on report days before the release. Earlier reports therefore cannot be assumed to carry the same custom-model distinction. A change in the visibility of that category should not be mistaken for evidence that custom model use began at the same time.
These constraints do not remove the value of the separation. They define it more precisely: organizations gain a clearer classification of recorded consumption, with stronger observation for server-routed custom model requests and incomplete coverage possible for local BYOK.
Access requirements for new metrics
Access is available to enterprise owners, enterprise billing managers, organization owners, and people whose custom organization or enterprise role grants the View Copilot Metrics permission. The Copilot usage metrics policy must also be enabled. Both the role or permission and the policy condition belong in any assessment of whether a user can access the reports.
These requirements connect the reporting change to organizational administration. Developer configuration determines local BYOK use, and administrator configuration establishes enterprise custom models, but access to usage reporting is described through the listed ownership, billing and custom-role permissions. Configuring a model and being entitled to review organizational metrics are separate parts of the documented workflow.
For teams interpreting the new data, the immediate priority is to preserve the meaning of each field. Local activity indicators, volume counts and distinct-user measures answer different questions. Custom model flags distinguish usage within model entries. Existing totals already contain the activity, while historical custom-model flags and complete local telemetry cannot be assumed.
The practical governance improvement is visibility into those distinctions. Organizations can use the reports to examine recorded BYOK activity, understand which usage belongs to Copilot-hosted models, and investigate differences across user groups. The evidence supports that clearer account of consumption; conclusions about cost, policy compliance or efficiency still depend on respecting the reporting boundaries GitHub documents.
