Команды привыкли выбирать модель по цене миллиона токенов и качеству на бенчмарках. Но свежие измерения, которые разбирает The New Stack, показывают более неприятную механику: один и тот же интеллект может стоить радикально по-разному в зависимости от софта, который гоняет его по задаче. Смена харнесса способна дать больший выигрыш в себестоимости, чем переход на более дешёвую модель.
Один мотор, разный расход
В июньском независимом тесте 12 конфигураций запускали через OpenRouter на одинаковых Python-задачах и одинаковых моделях. Сначала использовали DeepSeek V4 Flash, затем Nvidia Nemotron 3 Ultra. Расход на решённую задачу составил примерно от 3 500 токенов у Aider в architect mode до 292 000 у OpenClaw. Порядок участников почти не изменился при смене модели, что указывает именно на влияние харнесса.
Это не идеальный эксперимент. Для каждой комбинации харнесса, задачи и модели сделали только один прогон, поэтому оценки разброса нет, а агентные запуски стохастичны. Но механизм подтверждается другими измерениями.
В августовском тесте Composio восемь харнессов выполняли 30 рабочих сценариев с Airtable, Gmail, Google Calendar, Google Sheets, GitHub, Slack и PostHog. Результат проверял программный верификатор, а не другая LLM. Из 240 запусков успешно завершились 129. Стоимость успешной задачи колебалась от $0,028 у Pi Agent до $0,195 у Claude Code. DeepAgents показал ту же долю успешных выполнений, что Claude Code, но стоил в четыре раза дешевле на один успех.
Контроль и здесь был не стерильным: Pi работал с разными reasoning-настройками у двух провайдеров, а у Prime Agent проверяемыми оказались только 24 запуска из 30. Поэтому объявлять победителя рано. Зато уже трудно защищать привычную схему закупки, где команда тщательно сравнивает модели, а харнесс считает бесплатной обвязкой.
Главный расход начинается до полезной работы
Причина разброса довольно прозаична. Перед первым содержательным действием харнесс отправляет модели системный промпт, описания инструментов и настройки окружения. В июньском тесте этот стартовый груз составлял около 700 токенов у Aider в architect mode и около 26 000 у OpenClaw.
Сам по себе тяжёлый старт ещё не катастрофа. Проблема в том, что контекст приходится передавать снова на каждом ходе. Харнесс с базовым грузом в 26 000 токенов за 15 итераций тратит примерно 390 000 входных токенов только на собственную конструкцию. В тесте произведение стартового объёма на число ходов предсказывало итоговый расход на решённую задачу с R² 0,99 для обеих моделей.
Любопытно, что контекст у разных харнессов рос примерно одинаково, на несколько сотен токенов за ход. Дорогие системы не обязательно хуже управляют историей диалога. Они просто начинают каждый круг с более тяжёлым чемоданом, а API исправно взвешивает его заново.
Отсюда практический порядок аудита. Сначала измерить размер системного промпта и описаний инструментов. Затем посчитать число ходов до результата. И только после этого обсуждать более хитрые оптимизации или смену модели.
Кэш может перевернуть таблицу
Сырые токены тоже не равны счёту. По данным Composio, у Claude Code из кэша пришло лишь 1,5% входных токенов, у Codex около 70%, у OMP 57%. Свежий ввод стоил примерно в пять раз дороже кэшированного. Поэтому потребление Claude Code было сопоставимо с конкурентами, но итоговая цена оказалась выше.
В июньском тесте Codex выставил более миллиона токенов за набор задач, однако 77% пришлись на чтение кэша по цене примерно в десять раз ниже обычной. В результате он оказался дешевле Claude Code на решённую задачу, хотя использовал вдвое больше сырых токенов. Автор теста связал почти нулевую долю кэша у Claude Code с путём запросов через Anthropic-style endpoint OpenRouter, а не с содержанием промптов.
Для билдера это означает, что метрика tokens per task без данных о кэше почти декоративна. Считать нужно стоимость успешной задачи, причём через тот же endpoint и провайдера, которые пойдут в продакшен.
Что проверить до следующего счёта
Минимальный внутренний бенчмарк должен фиксировать четыре вещи: долю успешно выполненных задач, стартовый объём контекста, число ходов и долю кэшированных токенов. Запускать его стоит на своих сценариях, с одной моделью и одинаковым лимитом времени, меняя только харнесс. Для оценки устойчивости нужны повторные прогоны: Artificial Analysis, например, сравнивает пары модель-харнесс на 326 задачах и усредняет результат по трём попыткам.
Конкретный маркер на ближайшем счёте прост. Если стоимость одной успешной задачи лучше объясняется произведением стартового контекста на число ходов и долей кэша, чем ценой выбранной модели, значит харнесс пора считать частью экономики продукта, а не технической деталью.