# BYOK і enterprise custom models у Copilot usage API: нарешті видно, хто куди шле запити

> Copilot usage metrics API розділив BYOK та hosted-usage. Розбираємось, що саме з'явилось у полях used_local_byok і is_custom_enterprise_model та як це читати.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-11-04
- Категорія: AI в роботі розробника
- Canonical: https://cookiesoftware.io/blog/copilot-byok-enterprise-usage-api

---
GitHub оновив Copilot usage metrics API так, що тепер можна чітко відділити BYOK-трафік (bring your own key) і enterprise custom models від звичайного Copilot-hosted usage. До цього моменту всі ці запити часто змішувались в одних і тих самих лічильниках, бо локальні та кастомні моделі нерідко мають ті самі назви, що й hosted-версії від GitHub.

## Чому enterprise-командам раптом стало важливо, хто куди ходить

Якщо ти адмінишся з Copilot на рівні організації чи enterprise, ти, ймовірно, вже стикався з ситуацією: дашборд показує usage моделі, а ти не можеш сказати напевно – це запит пішов у Copilot-hosted інфраструктуру, чи розробник просто підключив власний ключ до локальної llama-server і ганяв запити повз усі корпоративні політики.

Це не тільки питання бюджету. Це питання governance: чи дотримується команда BYOK-політики, чи код справді не покидає контрольований периметр, і чи той "дешевий" usage – справді дешевий, чи просто рахується деінде. Раніше відповісти на ці питання через офіційний API було неможливо – дані про BYOK вже існували, але губились усередині загальних totals.

## Що саме змінилось

Зміна стосується двох типів usage, які раніше були невидимими окремо:

**Local BYOK** – коли розробник сам налаштовує провайдера у клієнті: Copilot CLI чи GitHub Copilot app шле запити напряму до ключа розробника або до локальної моделі (Ollama, Foundry Local, LM Studio, llama-server – названі явно в changelog). Ці дані тепер доступні через:
- `used_local_byok` – булевий прапорець на рівні користувача: чи був хоча б один local BYOK запит за день;
- `totals_by_local_byok` – сесії, запити, prompts і токени, розбиті за `byok_kind` (`local_managed`, `local_user`, `local_auto`, `remote_user`) і `surface` (`copilot_cli` або `copilot_app`);
- `daily_active_local_byok_users`, `weekly_active_local_byok_users`, `monthly_active_local_byok_users` – кількість унікальних активних BYOK-користувачів за день, тиждень, місяць.

**Enterprise custom models** – моделі, які налаштовують адміни в GitHub settings, а запити йдуть через GitHub до твого провайдера. Їх позначає нове булеве поле `is_custom_enterprise_model` всередині `totals_by_client[].totals_by_model[]`. Якщо модель використовується і як hosted, і як custom – у звіті з'являються два окремі записи, щоб лічильники не перемішувались.

Ключова різниця між цими двома типами – у джерелі даних. Local BYOK GitHub бачить через client telemetry, а enterprise custom models спостерігає server-side, бо запит фізично проходить через інфраструктуру GitHub. Це напряму впливає на точність цифр, про що нижче.

Обидва типи з'являються в enterprise- і organization-звітах, на рівні користувача й агрегатів, у 1-денних і 28-денних репортах.

## Як це виглядає в коді

Офіційний ендпоінт і повну схему відповіді краще брати з документації Copilot usage metrics API, на яку посилається changelog – тут я не вигадуватиму конкретний шлях запиту. Але якщо в тебе вже є доступ до звіту у форматі JSON, має сенс написати невеликий шар для обробки саме нових полів – щоб не парсити їх руками щоразу.

