«Минус 7% стоимости токенов при том же качестве»: Cursor перестроила обвязку агентов и урезала системный промпт на 66%

Что изменила Cursor

Cursor опубликовала разбор того, как её агентская обвязка (harness) экономит токены на длинных прогонах: по данным компании, изменения в нескольких слоях снизили стоимость токенов для пользователей на 7% без потери качества агента. Пост вышел 23 сентября 2026 года в разделе research; авторы — Jediah Katz, Connor O’Keefe и Calvin Yee.

Куда уходит расход

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

System prompt: минус примерно две трети

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

Пока модели были слабее, приходилось прописывать инструкции про использование инструментов, управление задачами и работу с изменениями кода, а также защищаться от странного поведения вроде дампов хэшей, бинарного вывода и эмодзи. С ростом качества моделей это стало ненужным: вместо длинных списков «DO NOT do this», «You must» или «Important» достаточно определить поведение инструмента, и модели в целом следуют ему — эффект подтвердился на разных семействах моделей, что позволило урезать системный промпт примерно на 66%.

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

Инструменты грузятся только тогда, когда нужны

Второй крупный источник статического контекста — определения инструментов, которые за год заметно разрослись вместе с возможностями агента: фоновое наблюдение за шеллом, облачные субагенты, более надёжный доступ к веб-контенту. Большинство этих инструментов важно, но каждый нужен меньше чем в 20% разговоров.

Схожую задачу Cursor решала раньше с MCP: перевод их в динамический контекст снизил общие расходы токенов на 46,9% в сессиях, где вызывался хотя бы один MCP-инструмент. Теперь тот же приём применён к собственным встроенным инструментам — по данным компании, это урезало токены описаний в статическом контексте на 60%. В статике остались высокочастотные инструменты для чтения, поиска, редактирования и работы с шеллом, а также ask_question, вызовы которого некоторые модели склонны галлюцинировать, и инструменты, критичные для отдельных продуктовых сценариев вроде create_plan в Plan Mode; остальные подгружаются по необходимости.

Это часть общей линии Cursor: в посте про Cursor Router компания описывает динамический вызов инструментов как пример того, что большинство нативных описаний инструментов больше не грузится в каждый промпт, а «горячими» остаются общие инструменты вроде read и edit.

Кэш: явные точки разрыва и «фантомное» сообщение

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

Точки разрыва помогают только при стабильном префиксе, поэтому компания заодно ужесточила состав начала запроса: инструменты и системные инструкции оставлены для редко меняющегося содержимого, а более переменная настройка — включая skills, субагентов и информацию об окружении — вынесена за границы кэша в «фантомное пользовательское сообщение». Результат — снижение частоты холодных промахов кэша на 20%.

Номера строк через десять

Ещё один слой — то, что агент добавляет сам по ходу работы, и в первую очередь чтение файлов: инструмент Read традиционно нумеровал каждую строку, потому что модели плохо считают строки и должны ссылаться на конкретные участки. Один номер строки стоит примерно три–пять токенов, но при чтении десятков тысяч строк за сессию нумерация каждой даёт заметный объём контекста. Cursor стала ставить номера только на каждой десятой строке — по её оценке, этого достаточно, чтобы модели корректно ссылались на код, а расход токенов на чтение из кэша снизился на 1,6% без потери качества.

Субагенты: меньше подсказок, строже выбор модели

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

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

Что дальше

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