GitHub Copilot Metrics API Separates BYOK Usage: Governance, Cost Reporting and Key Limits

What changed​

GitHub's changelog entry for November 3, 2026 describes two kinds of BYOK. They are configured differently and routed differently, so the API reports them differently.

GitHub's BYOK documentation says there are two separate mechanisms for providing your own LLM keys to Copilot. The usage API now maps onto both.

Both kinds appear in enterprise and organization reports. They appear at user and aggregate level, in 1-day and 28-day reports.

The local BYOK fields​

Local BYOK covers a developer's own provider key. It also covers local models served by tools such as Ollama, Foundry Local, LM Studio and llama-server. GitHub added three groups of fields:

• used_local_byok is a per-user flag. It records whether the user made at least one local BYOK request in Copilot CLI or the Copilot app that day.
• totals_by_local_byok holds session, request, prompt and token counts. It is broken out by byok_kind and by surface. The byok_kind values are local_managed, local_user, local_auto and remote_user. The surface values are copilot_cli and copilot_app. It appears in both user-level and aggregate reports.
• daily_active_local_byok_users, weekly_active_local_byok_users and monthly_active_local_byok_users count distinct users with local BYOK activity for the day, calendar week and calendar month. They appear in aggregate reports.

GitHub lists the four byok_kind values but does not explain what each one means. Don't build dashboard logic that assumes more than the labels say. Check GitHub's API documentation first.

The enterprise custom model field​

GitHub added is_custom_enterprise_model as a boolean on each totals_by_client[].totals_by_model[] entry. It is true when the request used a custom model configured for your enterprise or organization.

Because GitHub sees these requests on its own servers, the field covers every client, including IDEs. That is a notable contrast with local BYOK, which is limited to Copilot CLI and the Copilot app. GitHub's BYOK documentation backs this up. It says enterprise BYOK is handled server-side and affects the models served to users by the Copilot API.

If a model is used both as a Copilot-hosted model and as a custom model, it appears as two separate entries. The counts stay separate, and custom entries carry real request and token counts.

GitHub's reference documentation adds a caveat about totals_by_client. Its request counts are successful model calls, not prompts, and one prompt can trigger several model calls. Don't compare those counts with prompt counts such as totals_by_cli.prompt_count. Model entries are also keyed on both model and model selection mode, so one model can already appear more than once.

Why it matters​

GitHub says BYOK usage used to blend into Copilot-hosted totals, because local and custom models often share names with Copilot models. GitHub pitches four benefits:

1. Governance. You can see who sends requests to their own provider keys, local models or enterprise custom models. You can then check that against your BYOK policy. For Copilot Business and Enterprise plans, local BYOK in IDEs can be disabled by an enterprise or organization policy. The new fields let you compare what is reported against what you intended.
2. Spend analysis. You can separate Copilot-hosted usage from usage billed by your own provider or run on free local models. Cost per user then reflects what Copilot actually serves.
3. One view across tools. You get a single picture of AI usage whichever model or provider developers choose.
4. Efficiency comparisons. You can group users by BYOK or custom model usage and compare them against the Copilot metrics you already track.

This fits a wider trend. Finance and platform teams are trying to govern AI costs as Copilot moves to usage-based billing. A Microsoft FinOps community post on governing Copilot spend notes that billing GitHub through Azure routes the charges, while BYOK moves the consumption. If consumption moves to your own provider, Copilot's own numbers stop telling the whole story. Separate flags help you work out where the rest of the activity went.

Limits to know before you build on it​

GitHub is candid about what the data cannot do.

• No change to existing totals. Local BYOK is a subset of totals_by_cli and totals_by_copilot_app. Custom model usage is already in totals_by_client. If you add the new breakdowns to the parent totals, you will double-count.
• Local BYOK is a lower bound. The local fields rely on client telemetry, so they undercount when telemetry is disabled. Token counts can also be low because some local providers don't report token usage. Enterprise custom model counts are observed server-side and don't share this limitation.
• Model names are limited. Custom model names use the existing normalization, so unrecognized names appear as unknown. Local BYOK usage isn't broken out by model name at all.
• No backfill. Report days before this release don't include is_custom_enterprise_model. A trend line spanning the release date will show custom model usage appearing from nothing. That reflects the data, not a change in behavior.

In practice, a user with local BYOK telemetry switched off is invisible in those fields. An absence of local BYOK activity is therefore not proof that nobody is using their own keys. Treat the numbers as evidence of presence, not proof of absence.

Access and prerequisites​

GitHub says the data is available to enterprise owners, enterprise billing managers and organization owners. It is also available to anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission. The Copilot usage metrics policy must be enabled. GitHub's earlier setup guidance says to set the Copilot usage metrics policy to Enabled under the Copilot section of AI Controls.

GitHub's reference documentation names the corresponding custom-role permissions "View Organization Copilot Metrics" and "View Enterprise Copilot Metrics". It also says the dashboard charts don't include Copilot CLI usage. The API fields are therefore the place to look for local BYOK in the CLI.

Practical advice for admins​

• Start with the user-level flag. Use used_local_byok to list who is routing around Copilot-hosted models, then compare that list with your policy.
• Treat counts as directional. Use them to spot trends and exceptions, not for exact chargeback.
• Keep fields separate in dashboards. Plot hosted, local BYOK and custom model usage as distinct series, and don't sum them into a parent total.
• Mark the release date. Annotate any time series so the missing history before November 3 isn't read as growth.
• Check for unknown names. If custom model entries show up as unknown, the model name didn't match GitHub's normalization. It is not necessarily a misconfiguration.

Bottom line​

This is a modest but useful change. It doesn't add new totals. It lets you separate usage that was already being counted but was hard to attribute. The honest caveat is that the local BYOK data depends on client telemetry. Combine it with your BYOK policy settings and provider-side billing records for a more complete picture.