Один запрос к агенту выглядит для пользователя как одно действие, но для бизнеса это уже не одна единица себестоимости. Ориентир в 100× вполне реалистичен, хотя считать его универсальной константой нельзя. Главный вывод другой: тарифицировать агента по сообщениям так же опасно, как продавать поездку такси по числу нажатий на кнопку «вызвать».
Откуда взялись 100×
Сводка Hacker News AI search приводит такие иллюстративные диапазоны: чат-реплика расходует от сотен до пары тысяч токенов, сложная агентная сессия от 50 тысяч до 200 тысяч, а задачи с несколькими агентами могут выйти за миллион. Авторы отдельно предупреждают, что это данные из практических руководств, а не показания единого официального счётчика.
Проверка арифметики показывает, что рабочий ориентир 100× не взят с потолка. Если сравнить чат на тысячу токенов и агентную сессию на 100 тысяч, получится ровно сто раз. Обе величины находятся внутри указанных диапазонов. Даже консервативное сравнение нижней границы агента, 50 тысяч, с верхней границей чата, 2 тысячи, даёт 25×.
Но превращать 100× в рыночное среднее было бы натяжкой. В той же сводке тема Gartner сформулирована как 5–30× относительно стандартного запроса, для coding agents указано до 100×. Исследование Stanford Digital Economy Lab на SWE-bench получило разницу примерно в 1000× между агентным программированием и code-chat. То есть корректный вывод звучит не «агент всегда ест в сто раз больше», а «разброс настолько велик, что средняя цена запроса почти ничего не говорит о себестоимости продукта».
Косвенный сигнал появился и раньше. The Decoder писал, что климатолог Зик Хаусфатер за восемь недель работы с Claude Code насчитал 3,2 млрд токенов и около 170 кВт·ч электричества дата-центра. В пересчёте на промпт расход энергии оказался примерно в 600 раз выше типичного AI-чата. Это не калькуляция денежной себестоимости, но хорошо показывает масштаб ошибки, когда агентную работу пытаются измерять меркой короткой переписки.
Считать нужно задачу, а не сообщение
У чат-продукта сообщение ещё могло служить грубой единицей потребления. У агента пользовательская команда запускает сессию, размер которой заранее известен лишь приблизительно. Поэтому без ограничений продукт фактически обещает клиенту фиксированную цену за работу с плавающей и иногда экстремальной себестоимостью.
Для фаундера отсюда следуют четыре практических требования.
Первое: бюджет токенов и шагов на каждую категорию задач. Не общий месячный лимит на пользователя, а предел внутри конкретного запуска. Если задача не укладывается, агент должен остановиться, запросить продолжение или перейти в упрощённый режим. Бесконечная настойчивость агента выглядит магией только до первого счёта.
Второе: маршрутизация моделей. Если доступные модели различаются по цене, нет смысла отдавать каждой промежуточной операции самый дорогой вариант. Сильную модель стоит оставлять для тех этапов, где её качество действительно влияет на результат, а остальную работу направлять на более дешёвые модели. Проверять эту схему нужно собственными данными, а не верой в слово «agentic» на лендинге.
Третье: аварийные лимиты. Нужны ограничения на одну задачу, пользователя и весь продукт. Их лучше встроить до запуска: остановить неудачную сессию неприятно, но менять тариф после того, как клиенты привыкли к безлимитной работе, ещё неприятнее.
Четвёртое: цена должна учитывать выполненную работу. Тариф «N запросов в месяц» смешивает дешёвую чат-реплику и тяжёлую агентную задачу, хотя их расход может различаться на порядки. Честнее продавать ограниченные классы задач, включённый вычислительный бюджет или пакеты тяжёлых запусков. Конкретная упаковка зависит от продукта, но сообщение больше не годится на роль универсальной расчётной единицы.
Интерес к оптимизации уже заметен по практическим публикациям: на Hacker News обсуждался материал о сокращении расхода токенов агента на 94%, а также появился Token Time, счётчик токенов по аналогии с экранным временем. Это пока не доказательство единого рецепта, зато хороший диагноз: рынок начал устанавливать спидометры после того, как машины уже выехали на трассу.
Что смотреть после запуска
Главные показатели теперь не число сообщений и даже не средний расход. Смотрите на токены на завершённую задачу, отдельно на медиану и верхний хвост, долю запусков, упёршихся в лимит, и себестоимость по типам задач. Если верхний хвост растёт быстрее выручки, а несколько тяжёлых сессий съедают маржу от десятков обычных, прогноз сбылся: вы запустили не чат с новой кнопкой, а продукт с другой экономикой.