3,583 papers
arXiv:2610.15093 71 10 окт. 2026 г. FREE

TurnCost: стоимость работы кодового агента определяют ходы, а не размер ответов инструментов

КЛЮЧЕВАЯ СУТЬ
Парадокс: самые дорогие запуски кодовых агентов — те, где ответы инструментов самые короткие. Метод TurnCost позволяет увидеть, куда реально уходят деньги в сессии с агентом, и не тратить недели на сжатие логов, которое почти ничего не даёт. Агент отправляет весь диалог заново на каждом ходу, а кэш префикса (кэш начала диалога) делает старую часть в 10 раз дешевле. Исследователи пересчитали 600 реальных запусков с учётом кэша. Число ходов объясняет почти весь разброс стоимости, размер ответов инструментов — почти ничего.
Адаптировать под запрос
⚡

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 (обвязки агентов).

📋 Дайджест исследования

Ключевая суть

Парадокс: самые дорогие запуски кодовых агентов — те, где ответы инструментов самые короткие. Метод TurnCost позволяет увидеть, куда реально уходят деньги в сессии с агентом, и не тратить недели на сжатие логов, которое почти ничего не даёт. Агент отправляет весь диалог заново на каждом ходу, а кэш префикса (кэш начала диалога) делает старую часть в 10 раз дешевле. Исследователи пересчитали 600 реальных запусков с учётом кэша. Число ходов объясняет почти весь разброс стоимости, размер ответов инструментов — почти ничего.

Принцип работы

Считай стоимость так, как её считает провайдер. Цикл простой: ход → ответ инструмента → следующий ход. Каждый новый ход добавляет ещё один проход по накопленному контексту. Ответ инструмента — пара сотен токенов. Контекст — десятки тысяч. Поэтому число ходов бьёт по счёту сильнее, чем размер ответа. Это как такси со счётчиком: платишь за каждую поездку, а не за вес багажа. Сначала ищи лишние ходы, и только потом думай про сжатие и смену модели. Смена модели посреди сессии убивает кэш. Новая модель читает весь контекст заново по полной цене.

Почему работает

Кэш работает, пока диалог только дописывается в конец. Всё старое читается примерно за десятую часть цены. Полную цену платишь почти только за последний ответ. Поэтому стоимость можно посчитать точно, а не гадать. Прайс-лист без кэша врёт. Дешёвая модель с ценой входа в 5 раз ниже списочной цены сильной может оказаться убыточной. Выгода есть, только если цена входа дешёвой модели ниже цены кэш-чтения сильной. Жесть: в половине проверенных сценариев переход на дешёвую модель увеличил расходы. Ещё один неприятный факт для любителей сжатия: простое обрезание ответов экономит столько же, сколько сжатие моделью. Огромные логи редкость. Крупные ответы чаще дают правки файлов, а их сжимать опасно.

Когда применять

Разработка с кодовыми агентами (Cursor, Claude Code) → разбор счёта за сессии, особенно когда команда спорит: «сжимать логи» или «поставить дешёвую модель на чтение файлов». Если дешёвая модель всё же нужна, отдавай ей только узкий срез (ответ инструмента), а не весь диалог. НЕ подходит как доказательство, что сокращение ходов не ломает результат: авторы этого не проверяли. Данные только на двух открытых моделях, закрытые могут вести себя иначе. Ручной аудит через чат грубый: токены модель оценивает на глаз.

Мини-рецепт

1. Выгрузи журнал: возьми историю сессии агента или логи запусков. Нужны номер хода, действие и ответ инструмента.
2. Запусти аудит: вставь журнал в чат с шаблоном ниже. Модель разложит ходы по типам и покажет доли.
3. Лови повторы: одинаковый запрос без изменений, та же команда без правки между запусками, повторное чтение файла.
4. Сравни два рычага: что в этой сессии дороже, число ходов или размер ответов? Требуй цифры.
5. Прежде чем менять модель: сравни цену входа дешёвой с ценой кэш-чтения сильной. Если не ниже, не трогай.
6. Проверь качество: после сокращения ходов посмотри, не упало ли число решённых задач.

