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, має сенс написати невеликий шар для обробки саме нових полів – щоб не парсити їх руками щоразу.

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 – там розібрано, як контролювати, що саме агент робить локально, а нові поля 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 – usage-метрики добре працюють у парі з трасуванням того, що саме агент робив із цими запитами.

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