Та же модель, меньше счёт — как harness собирает каждый запрос
Саммари
Агент для кодинга не помнит предыдущие шаги: на каждом ходе harness заново собирает запрос из системных инструкций, описаний всех инструментов, служебного контекста и всей истории диалога, и провайдер берёт оплату за каждое такое чтение. Автор разбирает, как Cursor сократил расходы на токены, не меняя основную модель, и какие источники стоимости вообще контролируются разработчиком.
Из этого следует, что стоимость агентной сессии определяется не числом сообщений, а тем, сколько раз за сессию перечитывается неизменяемый префикс. Поэтому первый вопрос при оптимизации — что харнесс отправляет на каждом ходе, а не какую модель выбрать.
На практике для инструментов работает правило «описание загружается по требованию»: если инструмент нужен меньше чем в каждом пятом разговоре, держать его полное описание в каждом запросе невыгодно. Это совпадает с выводом о потолке числа видимых тулов из S174.
Важный нюанс: 7% экономии, которые Cursor называет для своих пользователей, — самоотчёт вендора без базовой линии и размера выборки; неясно, это токены или деньги. Ценность статьи в направлении оптимизации, а не в конкретном проценте, который нельзя перенести на свой проект.
Ограничение: переносимость снижена, если у вас нет контроля над харнессом (например, работаете только через готовый клиент). Тогда доступны лишь рычаги на стороне своих инструментов и промптов.