Стоимость AI-агентов: почему цена токена не предсказывает счёт
Alibaba выпустила модель Qwen 3.8-Max и представила её как одну из лучших в категории агентного использования. Независимое тестирование на открытом стенде VulcanBench поместило ту же модель в нижнюю часть таблицы. Оба результата корректны — разница объясняется временными бюджетами: Alibaba давала модели до пяти часов на задачу, независимый стенд — от 45 до 60 минут. Этот эпизод обнажает проблему, которая касается любого бизнеса, уже запустившего или планирующего запустить AI-агентов в рабочие процессы.
Цена за токен — первое, что публикуют в обзорах новых моделей. Она удобна для сравнения, но перестала быть надёжным предиктором реальных расходов. Причина в архитектуре современных reasoning-моделей: прежде чем сформировать ответ, модель тратит токены на внутренние рассуждения. Если токенный или временной лимит исчерпывается до завершения этих рассуждений, задача возвращается как провал — при этом полная стоимость запуска уже списана.
Как настройки агента формируют реальный счёт
Измерения VulcanBench по Claude Opus 5 показали неочевидный результат: режим минимального усилия решил 20 из 23 задач, тогда как режим максимального усилия — только 18. Дополнительные рассуждения при высоком усилии не были бесполезны: этот режим допустил наименьшее число неверных ответов. Однако он чаще исчерпывал временной лимит, а таймаут засчитывается как ноль. При неограниченном времени высокое усилие лишь сравнивалось с дешёвым режимом — при стоимости в 3,1 раза выше.
Исследование Long-Horizon-Terminal-Bench, опубликованное в июле, тестировало 17 моделей на 46 задачах с лимитом 90 минут на попытку. На таймауты пришлось 79% незавершённых запусков. Авторы уточняют: прерванные задачи не находились близко к завершению — средняя награда составляла от 0,10 до 0,35, поэтому нельзя считать, что больше времени автоматически давало бы правильный ответ. Но вывод очевиден: бенчмарки неявно измеряют эффективность использования времени, даже если не заявляют об этом.
Стандартная логика маршрутизации в агентных системах предполагает эскалацию к более мощной модели, если дешёвая попытка провалилась. Это работает, если следующий уровень действительно лучше справляется с задачей. Но для значительной части комбинаций «модель — задача» более дорогой режим просто расходует бюджет быстрее и заканчивается таймаутом. Компания платит за эскалацию, не получая результата.
Метрика, которая даёт реальную картину
Несколько независимых команд пришли к одной метрике — стоимость за успешно выполненную задачу. Формула простая: суммарные расходы, включая все провальные попытки, делятся на число задач, которые прошли проверку приёмки.
VulcanBench публикует эту колонку как основную с момента первых отчётов. Long-Horizon-Terminal-Bench размещает стоимость на задачу рядом с точностью: наиболее показательная строка — GPT-5.4 примерно по $26 за задачу при заметно более низком проценте успеха по сравнению с Grok 4.5 примерно по $11. TestEvo-Bench запускает агентов в условиях ограничения бюджета: показатель Claude Code по генерации тестов падает с 71% до 44% при более жёстком лимите.
Вендоры уже двигаются в том же направлении. HubSpot в апреле перевёл агента Breeze Customer Agent на оплату 50 центов за решённый диалог вместо $1 за обработанный. Zendesk выставляет счёт за автоматически решённые обращения. Intercom берёт 99 центов за результат и не тарифицирует незавершённые сессии. Модели ценообразования вендоров уже строятся вокруг успешного исхода — это сигнал, что именно эту единицу измерения рынок принимает как стандарт.
Для внедрения этой метрики в собственную систему нужно изменить способ логирования. Сейчас большинство агентных систем фиксируют факт провала, но не его причину. Таймаут, неверный ответ и техническая ошибка стенда — три разных события с разными способами устранения. Пока они записываются одним флагом «failure», показатель успешности измеряет сразу две разные проблемы, и непонятно, какую из них решать.
Отдельного внимания заслуживает параметр усилия по умолчанию. Qwen 3.8-Max при незаполненном поле effort запускается на максимальном уровне рассуждений — том самом, который показал наихудший результат в независимом тестировании. Команды, которые не меняют этот параметр, фактически запускают конфигурацию с наибольшей стоимостью за решённую задачу, не осознавая этого.
Ещё один практический момент касается выбора между лимитом по времени и лимитом по токенам. Ограничение по стенному времени включает в счёт скорость конкретного провайдера — и эта скорость засчитывается как качество модели. Если задержка не является частью вашего SLA, корректнее ограничивать токены, а не минуты.
- Добавьте обязательное поле с причиной провала в каждый запуск агента: таймаут, неверный ответ, ошибка стенда — отдельными значениями, не одним флагом.
- Считайте стоимость за успешную задачу по каждому уровню усилия, а не только по модели в целом.
- Ограничивайте токены, а не стенное время, если задержка не входит в ваши требования к уровню сервиса.
- Проверьте настройку усилия по умолчанию во всех развёрнутых агентах — особенно у моделей, запущенных без явной конфигурации этого параметра.
Практический вывод: прежде чем масштабировать агентную систему или переходить на новую модель, запустите тестирование с явным фиксированием причин провалов и посчитайте стоимость за успешно выполненную задачу по каждому уровню усилия — результат может кардинально отличаться от цены в прайс-листе.