GitHub заявил, что сократил расходы на токены в агентных CI-процессах максимум на 62%. Для команд, которые уже запускают LLM-агентов внутри пайплайнов, это неприятно практичная новость: значимая часть бюджета утекает не в «большие идеи», а в рутину вроде лишних tool-схем, повторных чтений и неудачно устроенных вызовов.
Об этом сообщает InfoQ со ссылкой на результаты, которые GitHub получил на собственных production workflow. Компания пишет, что урезала потребление токенов за счет трех довольно приземленных мер: убрала неиспользуемые инструменты Model Context Protocol, заменила часть MCP-вызовов на команды gh CLI и добавила ежедневную связку из двух служебных агентов, которые ищут аномалии и предлагают оптимизации. Если убрать маркетинговую обертку, картина простая: GitHub навел FinOps-порядок в AI-автоматизации и получил измеримый эффект.
Ключевая деталь здесь не только в процентах, но и в способе измерения. GitHub пропускает все обращения агентов через API-прокси и для каждого прогона сохраняет артефакт token-usage.jsonl. В нем в нормализованном виде собираются входные, выходные и кэш-токены для разных CLI-инструментов, включая Claude CLI, Copilot CLI и Codex CLI. Чтобы сравнивать сценарии между моделями разного класса, команда использует внутреннюю метрику Effective Tokens или ET. Выходные токены там учитываются с коэффициентом 4x, чтение из кэша с коэффициентом 0,1x, а сверху применяется множитель модели: Haiku считается по 0,25x, Sonnet по 1,0x, Opus по 5,0x. По логике GitHub, падение ET на 10% означает и падение стоимости на 10% вне зависимости от того, какая именно модель работала в конкретном workflow.
Сами оптимизации тоже не выглядят магией. Самая частая проблема, которую находит внутренний оптимизатор, это неиспользуемые MCP-инструменты. Поскольку LLM API по своей природе stateless, рантайм агента вынужден прикладывать схемы инструментов к каждому запросу заново. Если на MCP-сервере GitHub висит 40 tools, это добавляет к каждому ходу еще 10-15 КБ схемы. По данным компании, в smoke-test workflow удаление лишних инструментов уменьшало контекст на 8-12 КБ на один вызов. В изоляции цифра кажется скромной, но в расписанных по cron и часто запускаемых CI-сценариях такая «мелочь» быстро превращается в ощутимую статью расходов на токены.
Вторая мера еще интереснее для инженеров платформ и DevEx-команд. GitHub заменил часть MCP-обращений, которые нужны для получения diff pull request или содержимого файлов, на вызовы gh CLI. В одном варианте данные скачиваются в workspace еще до старта агента. В другом используется прозрачный HTTP-прокси во время выполнения, чтобы агент не получал на руки токены аутентификации. Это важный нюанс: компания не просто экономит контекст, но и пытается не размывать границу доступа. Для тех, кто строит внутренних AI-ассистентов в CI, здесь полезный сигнал: чем меньше агенту нужно «разговаривать» с внешними инструментами вживую, тем дешевле и безопаснее может быть пайплайн.
Где экономия сработала, а где нет
GitHub привел результаты по дюжине production workflow, и они выглядят достаточно убедительно, чтобы на них смотрели не как на единичный удачный кейс. В сценарии Auto-Triage Issues компания зафиксировала устойчивое снижение ET на 62% на 109 прогонах после исправлений. Security Guard показал минус 43%, Smoke Claude минус 59%, а Daily Community Attribution улучшился на 37%. На этом фоне особенно полезно, что GitHub не делает вид, будто оптимизация всегда работает одинаково. Workflow Contribution Check, наоборот, показал рост ET на 5%, и компания объясняет это не регрессией, а смещением нагрузки в сторону более крупных pull request.
Еще показателен случай с тем же Daily Community Attribution. В одном из прогонов там обнаружили восемь неиспользуемых GitHub MCP tools, к которым за весь run не было ни одного обращения. Казалось бы, очевидная добыча для pruning. Но после удаления ET не снизился. Причина вполне земная: манифесты инструментов занимали слишком маленькую долю общего контекста этого workflow, поэтому выигрыш просто утонул в остальном объеме. И это, пожалуй, самая полезная часть всей истории. GitHub фактически признает, что «почистить MCP» не равно автоматически «сэкономить деньги». Если контекст раздувают не схемы инструментов, а, например, огромные diff, повторные чтения файлов или сама логика агентного цикла, то резать нужно уже не декларации, а архитектуру задачи.
На фоне общего бума агентных инструментов в разработке это выглядит своевременно. Рынок последние месяцы был занят в основном тем, как дать агентам больше доступа, длиннее контекст и больше полномочий. GitHub напоминает о менее гламурной стороне вопроса: любая scheduled AI-автоматизация в CI имеет привычку тихо расти в цене, пока команда занята продуктом, а не инфраструктурной бухгалтерией. Anthropic и OpenAI уже предлагают prompt caching, LangChain умеет отслеживать токены через callback-механизмы, но GitHub делает акцент не на отдельной фиче, а на цикле наблюдаемости и исправления. Один агент собирает статистику, выделяет аномалии и самые дорогие job, второй читает исходники и свежие логи, затем сам открывает issue с предложением конкретных правок. Примечательно, что оба этих «контролера расходов» тоже попадают в ежедневные отчеты и сами становятся частью общей математики.
Что это значит для команд, которые уже играют в agentic CI
Для русскоязычных разработчиков, тимлидов и IT-директоров вывод довольно неприятный, но полезный: если у вас уже есть AI-агенты в CI, почти наверняка у вас есть и скрытые расходы на токены, о которых никто толком не знает. Причем оптимизировать их часто можно без смены модели и без очередного раунда споров о том, «какой LLM лучше». GitHub показывает более скучный, но куда более инженерный путь: нормализовать телеметрию, придумать единую метрику стоимости, выделить дорогие сценарии и чинить конкретные узкие места. Для бизнеса это означает более предсказуемый бюджет на AI-автоматизацию. Для платформенных команд — повод пересмотреть, какие tool-схемы агент реально получает на каждом шаге, зачем ему живые MCP-вызовы и можно ли часть данных готовить заранее. Для security-команд — напоминание, что удобство агента не должно автоматически означать раздачу лишних секретов.
Следующий шаг, который обозначил сам GitHub, логично выходит за рамки одного workflow: анализировать портфель сценариев на уровне репозитория и искать дублирующиеся чтения, повторные запросы и общие промежуточные артефакты. Если эта практика закрепится, разговор про AI в DevOps может быстро сместиться от восторга по поводу автономности к более взрослому вопросу: не сколько задач агент умеет выполнять, а сколько стоит каждая полезная единица этой автономии. Проверить исходный разбор можно в .