Cursor сократила расход токенов на 7%: пять приёмов харнесса агента

Агенты стали работать дольше. Каждый новый шаг несёт в себе контекст предыдущего, и стоимость одного запуска растёт быстрее, чем объём полезной работы. 23 сентября 2026 года команда Cursor описала в блоге, как оптимизировала свой харнесс — ту обвязку вокруг модели, которая собирает запрос, переиспользует кэш и решает, когда отдать часть работы субагенту. Итог: минус 7% расхода токенов на пользователя при том же качестве агента. Пять приёмов, которые за этим стоят, разбираем ниже.

Откуда уходят деньги

Сначала Cursor разложила трафик на три части: сколько токенов уходит на ответ модели, на ввод без кэша и на ввод из кэша. Отдельно команда посчитала, что именно лежит в контексте:

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

1. Системный промпт похудел на 66%

Раньше, когда модели были слабее, приходилось подробно расписывать в системном промпте, как пользоваться инструментами, как вести задачи и как менять код. Отдельно добавляли запреты: не выдавать огромные дампы хэшей, не печатать бинарные данные, не сыпать эмодзи.

С моделями нового поколения всё это оказалось лишним. Вместо длинных списков «не делай этого», «ты обязан», «важно» хватило одного описания поведения инструмента — и модель обычно сама соблюдает правила. Работало это одинаково у всех семейств моделей, так что системный промпт удалось сократить примерно на 66%.

Отдельная мысль Cursor про методику проверки. Инструкции приходится постоянно добавлять и убирать, потому что новые модели требуют новых подсказок. Эти подсказки потом попадают в обучение следующих моделей. Помогают A/B-тесты на большой базе пользователей. Эвалы тоже полезны, и работают они быстро. Но по словам команды, эвалы чаще всего состоят из «сложных» задач. Поэтому они плохо отражают настоящее распределение запросов пользователей.

2. Инструменты грузятся только когда понадобятся

Системный промпт — лишь часть контекста, который Cursor отправляет на каждом ходу. Вторая часть — описания инструментов. За год они разрослись: добавились фоновый мониторинг shell, облачные субагенты, более надёжный доступ к содержимому веба. Инструменты важные, но каждый из них нужен меньше чем в 20% разговоров.

С похожей задачей Cursor столкнулась раньше в этом году. Тогда описания MCP-инструментов перенесли в динамический контекст, чтобы они загружались по требованию. На сессиях, где MCP-инструмент всё-таки вызывали, общее число токенов упало на 46,9%. Теперь тот же приём применили к собственным встроенным инструментам.

Чтобы решить, что оставить в статическом контексте, команда прогнала A/B-тесты нескольких конфигураций. Смотрели на частоту вызова каждого инструмента. Смотрели и на то, нужна ли модели схема этого инструмента с самого начала. Замеряли расход токенов, стоимость, задержку, ошибки вызова инструментов и общую активность агента. Нужно было убедиться, что экономия не бьёт по качеству.

В статическом контексте остались:

• инструменты для чтения, поиска, редактирования и работы с shell — ими пользуются чаще всего;
• ask_question — некоторые модели склонны вызывать его без повода, даже когда он не нужен;
• инструменты, важные для отдельных сценариев продукта, например create_plan в режиме планирования.

Остальные инструменты теперь загружаются, когда агенту они действительно нужны. Суммарно это урезало описания инструментов в статическом контексте на 60%.

3. Явные точки кэширования в OpenAI API

После уменьшения статического контекста команда занялась тем, как повторяющийся контекст переиспользуется между ходами.

Кэширование промптов позволяет провайдеру модели переиспользовать неизменное начало запроса. Но возможности управления этим кэшем зависят от провайдера. До GPT-5.6 граница кэша определялась автоматически по последнему запросу. Инструменты и системные инструкции менялись редко, но отдельным куском они не помечались как переиспользуемые.

Начиная с GPT-5.6 API OpenAI позволяет клиенту расставлять явные точки кэширования поверх обычного автоматического кэширования. Cursor ставит их после стабильных слоёв запроса и перед разговором, который растёт. Так последующие ходы переиспользуют больше неизменного начала.

Точки кэширования работают, только если начало запроса действительно стабильно. Поэтому Cursor дополнительно ужесточила правила, что именно стоит в начале запроса. Инструменты и системные инструкции оставили для контента, который меняется редко. А всё, что меняется от запроса к запросу, перенесли за границу кэша в так называемое «призрачное сообщение пользователя». В нём лежит контекст, привязанный к пользователю и к текущему запросу: skills, субагенты, сведения об окружении.

Вместе эти изменения снизили долю промахов по холодному кэшу на 20%.

4. Номера строк — только на каждой десятой

Значительная часть расхода — это контекст, который агент добавляет по ходу работы. И большая его часть приходит из чтения файлов.

Инструмент Read у Cursor раньше нумеровал каждую строку. Причина в том, что модели плохо считают строки сами. Вторая причина — пользователю нужно ссылаться на конкретные места в коде.

Один номер строки стоит всего 3–5 токенов. Но за сессию агент читает десятки тысяч строк, и нумерация каждой строки добавляет заметный объём контекста. Теперь номера выводятся на каждой десятой строке. Модели этого достаточно, чтобы корректно ссылаться на код, а расход токенов на чтение из кэша упал на 1,6% без потери качества.

5. Субагенты — по делу, модель — по указанию

Чем дольше идёт работа агента, тем больше поводов передать часть задачи субагенту. Это экономит токены: субагент обычно начинает с чистого контекстного окна, а не тащит весь разговор родителя. Отчитавшись о результате, он возвращает короткое резюме, и родитель продолжает работу без всей этой рабочей массы.

Плата за такую изоляцию — координация. Агенты, которые не видят контекст друг друга, могут продублировать работу или взяться за задачу, которая уже не нужна.

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

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

Что дальше

Команда обещает продолжать измерять, как копится контекст на длинных прогонах, и искать места, где обвязка сокращает повторную обработку без потери качества. В перспективе расход токенов должен расти заметно медленнее объёма работы, который агент способен выполнить. Часть наработок команда уже переносит в Grok Bot, оптимизируя его обвязку по той же схеме.

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