Michael JohnsonЯкщо розробник звертається до Copilot через сторонній інструмент, звичайна статистика за IDE може не показати, звідки надійшли запити. 23 жовтня 2026 року GitHub додала до API метрик використання Copilot поле totals_by_client, яке групує використання моделей за клієнтами, зокрема OpenCode, Claude Code, Codex і Zed. Для адміністраторів це спосіб побачити частину активності за межами редактора й точніше обговорювати внутрішні правила використання ШІ.
Що охоплює новий зріз
У кожному елементі totals_by_client зазначено клієнта, кількість успішних викликів моделі, кількість сесій та обсяг токенів prompt і output із їхньою середньою кількістю на виклик. Вкладене поле totals_by_model розподіляє ці показники за моделями й показує режим вибору: користувач вибрав модель безпосередньо, спрацював автоматичний вибір або модель призначив продукт.
Поле додано до одноденних і 28-денних звітів для підприємств, організацій і користувацьких зрізів цих рівнів. В агрегованому 28-денному звіті деталізація за клієнтами доступна для кожного дня. Зміна адитивна: попередні поля зберігаються, а за відсутності даних масив залишається порожнім. Докладніше GitHub описала в анонсі нового зрізу метрик використання.
На які запитання відповідають дані
Команда може порівняти обсяг запитів і токенів, що надійшли через різні інструменти, і вирішити, які інтеграції варто підтримувати або включати до корпоративних правил. Наприклад, зростання частки OpenCode у звіті може підказати, що розробники використовують Copilot як постачальника моделей поза IDE. Зіставлення клієнтів і моделей допомагає перевірити, які моделі фактично створюють основне навантаження.
Для аналізу бюджету корисно почати з токенів і кількості викликів, а потім звірити їх із чинними умовами тарифікації. request_count рахує виклики моделі, а не користувацькі промпти: один промпт може породити кілька викликів. Тому це поле підходить для аналізу навантаження на сервіс моделей, але не для прямого підрахунку взаємодій розробників.
Як інтегрувати метрику в робочий процес
- Перевірте доступ. Політику метрик використання Copilot має бути ввімкнено. Отримувати звіти можуть уповноважені власники підприємства чи організації, менеджери з виставлення рахунків і ролі з дозволом переглядати відповідні метрики.
- Порівнюйте однакові періоди. Використовуйте одноденний звіт, щоб перевірити зміни після ввімкнення інструмента, а 28-денний — щоб побачити стабільний розподіл активності. У кожному звіті розглядайте окремо виклики, токени й сесії: це різні виміри навантаження.
- Встановіть пороги для аналізу. Наприклад, позначайте клієнта, частка токенів або викликів якого помітно зросла порівняно з його попереднім періодом. Виберіть поріг відповідно до власних вимог і базового навантаження; GitHub не встановлює універсального порога.
- Зіставляйте звіт із налаштуваннями доступу. Нову деталізацію можна використовувати як основу для обговорення підтримки й керування інструментами. Самі звіти описують зареєстроване використання, але не замінюють перевірку дозволів або інвентаризацію інтеграцій.
В офіційній документації API метрик використання Copilot описано звіти, вимоги до дозволів і доступні зрізи. Перш ніж автоматизувати процес, перевірте в ній актуальну схему потрібного звіту й використовуйте відповідні права доступу.
Що означає позначка клієнта
GitHub визначає клієнта за integration ID, який інструмент передає із запитом. Компанія прямо характеризує групування як приблизну ідентифікацію: значення допомагає агрегувати трафік, але саме по собі не підтверджує особу користувача чи автентичність застосунку. Невідомі клієнти потрапляють до групи other, а значення, які неможливо нормалізувати, можуть відображатися як unknown.
Є й окремі спеціальні випадки: для викликів Copilot code review і Copilot cloud agent використовується режим вибору product_selected, оскільки модель вибирає продукт; для code review модель може відображатися як unknown. Це важливо враховувати під час порівняння зрізів моделей між інструментами.
Висновок практичний: totals_by_client усуває прогалину в обліку серверних викликів Copilot із зовнішніх інструментів і надає адміністраторам нові дані для аналізу навантаження та ухвалення рішень щодо підтримки. Щоб перетворити цю деталізацію на надійну картину використання, зіставляйте її з дозволами та іншими внутрішніми джерелами, а назви клієнтів трактуйте як категорії трафіку, а не як підтверджену ідентичність.