I pay for AI coding tools the way most developers do: a subscription here, an API key there, and a vague feeling at the end of the month that the numbers don't quite add up. The subscription says one thing, the provider dashboard says another, and nobody can answer cleanly — how much of this usage is actually mine, and how much is the tool's own models?
On November 3, 2026, GitHub shipped a change that finally lets teams answer that question for Copilot. The usage metrics API now separates bring-your-own-key (BYOK) usage from Copilot-hosted model usage, and it flags enterprise custom models too. It arrived alongside Dependabot support for Agent Package Manager files and Copilot landing inside JetBrains Air. Together, they say something clear: your coding assistant is no longer one model behind one subscription. It is a mix of hosted models, your own keys, and local models on your own machine — and the reporting is finally catching up.
What actually shipped on November 3
The change is in the Copilot usage metrics API, the endpoint enterprise and organization admins use to see who is using Copilot, how much, and with which models. Until now, if a developer pointed Copilot at their own API key or a local model, those requests blended into the same totals as Copilot-hosted models. That was a real problem, because a local model and a Copilot-hosted model often share the same name — the report could not tell them apart, so the numbers quietly merged.
The November 3 update adds dedicated fields that split them out, at enterprise and organization level, at user level and in aggregate, in 1-day and 28-day reports. It covers two kinds of BYOK.
The first is local BYOK, configured by the developer in their client. Requests go from Copilot CLI or the GitHub Copilot app directly to the developer's own provider key or a local model — including models served by Ollama, Foundry Local, LM Studio, and llama-server, the local-model stack that has gone from hobbyist curiosity to a serious option for teams that want code to stay on their own hardware.
The second is enterprise custom models, configured by an admin in GitHub settings. Those requests route through GitHub to your provider, rather than going direct from the client. Same idea — a model that is not GitHub's — but set up centrally instead of per developer.
The new fields, in plain English
Four new things are worth knowing by name, because you will see them in your reports.
used_local_byok is a per-user flag. It records whether a given user made at least one local BYOK request on that day. It answers the first question any admin asks: who on my team is actually using their own key or a local model?
totals_by_local_byok holds the detail. It breaks down session, request, prompt, and token counts by BYOK kind (local_managed, local_user, local_auto, remote_user) and by surface (copilot_cli or copilot_app). So you can see not just how many tokens went through BYOK, but whether they came from the CLI or the app.
Daily, weekly, and monthly active local BYOK users count distinct BYOK users over time. This is the adoption metric. If you rolled out local models to your team last month, this is the number that tells you whether anyone actually kept using them.
is_custom_enterprise_model is 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. GitHub observes these requests server-side, so the field covers every client, including IDEs — unlike local BYOK, which depends on client telemetry.
One detail I appreciate: if a model is used both as a Copilot-hosted model and as a custom model, it appears as two separate entries, so the counts stay honest. Custom model entries include real request and token counts, not estimates.
Why this matters: the bill problem
Here is the situation this fixes, and I have lived it. A team pays for Copilot seats. Some developers also bring their own keys — maybe they want a model Copilot does not host, maybe they run a local model for privacy, maybe they have credits with another provider to burn down. At the end of the month, the admin opens the usage report and sees a token total. What they cannot see is how much of that total was GitHub's models and how much was the developers' own keys.
The biggest reason is cost, but policy matters too. BYOK spend is invisible in GitHub's billing but very real on your provider invoice. Separating the two lets you see the full picture — seat cost, plus BYOK cost, plus local compute. Without the split, teams double-count or under-count, and both mistakes lead to bad budgeting. And many companies have rules about which models code can go to: some code can go to a hosted model, some cannot leave the building at all — exactly why local models exist. If BYOK usage is invisible, an admin cannot verify the policy is being followed. Now they can see, per user, whether local models are being used and how much traffic goes through them.
The fine print: three caveats
I like this change, but the changelog is honest about its limits, and you should be too.
First, local BYOK fields rely on client telemetry. If a developer has telemetry disabled, their local BYOK usage undercounts — or does not appear at all. The numbers are a floor, not a ceiling.
Second, no backfill. Report days before this release do not include the new is_custom_enterprise_model field. You cannot retroactively split your October usage into hosted and BYOK. Your clean, separated history starts on November 3.
Third, and reassuringly, your existing totals do not change. BYOK usage was already counted — local BYOK is a subset of totals_by_cli and totals_by_copilot_app, and custom model usage was already in totals_by_client. The new fields reorganize the view; they do not add usage. If your totals jump this week, something else changed. One access note: these fields are available to enterprise owners, enterprise billing managers, organization owners, and anyone with a custom role granting the View Copilot Metrics permission, and the Copilot usage metrics policy must be enabled or they will not appear.
Dependabot can now update your agent skills
The same changelog window brought a second change for anyone building with AI agents: Dependabot version updates now support Agent Package Manager (APM).
As AI agents have become part of real workflows, teams keep agent skills, prompts, and instructions in version-controlled files — and those files have dependencies, like any other code. APM is the package manager for that world, with an apm.yml file declaring git dependencies and an apm.lock.yaml locking them down. Until now, keeping those dependencies current was manual work. Dependabot now opens pull requests to update the git dependencies declared in apm.yml, and regenerates apm.lock.yaml when present. You add an apm entry to .github/dependabot.yml, specify the directory and a schedule, and Dependabot treats your agent skills like any other dependency.
One limit: this covers version updates only, not security updates. Dependabot will keep your agent skills current; it will not yet flag them for vulnerabilities. It is generally available on github.com for all plans, and scheduled to arrive in GitHub Enterprise Server 3.24.
I think this is a bigger deal than it looks. The moment your agent's skills and prompts become dependencies, they need the same hygiene as the rest of your codebase — updates, review, and a paper trail. A stale skill file is a stale dependency, and stale dependencies are how small problems become incidents.
What I would do this week
If you manage Copilot for a team, run through this short checklist. First, check the Copilot usage metrics policy is enabled, or none of the new fields will appear. Second, pull a 28-day report and look at the BYOK split — local BYOK usage is spiky, and the 28-day view shows the pattern while the 1-day view shows noise. Third, talk to developers about telemetry; reports undercount when it is off. Fourth, if you keep agent skills in a repository, add the APM entry to Dependabot. And fifth, remember the no-backfill rule: start your baseline now and compare against it next month.
Conclusion
November 3 was not a day of big announcements from GitHub. It was a day of small, precise changes that add up to something meaningful: the Copilot usage API now separates your own-key and local-model usage from Copilot-hosted usage; enterprise custom models are flagged across every client; and Dependabot now keeps your AI agent skills up to date like any other dependency.
This is a reporting improvement, not a product revolution, and I do not want to oversell it. The BYOK split does not make Copilot cheaper or local models faster. What it does is remove a blind spot. The Dependabot change is similar: it does not make your agent skills better, it makes them easier to keep current — the boring reliability work that prevents the exciting failures. But boring reliability work is what turns a clever tool into infrastructure. If you pay for AI coding tools, open your usage report this week and look at the split. You might find your team already uses local models more than you thought. Either way, you will make the next decision with real numbers instead of a feeling. That is not a revolution. It is just good engineering, and it is about time the reporting caught up.
Frequently Asked Questions
What is BYOK in GitHub Copilot?
BYOK stands for bring your own key: pointing Copilot at your own API provider key or a local model instead of only the models GitHub hosts. Local BYOK is configured by the developer in their client — Copilot CLI or the GitHub Copilot app — and requests go directly to the developer's provider or local model, including models served by Ollama, Foundry Local, LM Studio, and llama-server. Enterprise custom models are configured centrally by an admin and route through GitHub to the provider.
What did GitHub change in the Copilot usage API on November 3, 2026?
The usage metrics API now reports BYOK usage separately from Copilot-hosted model usage. New fields include used_local_byok, totals_by_local_byok (session, request, prompt, and token counts by BYOK kind and surface), daily, weekly, and monthly active local BYOK user counts, and an is_custom_enterprise_model boolean flagging enterprise custom model requests. Reports cover enterprise and organization level, at user and aggregate level, in 1-day and 28-day ranges.
Does the BYOK split change my existing Copilot usage totals?
No. BYOK usage was already counted — local BYOK is a subset of totals_by_cli and totals_by_copilot_app, and custom model usage was already in totals_by_client. The new fields reorganize the same usage into separate lines; they do not add new usage.
Why might my local BYOK usage be undercounted?
Local BYOK fields rely on client telemetry, so they undercount when telemetry is disabled on a developer's machine. Enterprise custom models do not have this problem — GitHub observes those requests server-side. There is also no backfill: report days before November 3 do not include the new fields.
What is Agent Package Manager, and what does Dependabot do with it now?
Agent Package Manager (APM) is a package manager for AI agent skills, prompts, and instructions, declared in an apm.yml file with an apm.lock.yaml lockfile. Dependabot version updates now support APM: it opens pull requests to update the git dependencies declared in apm.yml and regenerates apm.lock.yaml when present. It covers version updates only, not security updates. It is generally available on github.com for all plans and scheduled for GitHub Enterprise Server 3.24.
Who can see the new BYOK fields in the usage reports?
Enterprise owners, enterprise billing managers, organization owners, and anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission. The Copilot usage metrics policy must also be enabled — if the fields do not appear, check that policy first.