```typescript
interface LocalByokTotals {
  byok_kind: "local_managed" | "local_user" | "local_auto" | "remote_user";
  surface: "copilot_cli" | "copilot_app";
  sessions: number;
  requests: number;
  prompts: number;
  tokens: number;
}

interface ModelTotals {
  model: string;
  is_custom_enterprise_model?: boolean;
  requests: number;
  tokens: number;
}

interface CopilotUsageReport {
  used_local_byok?: boolean;
  totals_by_local_byok?: LocalByokTotals[];
  totals_by_client: Array<{
    client: string;
    totals_by_model: ModelTotals[];
  }>;
}

function splitUsage(report: CopilotUsageReport) {
  const localByok = report.totals_by_local_byok ?? [];
  const byokRequests = localByok.reduce((sum, t) => sum + t.requests, 0);

  const customModelUsage = report.totals_by_client.flatMap((client) =>
    client.totals_by_model
      .filter((m) => m.is_custom_enterprise_model)
      .map((m) => ({ client: client.client, ...m }))
  );

  return { byokRequests, customModelUsage };
}
```

Нічого складного – важливіше те, що тепер ти можеш побудувати власний governance-звіт поверх цих полів: наприклад, порахувати, скільки розробників регулярно ходять у local BYOK попри корпоративну політику, або порівняти витрати на enterprise custom model із тим, скільки тих самих запитів раніше "ховались" у hosted totals.

Якщо команда вже використовує локальні моделі через Ollama в межах Copilot, варто подивитись на [Local sandboxing і Ollama у Copilot](/blog/copilot-local-sandbox-ollama) – там розібрано, як контролювати, що саме агент робить локально, а нові поля usage API якраз дають видимість поверх цього контролю.

## Чесні обмеження, які варто знати заздалегідь

Перш ніж будувати на цих даних дашборд для CFO, варто розуміти межі точності:

- **Local BYOK – це lower bound, не точна цифра.** Дані спираються на client telemetry, тож якщо телеметрія вимкнена – запити просто не потраплять у звіт. Token counts можуть бути заниженими ще сильніше, бо деякі local providers взагалі не репортують використання токенів.
- **Enterprise custom models точніші**, бо GitHub спостерігає їх server-side – ця категорія не має обмеження telemetry і покриває всі клієнти, включно з IDE.
- **Існуючі totals не зламались.** Local BYOK – підмножина вже наявних `totals_by_cli` і `totals_by_copilot_app`, а custom model usage й так входив у `totals_by_client`. Якщо в тебе вже є звіти з попередніми цифрами, вони не поїхали – просто з'явилась деталізація всередині.
- **Backfill немає.** Звітні дні до релізу не матимуть поля `is_custom_enterprise_model` – історичні порівняння доведеться робити з цим застереженням.
- **Назви моделей нормалізуються як і раніше**, тож нерозпізнані custom-моделі показуватимуться як `unknown`. А local BYOK взагалі не розбивається за назвою моделі – тільки за `byok_kind` і `surface`.
- **Доступ не для всіх.** Дані бачать enterprise owners, enterprise billing managers, organization owners і власники кастомних ролей з правом View Copilot Metrics, і лише за умови, що увімкнена Copilot usage metrics policy.

## Коли це реально варто підключати

Якщо в компанії менше десятка розробників і Copilot usage ніхто системно не аналізує – це апдейт, який можна просто взяти до відома. Але якщо у вас:

- є формальна BYOK-політика, яку хтось має перевіряти, а не вірити на слово;
- бюджет на AI розмазаний між Copilot-hosted і власними провайдерськими ключами, і фінансам потрібна прозорість per-user;
- команда одночасно використовує локальні моделі, hosted Copilot і enterprise custom models – і хочеться одного погляду на все це,

– тоді нова деталізація закриває реальну сліпу зону. Паралельно варто подумати і про безпековий бік BYOK: власні ключі провайдерів – це ще один секрет, який може витекти, і тут корисно тримати в голові підхід з [AI observability: чому агент витратив $8 і все одно викликав не той tool](/blog/ai-agent-observability) – usage-метрики добре працюють у парі з трасуванням того, що саме агент робив із цими запитами.

Нові поля не змінюють архітектуру Copilot і не додають нових можливостей самому асистенту – вони просто роблять видимим те, що раніше рахувалось, але губилось у спільних totals. Для governance-команди це різниця між "ми думаємо, що контролюємо BYOK" і "ми бачимо це в цифрах".