Инженеры Cursor описали, как оптимизировали свой агентский харнесс — обвязку, которая собирает запросы, управляет контекстом, инструментами и кэшем, — и снизили затраты на токены на 7% без потери качества агента. Эффект разложен на независимые приёмы: системный промт сокращён примерно на 66% за счёт отказа от команд вида «DO NOT» и «You must», описания статических инструментов урезаны на 60% через динамическую подгрузку, явные cache breakpoints в API OpenAI дали на 20% меньше холодных промахов кэша, а нумерацию строк в Read оставили только на каждой десятой строке. Помимо технического разбора в блоге, команда опубликовала готовый промт, который можно отдать собственному агенту как задание на дешёвую сборку или рефакторинг его харнесса.

image

Что произошло

Команда Cursor опубликовала в блоге пост «Improved Token Efficiency for Longer Agent Runs», посвящённый оптимизации собственного агентского харнесса, а в Telegraph выложила построенный на этих приёмах длинный промт для самостоятельной сборки подобной обвязки. По замерам компании, суммарная экономия составила 7% токенов за задачу без падения качества агента, причём эффект проверяли A/B-тестами на реальном продовом трафике, а не синтетическими бенчмарками. Системный промт сократили примерно на 66%, заменив прямые команды «DO NOT» и «You must» описаниями инструментов. Описания статических инструментов урезали на 60% за счёт динамической подгрузки: из постоянного контекста убрали всё, что нужно реже чем в 20% сессий. Явные точки кэша в API OpenAI, доступные с GPT-5.6, дали на 20% меньше холодных промахов кэша, а разреженная нумерация строк в Read — номер строки печатается только на каждой десятой позиции — убрала ещё 1,6% токенов чтения из кэша.

Контекст

Харнесс — это обвязка вокруг модели, которая собирает запросы, управляет контекстом, списком инструментов и кэшем, поэтому именно от того, что она отправляет в модель, зависит, сколько токенов уходит на задачу. Ключевой механизм у Cursor — управление границей кэша: переменные данные вроде skills, окружения и правил переносятся за границу кэша в «phantom user message», а cache breakpoints ставятся после стабильных слоёв контекста и перед растущей историей диалога, чтобы стабильная часть не перевычислялась заново. Экономия достигается изменением состава и порядка отправляемого контекста, а не просьбами к модели быть бережливее. Тот же принцип динамического контекста вместо статического Cursor раньше проверяли на MCP-инструментах: их перевод в динамическую подгрузку давал −46,9% токенов в сессиях с MCP, что согласуется с новыми замерами. Методологически важно, что цифры получены на продовом трафике: это снижает риск cherry-picking, но делает метрики чувствительными к профилю задач, составу инструментов и конкретной модели.

Почему это важно для индустрии

Для агентских продуктов это прямое влияние на юнит-экономику: заявленный эффект за один проход — минус 7% цены за задачу — задаёт воспроизводимый ориентир, с которым команды могут сравнивать собственные замеры. Приёмы применимы к любому API с prompt caching и не требуют смены модели, поэтому барьер входа низкий. Плейбук опубликован открыто, и это обесценивает «умную обвязку» как отдельное УТП: базовую оптимизацию теперь может воспроизвести любая команда. Если цифры подтвердятся у других команд, динамическая подгрузка инструментов, cache breakpoints и вынос переменных данных за границу кэша с высокой вероятностью станут стандартными частями харнесс-фреймворков, а защитные инструкции времён старых моделей начнут массово вычищать; «стоимость задачи» при этом может стать стандартной метрикой дашбордов наравне с latency и качеством. В более длинной перспективе — и это интерпретация, а не факт из источников, — оптимизация «что отправлять в модель» способна выделиться в отдельную инженерную дисциплину с собственными бенчмарками, профилировщиками контекста и регрессионными тестами на стоимость, а экономика агентов будет оптимизироваться на уровне обвязки так же системно, как на уровне моделей.

Почему это важно для пользователей

Если вы собираете свой харнесс или пайплайн вокруг LLM, у вас есть готовый план, применимый в тот же день и без смены модели. Первый шаг — замерить долю расходов по источникам и типам биллинга: output, uncached и cached. Дальше нужно вычистить из системного промта защитные инструкции, оставшиеся от старых моделей, заменив команды «DO NOT» и «You must» описаниями инструментов. Статичными стоит оставить только высокочастотные инструменты вроде read, search, edit и shell, а редкие перевести на динамическую подгрузку. Затем выставляются cache breakpoints после стабильных слоёв контекста, а нумерация строк в Read переводится на разреженный режим с номером лишь на каждой десятой строке. Отдельный быстрый путь — взять промт из Telegraph и скормить его собственному агенту как задание на рефакторинг харнесса; технический разбор в блоге Cursor объясняет, почему каждый приём работает.

Что пока неизвестно / ограничения

В публичных материалах не раскрыты детали методологии A/B-тестов: объём выборки, состав трафика, набор моделей и длительность наблюдения остаются неизвестными. Также не раскрыто, как именно операционализировали «отсутствие потери качества» — какая метрика качества измерялась. Все цифры являются vendor self-reported от Cursor, независимых репликаций на других нагрузках и API пока нет, поэтому переносимость результатов на чужие пайплайны не подтверждена. Наконец, эффект для конкретного пайплайна заранее неизвестен и зависит от доли статического контекста и кэшируемости последовательности, так что стартовая точка — собственный замер, а не чужие цифры.

Источники

Автор

Look at AI, редакция