Шаблон:
Ниже журнал сессии кодового агента ({инструмент}) по задаче «{задача}». Каждая строка: номер хода, действие агента, ответ инструмента. Сделай аудит ходов: 1) раздели ходы на чтение/запуск, правку, завершение и рассуждение без инструмента; 2) посчитай долю каждого типа и среднюю длину ответа в токенах; 3) найди лишние ходы: повторный запрос, повторный запуск без правки, повторное чтение файла; 4) для каждого лишнего хода дай номер и более короткий путь; 5) скажи, что дороже: число ходов или размер ответов. Журнал: {журнал_сессии}

Примеры

[ПЛОХО] : Как сжать логи тестов, чтобы агент тратил меньше токенов?
[ХОРОШО] : Ниже журнал сессии Cursor по задаче «починить парсер выгрузки заказов Ozon и Wildberries». Классифицируй каждый ход: чтение/запуск, правка, завершение, рассуждение. Посчитай долю ходов и среднюю длину ответа в токенах. Найди ходы, где файл читали повторно или команду запускали без правки между запусками. Для каждого дай номер хода и что агент мог сделать вместо него. В конце ответь: что дороже в этой сессии, число ходов или размер ответов? Журнал: {журнал} Первый запрос лечит симптом, которого почти нет. Второй показывает, где агент ходит кругами. В примере из 140 ходов такие повторы и есть главная статья расходов.
Источник: TurnCost: Turns, Not Observations: Cache-Aware Loop Engineering for Coding Agents
ArXiv ID: 2610.15093 | Сгенерировано: 2026-10-14 06:00

Концепты не выделены.

📖 Простыми словами

TurnCost: Turns, Not Observations: Cache-Aware LoopEngineeringfor CodingAgents

arXiv: 2610.15093

Ты думаешь, твой AI-программист сжигает бюджет, когда читает гигантские файлы или простыни логов? Полная чушь. Главный пожиратель денег — количество ходов агента, а не размер данных от инструментов. В каждом новом цикле модель перечитывает всю историю диалога заново. Даже хвалёный кэш префикса, который отдает старый контекст примерно за десятую часть цены, не спасает, если агент делает десятки мелких шагов туда-обратно.

Это как дотошный начальник: каждый раз, когда ты приносишь ему статус на одну строчку, он заставляет тебя перечитывать вслух весь проект с первой страницы. Принес сто мелких правок за день — перечитал библиотеку сто раз. В итоге суетливая возня обходится в разы дороже, чем если бы ты притащил один огромный отчет за один заход. Формально работа кипит, но бюджет улетает в трубу на чистом воздухе.

Авторы исследования TurnCost пересчитали расходы на 600 реальных запусках кодовых агентов и вскрыли этот абсурд. Оказалось, что число ходов объясняет почти весь чек, а размер выхлопа от утилит не решает вообще ничего. Самыми разорительными оказались сессии, где агент тупил микроскопическими итерациями: данных получил с гулькин нос, зато накрутил рекордное количество циклов.

Тестировали на коде, но грабли одинаковы для любых агентов. Исследовательский бот, автономный маркетолог или парсер вакансий утянут тебя в минус, если будут перепроверять каждый чих отдельным запросом. Архитектура цикла решает всё: пока агент гоняет пустые размышления, ты заново оплачиваешь десятки тысяч токенов истории на каждом шаге.

Короче: хватит трястись над размером логов и начни резать лишние итерации. Заставляй агента группировать действия и выдавать результат пачками, иначе никакой кэш не спасет проект от банкротства. Меньше беготни по кругу — целее баланс. Кто перестроит логику циклов, срежет косты в разы, а остальные продолжат гадать, куда утекают тысячи долларов на пустом месте.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с