GitHub рассказал, как сократить расходы на LLM-агентов в CI за счёт оптимизации GitHub Agentic Workflows. В компании выяснили, что автоматические агентные пайплайны, запускаемые на каждый pull request, со временем могут накапливать крупные счета за API, причём это часто остаётся незаметным.
GitHub использует сотни таких workflows как GitHub Actions с реальными лимитами API и запустил инициативу по систематической оптимизации токенов в апреле 2026 года. Команда внедрила прокси на уровне API, который и так применялся для защиты токенов доступа, и начала собирать единый лог по всем агентным фреймворкам (Claude CLI, Copilot CLI, Codex CLI).
Каждый workflow теперь сохраняет артефакт token-usage.jsonl с записью на каждый API-вызов: входные и выходные токены, токены чтения из кеша, записи в кеш, модель, провайдер и временные метки. Объединение этой информации с остальными логами дало историческую картину потребления токенов и основу для оптимизации.
На базе этих данных GitHub построил два ежедневных агентных пайплайна:
- Daily Token Usage Auditor — агрегирует расход токенов по workflow, отмечает резкие всплески, самые дорогие пайплайны и аномальные запуски (например, когда вместо четырёх шагов LLM требуется 18).
- Daily Token Optimizer — анализирует код workflow и свежие логи, создаёт issue в репозитории с описанием неэффективных мест и предлагает конкретные изменения.
Оба пайплайна сами являются агентными workflow и попадают в ежедневные отчёты, создавая небольшой «замкнутый цикл» улучшений.
Самой частой проблемой оказались неиспользуемые MCP-инструменты. Из-за статeless-природы LLM API рантаймы агентов отправляют полное описание доступных инструментов и JSON-схемы в каждом запросе. Для MCP-сервера GitHub с 40 инструментами это добавляет 10–15 КБ схем на каждый шаг. Если реально используются два инструмента, оставшиеся 38 — чистый оверхед.
Авторов workflow тянет подключать весь набор инструментов, а агент уже сам решает, что ему нужно. Но со временем большинство пайплайнов стабильно опираются на небольшой поднабор. Optimizer сопоставляет манифест инструментов с фактическими вызовами и рекомендует удалить лишние. В тестовых workflow это сократило контекст на 8–12 КБ на вызов и сэкономило несколько тысяч токенов за прогон без изменения поведения.
Более крупный резерв экономии — снятие части запросов к GitHub из LLM-петли. Раньше агент получал данные (diff pull request, содержимое файлов, комментарии) через MCP-вызовы. Каждый такой вызов — отдельный шаг рассуждения: выбор инструмента, формирование аргументов, обработка ответа в контексте, а значит, отдельный запрос к LLM с расходом токенов на схему, аргументы и результат.
Вместо этого GitHub стал использовать GitHub CLI (gh) для предзагрузки данных:
- Предварительные загрузки перед агентом: workflow перед запуском агента выполняет команды gh (например, для получения diff или списка изменённых файлов) и записывает результаты в файлы в рабочем каталоге. Агент читает эти файлы и обрабатывает данные с помощью уже имеющихся навыков bash-скриптинга.
- CLI-прокси внутри агента: если решение, какие данные взять, принимается на лету, используется лёгкий HTTP-прокси, который направляет вызовы gh к API GitHub, не раскрывая секреты агенту. Агент может выполнить gh pr view –json и получить структурированные данные, как в терминале. Это снижает расход токенов и сохраняет требование «без секретов» для агента.
Совместно эти подходы вынесли основную часть запросов к GitHub из контура LLM, оставив модели только задачи рассуждения.
Для оценки эффекта GitHub ввёл метрику Effective Tokens (ET), учитывающую стоимость токенов для разных моделей и типов токенов. Например, Claude Haiku примерно в четыре раза дешевле Sonnet по цене за токен, а выходные токены дороже входных у большинства провайдеров. В формуле ET учитываются множители для моделей (Haiku = 0,25×, Sonnet = 1,0×, Opus = 5,0×), веса для новых входных, кешированных входных и выходных токенов. Снижение ET на 10% означает реальную экономию на 10% независимо от выбранной модели.
При этом GitHub подчёркивает: сырые токены вводят в заблуждение. Один и тот же workflow может обрабатывать то маленький пятистрочный фикс, то крупный pull request на 200 строк. Разница в токенах в таком случае связана с нагрузкой, а не с эффективностью. Поэтому команда дополнительно отслеживает количество вызовов LLM (turns) и токенов на один вызов.
Отдельный вопрос — качество результата. Переход на более лёгкую модель и более строгую конфигурацию может удешевлять запуск, но ухудшать ответы. В GitHub пока опираются на косвенные признаки: число шагов LLM на прогон, количество выходных токенов и долю успешных вызовов инструментов. Для оптимизированного Smoke Copilot workflow эти показатели остались стабильными при снижении потребления токенов.
Для оценки реального эффекта GitHub применил Auditor и Optimizer к дюжине production-workflow в репозиториях gh-aw и gh-aw-firewall. Девять из них получили изменения по рекомендациям оптимизатора. В анализ попали только пайплайны с минимум восемью прогонами до и после оптимизации: Auto-Triage Issues, Daily Compiler Quality, Community Attribution, Security Guard, Smoke Claude.
Результаты по ET:
- Auto-Triage Issues — устойчивое снижение на 62% по 109 прогонам после фиксa.
- Daily Compiler Quality — улучшение на 19% по 12 прогонов.
- Daily Community Attribution — снижение на 37% по восьми прогонам.
- В gh-aw-firewall: Security Guard (аудит каждого pull request на чувствительные к безопасности изменения) и Smoke Claude (интеграционный тест пути через Claude CLI) показали улучшения на 43% и 59% соответственно.
Частота запусков оказалась столь же важна, как экономия на один прогон. Auto-Triage Issues с 62% экономии и средней частотой 6,8 запусков в день (максимум 15) за период наблюдения сэкономил около 7,8 млн ET. Security Guard и Smoke Claude вызываются ещё чаще, поэтому приоритизация по частоте даёт больший суммарный эффект.
Не все рекомендации дают заметное снижение ET на небольшом промежутке, особенно в живом репозитории с плавающей нагрузкой. Например, у Contribution Check ET вырос на 5% — в GitHub объясняют это не провалом оптимизации, а сдвигом нагрузки в сторону более крупных pull request.
По итогам анализа команда выделяет несколько характерных паттернов.
1. Много шагов агентов — детерминированный сбор данных. Auto-Triage Issues в gh-aw показал устойчивое снижение на 44% по 62 прогонам за счёт переноса чтения issue-метаданных и лейблов в предварительные шаги CLI до старта агента. Похожий подход дал 60% снижения для Security Guard: добавлен фильтр значимости, пропускающий LLM, если изменения не касаются файлов, связанных с безопасностью. «Самый дешёвый LLM-вызов — тот, который вы не делаете» — подчёркивает GitHub.
Случай Contribution Check показывает, как нагрузка скрывает выгоду. До оптимизации 41% запусков приходился на маленькие pull request (ET < 100K), 39% — на большие (ET > 300K). После оптимизации наблюдался всплеск разработки: 9% маленьких и 65% крупных pull request, а выходные токены (с большим весом в ET) выросли на 14%. При этом доля кешированных входных токенов осталась высокой — 82–83%.
2. Неиспользуемые инструменты обходятся дорого. В workflow Glossary Maintainer один инструмент search_repositories оказался вызван 342 раза за прогон и дал 58% всех вызовов инструментов, хотя для сценария, который анализирует только локальные изменения файлов, он был не нужен. Удаление этого инструмента стало рекомендацией оптимизатора.
В gh-aw-firewall для Smoke Claude сочетание агрессивного «обрезания» MCP-инструментов и перехода на модель Haiku дало снижение ET на 79%. Но Daily Community Attribution показал пределы этого приёма: workflow был сконфигурирован с восемью MCP-инструментами GitHub и ни разу их не вызвал за прогон, а их удаление почти не повлияло на ET, так как манифесты инструментов занимали малую долю контекста.
3. Одна ошибка в правилах может вызвать бесконечный цикл. Workflow Daily Syntax Error Quality до оптимизации был самым дорогим по ET в проекте. Причина — однострочная ошибка в конфигурации: файлы тестов копировались в /tmp/, после чего вызывалась команда gh aw compile *, но sandbox bash разрешал только относительные шаблоны путей. Каждый вызов компиляции блокировался, и агент уходил в 64-шаговый «ручной» цикл, читая исходники и пытаясь восстановить ответы компилятора. Исправление разрешённых шаблонов bash сразу устранило патологию.
GitHub отмечает, что все использованные подходы — наблюдаемость на уровне API, автоматический аудит, обрезка MCP-инструментов, замена MCP на CLI — уже доступны в фреймворке GitHub Agentic Workflows. Следующим шагом планируется переразбивка больших агентов на команды субагентов на более лёгких моделях.
Дальнейшее развитие команда видит в переходе от оптимизации отдельных workflow к системному уровню. Один прогон — это последовательность эпизодов: сбор контекста, чтение артефактов, повторы после ошибок, финальный ответ. Если выделить эти эпизоды в логах, можно точнее понять, что делает запуск дорогим, где повторяется работа, где операции должны стать детерминированными предварительными шагами.
Та же логика распространяется на портфель workflow: репозиторий обычно выполняет несколько агентных автоматизаций, которые реагируют на одни и те же события, анализируют одинаковые diff и логи и делают близкие выводы. Стоимость определяется не только параметрами отдельного workflow, но и пересечением задач между ними. GitHub планирует искать дублирующие чтения, кандидатов на консолидацию и возможности кешировать общие промежуточные артефакты.
Многие вопросы остаются открытыми. Полноценная оценка «полезной работы» требует метрик качества результата, которых пока нет в массовом виде для агентных CI-пайплайнов, а анализ эффективности на уровне эпизодов и портфеля требует более подробных данных о происхождении операций. Тем не менее команда уже меняет подход: мониторинг токенов включается с первого дня, а фокус смещается с отдельных дорогих запусков к поиску избежной работы во всей системе автоматизаций.
GitHub рекомендует командам, использующим агентные workflow в CI и сомневающимся в расходах, начать с того же шага: внедрить прокси на уровне API, включить логирование токенов и использовать данные для выявления главных точек роста.
Указанные Auditor и Optimizer можно подключить к репозиторию через gh-aw CLI и запускать параллельно с текущим CI, чтобы сразу получить видимость по расходу и механизм непрерывной оптимизации.
GitHub также напоминает о других материалах по теме: о безопасности GitHub Agentic Workflows, техническом превью фреймворка, практическом гайде по ревью pull request, созданных агентами, и подходе к «слою доверия» для GitHub Copilot Coding Agents. Компания продолжает развивать площадку ресурсов для разработчиков — от кейсов команд, подкаста про open source до обучающих рассылок и мероприятий вроде встречи OpenClaw на GitHub HQ во время Microsoft Build 2026.
Источник: материалы GitHub.
