TL;DR
Исследование пересчитало стоимость 600 реальных запусков кодовых агентов с учётом кэша префикса. Кэш префикса — это механизм провайдера: уже отправленное начало диалога повторно читается примерно за десятую часть цены. Оказалось, что число ходов агента (цикл «действие → результат инструмента → следующее действие») объясняет почти весь разброс стоимости. Размер ответов инструментов объясняет почти ничего. Самые дорогие запуски — те, где ходов больше всего. Ответы инструментов в них при этом самые маленькие.
Две боли, которые исследование разбирает. Первая: «сожмём огромные логи сборки, и счёт упадёт». Реально ответы инструментов короткие: медиана — сотни токенов, а огромные логи редкость. Поэтому умное сжатие почти не выигрывает у простого обрезания. Вторая: «поставим дешёвую модель на лёгкие шаги». Если считать по прайс-листу без кэша, экономия выглядит огромной. На деле почти весь вход читается из кэша, а при смене модели кэш пропадает и весь контекст читается заново по полной цене. Поэтому в половине проверенных сценариев переключение увеличивает расходы.
Метод в статье — способ считать правильно. Реконструируй стоимость с учётом кэша. Сравни, что вы оптимизируете: ходы или размер наблюдений. Проверь по формуле, окупится ли передача шага дешёвой модели. Если передаёшь, отдавай дешёвой модели только узкий срез (сам ответ инструмента), а не весь диалог.
Схема метода
ШАГ 1: Возьми журнал запуска агента → посчитай ходы и размеры ответов инструментов
ШАГ 2: Пересчитай стоимость с учётом кэша → (почти весь вход = дешёвое чтение из кэша)
ШАГ 3: Раздели разброс стоимости → ходы или размер ответов?
ШАГ 4: Решение «отдать шаг дешёвой модели?» →
да, если ходов осталось БОЛЬШЕ, чем (цена входа дешёвой) / (цена кэш-чтения сильной)
отдавай ТОЛЬКО срез контекста, не весь диалог
ШАГ 5: Хочешь сэкономить → сначала ищи лишние ходы
Это аналитическая процедура. В статье нет промпта, который выполняется в одном запросе.
Пример применения
Сильная зона выводов: понять, куда уходят деньги в своих сессиях с агентом. Лезть в инфраструктуру не нужно.
Задача: Разработчик продавца на Ozon и Wildberries правит в Cursor парсер выгрузки заказов. Агент сделал под 140 ходов. Счёт за месяц растёт, а команда спорит: «надо сжимать логи тестов» или «поставить дешёвую модель на чтение файлов». Он выгружает журнал сессии и просит модель в чате разобрать, из чего состоят ходы.
Промпт:
Ниже журнал сессии кодового агента (Cursor) по задаче «починить парсер выгрузки заказов Ozon/WB».
Каждая строка: номер хода, действие агента, ответ инструмента.
Сделай аудит ходов:
1. Классифицируй каждый ход: чтение/запуск (read/exec), правка (edit), завершение (terminate), рассуждение без инструмента (think).
2. Посчитай по типам: долю ходов, среднюю длину ответа инструмента (в токенах, приблизительно).
3. Найди лишние ходы: (а) повторный запрос с тем же результатом без изменений, (б) повторный запуск той же команды без правки между ними, (в) чтение файла, который уже читали в этой сессии.
4. Для каждого лишнего хода — номер хода и что агент мог сделать вместо него (один запрос, пакетное чтение, остановка).
5. Ответь на вопрос: что дороже в этой сессии — количество ходов или размер ответов инструментов? Приведи цифры.
Журнал:
{журнал_сессии}
Результат: Модель выдаст таблицу типов ходов с долями и средней длиной ответов. Затем список ходов, которые выглядят как повторы или лишние чтения. Затем вывод о том, что даёт больше: сокращение ходов или сжатие ответов. Цифры будут приблизительными, потому что токены модель в чате оценивает на глаз. Для точного счёта нужен токенайзер.
Почему это работает
Слабость интуиции: кажется, что «стоимость = размер того, что агент читает». Но в агентном цикле один и тот же диалог отправляется заново на каждом ходу. Каждый новый ход добавляет ещё один проход по всему накопленному контексту. Поэтому цена растёт быстрее, чем число ходов, а размер одного ответа почти не важен: он всего лишь пара сотен токенов на фоне десятков тысяч токенов контекста.
Сильная сторона механики: провайдер хранит кэш начала диалога. Пока диалог только дописывается в конец, всё старое читается по сниженной цене. Платишь по полному тарифу почти только за последний ответ инструмента. Эта предсказуемость позволяет посчитать стоимость точно, а не гадать.
Как это даёт рычаги: - Не меняй модель посреди сессии. Новая модель не видит кэша старой и читает весь контекст «с нуля». Переключение выгодно, только если цена входа дешёвой модели ниже цены кэш-чтения сильной. Цена дешёвой модели, которая в 5 раз ниже списочной цены сильной, может оказаться убытком. Разница между прибылью и убытком — примерно в два раза, и по прайс-листу этого не видно. - Если нужна дешёвая модель — отдавай ей узкий срез (только ответ инструмента), а результат вставляй обратно. Кэш сильной модели при этом остаётся целым. - Большие логи редки. Крупные ответы чаще дают правки: редактор возвращает обновлённый фрагмент файла. Его и опасно сжимать, потому что это код, с которым агент работает. - Простое обрезание ответов даёт ту же экономию, что и сжатие моделью. Дорогую схему стоит оправдывать качеством, а не стоимостью.
Шаблон промпта
В статье готовых промптов нет. Ниже шаблон аудита, который опирается на классификацию ходов и поиск повторов из методики авторов.
Ниже журнал сессии кодового агента ({инструмент}) по задаче «{задача}».
Каждая строка: номер хода, действие агента, ответ инструмента.
Сделай аудит ходов:
1. Классифицируй каждый ход: read/exec (чтение или запуск), edit (правка), terminate (завершение), think (рассуждение без инструмента).
2. Посчитай по типам: долю ходов, среднюю длину ответа инструмента (в токенах, приблизительно).
3. Найди лишние ходы:
(а) повторный запрос после усечённого ответа, который можно было сузить;
(б) повторный запуск той же команды без изменений между ними;
(в) повторное чтение файла, уже прочитанного в этой сессии.
4. Для каждого лишнего хода — номер и более короткий путь.
5. Что дороже в этой сессии: число ходов или размер ответов инструментов? Приведи цифры.
Журнал:
{журнал_сессии}
Подставь инструмент (Cursor, Claude Code), задачу и вставь журнал сессии. Журнал можно выгрузить из истории чата агента или из логов запусков.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита ходов агента. Адаптируй под мою ситуацию: [опиши, каким агентом пользуешься и что в нём тормозит или дорого].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
Модель уточнит инструмент, формат журнала и что для тебя «лишний ход». Без этого она не поймёт, как отличать повтор от нужной проверки.
Ограничения
⚠️ Связь ходов и успеха не доказана: авторы прямо пишут, что не установили, можно ли убрать ходы без потери результата. Вывод «сократи ходы — сэкономишь» остаётся гипотезой. Проверяй на своих задачах: снизилось ли число успешных решений.
⚠️ Ассоциация, не причина: ходы объясняют стоимость отчасти по определению: больше ходов — больше счёт. Сильная связь вытекает из устройства цикла. Рецепта, как убирать ходы, в статье нет.
⚠️ Качество не измеряли: сравнивали только стоимость. Про то, лучше ли сжатие моделью сохраняет смысл, чем обрезание, статья не говорит.
⚠️ Две открытые модели, две обвязки: данные только на Qwen3.5 и Minimax M2.5 в OpenHands и SWE-agent. Закрытые фронтирные модели и другие агенты могут вести себя иначе. Кэш в расчётах почти идеальный, в реальности он ниже.
⚠️ Нужен код для точного счёта: сам инструмент TurnCost — скрипт для набора журналов. Читателю без кода доступна только ручная версия аудита через чат, и она грубая.
⚠️ Читается через «настройку», а не через промпт: выводы больше про устройство агентных циклов, чем про инструкции. Готовых формулировок для CLAUDE.md или AGENTS.md в статье нет.
Как исследовали
Исследователи взяли открытый набор из 207 тысяч траекторий кодовых агентов (Open-SWE-Traces) и выбрали 600: по 150 из четырёх сочетаний «обвязка × модель». В журналах нет учёта токенов. Поэтому они написали TurnCost, который восстанавливает контекст каждого хода, токенизирует и точно моделирует кэш: при дописывании в конец новым остаётся только последний ответ инструмента.
Дальше сравнили пять вариантов: исходный запуск; смена модели на целый ход; передачу ответа дешёвой модели; то же сильной моделью (чтобы отделить эффект сжатия от эффекта дешёвой модели); простое усечение без вызова модели. Цены нормировали в долях, чтобы выводы не устаревали вместе с прайс-листами.
Что удивило. Во-первых, типичный ответ инструмента — 118–286 токенов, а огромные логи сборки — около 99-го процентиля. Поэтому умное сжатие и обычное удаление дают почти одно и то же, как и в работе AgentDiet. Во-вторых, 98,6% входных токенов приходят из кэша: расчёты без кэша завышают цену примерно в 7 раз. В-третьих, регрессия на 600 запусках: число ходов объясняет 84% разброса логарифма стоимости, средний размер ответа — 4%. Самые дорогие запуски имеют больше всего ходов при самых коротких ответах. Вывод для практики: оптимизируй цикл, а не размер ответов.
Адаптации и экстраполяции
🔧 Техника: добавь в аудит оценку «ходов до первой правки» → видишь, сколько агент разведывает вслепую
В шаг 2 шаблона добавь: «Посчитай, сколько ходов агент сделал до первой правки, и перечисли, что он читал за это время. Какие из чтений оказались нужными для итогового решения?» Это показывает, где агент блуждает, и подсказывает, что вынести в стартовую инструкцию.
Экстраполяция: правило цикла в файле инструкций (гипотеза, не результат статьи)
В статье такого правила нет. Это моя идея по мотивам вывода «ходы дороже наблюдений». Проверяй на 5–10 однотипных задачах, сравнивая число ходов и долю успешных решений:
Правила работы по ходам:
- Перед правкой прочитай все нужные файлы одним пакетом, не по одному.
- Не перечитывай файл, который уже читал в этой сессии, если он не менялся.
- Не запускай ту же команду повторно без правки между запусками.
- Если ответ инструмента усечён, сузь запрос (диапазон строк, фильтр), а не повторяй тот же.
- Если за {N} ходов нет прогресса, остановись и опиши, что пробовал и что блокирует.
Подставь N (например 15–20). Если успехов стало меньше, правило режет полезные проверки — ослабь его.
Ресурсы
- Pramod Kumar, Raj Kumar Pandey (The Pennsylvania State University). TurnCost: Turns, Not Observations: Cache-Aware Loop Engineering for Coding Agents. POVC '26, ASE 2026, Мюнхен. DOI: 10.1145/3843779.3844635
- Данные: nvidia/Open-SWE-Traces (CC BY 4.0). Инструмент TurnCost выложен авторами в открытый доступ.
- Связанные работы: AgentDiet (сжатие траекторий), AgentRouter, SWE-Router, MTRouter, TRACE-Router (маршрутизация шагов), SWE-agent и OpenHands (обвязки агентов).
