Michael JohnsonЕсли разработчик обращается к Copilot через сторонний инструмент, обычная статистика по IDE может не показать, откуда пришли запросы. 23 октября 2026 года GitHub добавила в Copilot usage metrics API поле totals_by_client, которое группирует использование моделей по клиентам, включая OpenCode, Claude Code, Codex и Zed. Для администраторов это способ увидеть часть активности за пределами редактора и точнее обсуждать внутренние правила использования ИИ.
Что попадает в новый срез
В каждом элементе totals_by_client указываются клиент, число успешных вызовов модели, число сессий и объём prompt- и output-токенов с их средним количеством на вызов. Вложенный totals_by_model разбивает эти показатели по моделям и показывает режим выбора: пользователь выбрал модель напрямую, сработал автоматический выбор или модель назначил продукт.
Поле добавлено в однодневные и 28-дневные отчёты для предприятия, организации и пользовательских срезов этих уровней. В агрегированном 28-дневном отчёте детализация по клиентам присутствует для каждого дня. Изменение аддитивное: прежние поля сохраняются, а при отсутствии данных массив остаётся пустым. Подробности GitHub описала в анонсе нового среза usage metrics.
На какие вопросы отвечают данные
Команда может сравнить объём запросов и токенов, поступивших через разные инструменты, и решить, какие интеграции стоит поддерживать или включать в корпоративные правила. Например, рост доли OpenCode в отчёте может подсказать, что разработчики используют Copilot как поставщика моделей за пределами IDE. Сопоставление клиентов и моделей помогает проверить, какие модели фактически создают основную нагрузку.
Для бюджетного анализа полезно начинать с токенов и количества вызовов, а затем сверять их с действующими условиями тарификации. request_count считает вызовы модели, а не пользовательские промпты: один промпт может породить несколько вызовов. Поэтому это поле подходит для анализа нагрузки на модельный сервис, но не для прямого подсчёта взаимодействий разработчиков.
Как встроить метрику в рабочий процесс
- Проверьте доступ. Политика Copilot usage metrics должна быть включена. Получать отчёты могут уполномоченные владельцы предприятия или организации, billing-менеджеры и роли с разрешением просмотра соответствующих метрик.
- Сравнивайте одинаковые периоды. Используйте однодневный отчёт для проверки изменений после включения инструмента, а 28-дневный — для устойчивого распределения активности. Внутри каждого отчёта разделяйте вызовы, токены и сессии: это разные измерения нагрузки.
- Задайте пороги для разбора. Например, отмечайте клиента, чья доля токенов или вызовов заметно выросла относительно собственного предыдущего периода. Порог выберите по своим требованиям и базовой нагрузке; GitHub универсального порога не задаёт.
- Сверяйте отчёт с настройками доступа. Новую детализацию можно использовать как вход для обсуждения поддержки и управления инструментами. Сами отчёты описывают зарегистрированное использование, а не заменяют проверку разрешений или инвентаризацию интеграций.
Официальная документация Copilot usage metrics API описывает отчёты, требования к разрешениям и доступные срезы. Перед автоматизацией проверьте в ней актуальную схему нужного отчёта и используйте соответствующие права доступа.
Что означает метка клиента
GitHub определяет клиента по integration ID, который инструмент передаёт с запросом. Компания прямо характеризует группировку как приблизительную идентификацию: значение помогает агрегировать трафик, но само по себе не подтверждает личность пользователя или подлинность приложения. Неизвестные клиенты попадают в группу other, а значения, которые нельзя нормализовать, могут отображаться как unknown.
Есть и отдельные специальные случаи: вызовы Copilot code review и Copilot cloud agent получают режим выбора product_selected, поскольку модель выбирает продукт; для code review модель может отображаться как unknown. Это важно учитывать при сравнении модельных срезов между инструментами.
Итог практичен: totals_by_client закрывает пробел в учёте серверных вызовов Copilot из внешних инструментов и даёт администраторам новые данные для анализа нагрузки и принятия решений о поддержке. Чтобы превратить эту детализацию в надёжную картину использования, сопоставляйте её с разрешениями и другими внутренними источниками, а названия клиентов трактуйте как категории трафика, а не как доказанную идентичность.