Summary: On November 3, 2026, GitHub updated the Copilot usage metrics API to break out bring-your-own-key (BYOK) usage across two forms: developer-configured local BYOK and admin-configured enterprise custom models. Until now these requests blended into Copilot-hosted totals, which made cost-per-user and BYOK policy checks unreliable. If you run Copilot at the enterprise or org level, this is the change that makes your usage dashboards actually reflect who is paying for inference.
Two kinds of BYOK, two data paths
The API now distinguishes local BYOK from enterprise custom models, and the distinction matters because they travel different routes. Local BYOK is what a developer sets up in their own client — a personal provider key, or a locally served model via tools like Ollama, Foundry Local, LM Studio, or llama-server. Requests go straight from Copilot CLI or the Copilot app to that key or model, bypassing GitHub entirely.
Enterprise custom models are the opposite: an admin configures them in GitHub settings, and requests route through GitHub’s servers to your provider. That server-side path means GitHub observes every request regardless of client, including IDEs.
The new fields
For local BYOK, the API adds used_local_byok (a per-user daily flag), totals_by_local_byok (sessions, requests, prompts, and tokens broken out by byok_kind and surface — CLI or app), plus daily, weekly, and monthly active local BYOK user counts. The byok_kind values separate local_managed, local_user, local_auto, and remote_user, which is useful if you need to tell centrally provisioned keys from personal ones.
For enterprise custom models, each totals_by_model[] entry inside totals_by_client gains an is_custom_enterprise_model boolean. One practical detail: if the same model name exists both as a Copilot-hosted model and a custom model, it appears as two entries, so the counts stay clean. All of this lands in enterprise and organization reports at both user and aggregate level, in 1-day and 28-day flavors.
What this changes for your cost reporting
This is a governance and accounting fix, not a new capability. Three things it unlocks:
- Policy enforcement. You can now see exactly who sends requests to their own keys or local models and compare that against your BYOK policy, instead of inferring it from anomalies in the totals.
- Honest cost per user. Usage billed to your own provider, or run on free local models, no longer inflates what Copilot-hosted inference appears to cost. That separation matters even more now that Copilot has shifted to usage-based billing with AI credits — when spend maps to tokens, you need to know whose tokens those are.
- Efficiency comparisons. You can group users by BYOK versus hosted usage and compare against the metrics you already track.
Limits to plan around
Before you build dashboards on this, note the caveats GitHub flags. Existing totals are unchanged — BYOK was already counted, just not separated — so this is purely additive. Local BYOK fields depend on client telemetry and will undercount when it’s disabled; token counts can also fall short because some local providers don’t report usage. Enterprise custom model counts don’t have that problem since GitHub sees them server-side. Local BYOK isn’t broken out by model name, unrecognized custom model names show as unknown, and there’s no backfill — report days before this release simply lack the new field.
Access requires the View Copilot Metrics permission (enterprise owners, billing managers, org owners, or custom roles with it) and the Copilot usage metrics policy enabled.
A sensible first step: pull a 28-day report, compare totals_by_local_byok against your totals for CLI and the Copilot app, and see how much of your previously opaque traffic was personal keys all along. That gap is your real BYOK footprint — and the number to watch as you tighten or loosen policy.
Sources
View the original post on X