Одна задача для AI-агента может потреблять в 10–50 раз больше токенов, чем обычный запрос в чат. Причина проста: агент не ограничивается ответом — он строит план, пишет код, запускает тесты, исправляет ошибки и повторяет цикл. Для компаний это меняет разговор о том, как считать стоимость AI-агентов: не по числу токенов, а по числу pull request, которые прошли ревью и попали в основную ветку.
Такую логику продвигает HPE в спонсорском материале, сообщает MIT Technology Review. Авторы предлагают метрику cost per merged pull request: все затраты на AI-помощь в разработке, разделённые на количество изменений, принятых в репозиторий. Рядом должны идти показатели доработок и дефектов — иначе дешёвый PR может оказаться просто плохо сделанной задачей, расходы на которую переедут в следующий спринт.
Проблема уже перестала быть теоретической. В материале говорится, что Uber якобы исчерпал годовой бюджет на ИИ к апрелю 2026 года после расширения использования Claude Code. GitHub Copilot, в свою очередь, перешёл от фиксированной подписки к модели с лимитируемыми кредитами. Gartner, по данным HPE, прогнозирует, что к 2028 году расходы на токены для AI-кодинга превысят среднюю зарплату разработчика. Эти утверждения приведены в рекламном материале, поэтому их разумнее воспринимать как сигнал о направлении рынка, а не как готовую финансовую модель для собственной компании.
Обычная реакция на растущий счёт предсказуема: лимиты на пользователей, квоты, согласования перед запуском агента. Но у такого подхода есть неприятный побочный эффект. Он одинаково режет и бесполезный цикл из десятков повторных запросов, и полезную автоматизацию, которая за вечер закрывает рутинный рефакторинг, генерирует тесты или готовит миграцию. Счётчик токенов фиксирует потребление вычислений, но не отличает провальный прогон от готового изменения, которое сэкономило команде дни работы.
Для русскоязычных команд, особенно тех, кто уже использует агентные инструменты в IDE и CI, вывод довольно прикладной. Стоит отдельно увидеть, кто именно создаёт расходы: средняя стоимость лицензии мало говорит о реальной картине, если несколько наиболее активных инженеров запускают агентов на порядок чаще остальных. HPE приводит ещё более резкий пример: самые активные 5% пользователей формировали основную часть потребления, а самый интенсивный пользователь мог расходовать примерно в 450 раз больше, чем самый редкий обладатель той же лицензии.
Не каждому шагу нужен самый дорогой модельный API
Вторая идея HPE — разделить задачи по сложности и риску. Сильные облачные модели имеет смысл оставить для архитектурного планирования, нестандартных задач и случаев, где требуется сложное рассуждение. Более повторяемую работу — генерацию кода по понятному шаблону, создание тестов, массовый рефакторинг — можно направлять в open-weight модели, развёрнутые внутри компании. Шлюз между инструментами и моделями должен учитывать сложность запроса, чувствительность данных, допустимую задержку и цену обработки.
Это не означает, что открытая модель автоматически заменит лидирующую во всём. Авторы прямо оговаривают: хорошие результаты на инженерных бенчмарках не доказывают равную эффективность для любого репозитория. Проверять нужно на собственном коде, тестах и критериях приёмки. Для команды важнее не место модели в публичном рейтинге, а её способность стабильно доводить конкретные задачи до PR, который примут коллеги.
Третья часть рецепта касается инфраструктуры. При оплате внешнего API каждая новая генерация увеличивает переменные расходы. При собственной вычислительной мощности значительная часть затрат появляется заранее: оборудование, электроэнергия, эксплуатация, поддержка и амортизация. Зато при устойчивом объёме задач цена дополнительного запуска снижается. HPE утверждает, что после маршрутизации рутинных внутренних нагрузок более чем из 150 приложений на локально работающие открытые модели смогла снизить токенные затраты на 30–50%.
У этой схемы есть очевидная граница применимости. Если команда пользуется AI-агентами редко или скачкообразно, собственная инфраструктура будет простаивать, а облачный API останется дешевле и проще. Если нагрузка постоянна и велика, локальная мощность может окупаться не только вычислениями, но и контролем над исходным кодом. В таком случае наружу можно выпускать лишь одобренные запросы для сложных задач, а генерацию, тестирование и обработку чувствительных репозиториев оставить внутри периметра.
Практическая рекомендация здесь полезнее лозунга о «суверенном ИИ»: до смены инфраструктуры нужно зафиксировать две базовые метрики — расходы на активного разработчика и стоимость AI-агентов в расчёте на влитый PR. Затем провести полный цикл разработки в новой схеме и посмотреть, улучшились ли обе цифры без роста дефектов и возвратов на доработку. Если нет, владение GPU само по себе не решает проблему.
Главный вопрос для компаний теперь не в том, как запретить разработчикам нажимать кнопку агента слишком часто. Важнее понять, какая доля этих запусков превращается в работающий код. По мере роста автономности инструментов бюджет на токены будет всё хуже описывать эффективность разработки — а метрика «сколько софта реально дошло до продакшена» всё лучше. Подробнее о подходе HPE изложено в материале .
