GitHub Copilot Just Separated Your BYOK Spend From Its Own — Here's What the New Usage API Actually Shows You

This post was originally published on ConvertElementor.

I pay for AI coding tools the way most developers do: a subscription here, an API key there, and a vague feeling about where the money actually goes. On November 3, 2026, GitHub shipped a change that finally lets teams answer that question for Copilot.

What actually shipped on November 3

The change is in the Copilot usage metrics API, the endpoint enterprise and organization admins use to see how Copilot is being used. Until now, requests made with your own key or a local model were lumped in with Copilot-hosted usage. The November 3 update adds dedicated fields that split them out, at enterprise and organization level.

There are two kinds of BYOK to know about:

• Local BYOK, configured by the developer in their client. Requests go from Copilot CLI or the GitHub Copilot app to your own provider or a local model like Ollama.
• Enterprise custom models, configured by an admin in GitHub settings. Those requests route through GitHub to your provider, using a model your organization chose.

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 — a per-user flag. It records whether a given user made at least one local BYOK request on that day.
• 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, this is where you see whether anyone actually uses them.
• 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 your enterprise or organization.

One detail I appreciate: if a model is used both as a Copilot-hosted model and as a custom model, it appears in both places, so neither total hides the other.

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 point Copilot at their own API keys or a local model. The Copilot bill looks fine, but the real spend — the API provider invoice, the local GPU time — is invisible in GitHub's billing and invisible in the usage reports. Now the usage API shows both sides of the ledger, so an admin can finally answer "what are we actually spending on AI coding, and where?"

The biggest reason is cost, but policy matters too. BYOK spend is invisible in GitHub's billing but still subject to your organization's policies — which models are allowed, which data leaves the network. You cannot govern what you cannot see.

The fine print: three caveats

I like this change, but the changelog is honest about its limits, and you should be too.

1. Local BYOK fields rely on client telemetry. If a developer has telemetry disabled, their local BYOK usage undercounts — or does not appear at all.
2. 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 now.
3. 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.

Access note: the new fields are visible to enterprise owners, enterprise billing managers, organization owners, and anyone with a custom organization role that includes the View Copilot Metrics permission, and the Copilot usage metrics policy must be enabled or they will not appear.

Bonus from the same changelog: 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 versioned repositories — 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 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. I think this is a bigger deal than it looks. The moment your agent's skills and prompts become dependencies, keeping them updated stops being a chore and starts being a pipeline.

What I would do this week

If you manage Copilot for a team, run through this short checklist: check the Copilot usage metrics policy is enabled, look at the new BYOK fields in your reports, compare them against your API provider invoices, and add an apm entry to Dependabot if your agents use APM skills.

Conclusion

November 3 was not a day of big announcements from GitHub. It was a day of small, precise changes that make AI spending visible and agent workflows maintainable. This is a reporting improvement, not a product revolution, and I do not want to oversell it. But the BYOK split answers a question every team paying for AI coding tools eventually asks: where is the money actually going?

---

Read the full article on ConvertElementor: GitHub Copilot Just Separated Your BYOK Spend From Its Own — Here's What the New Usage API Actually Shows You