Команда StackAI by Asana изменила сборку запросов браузерного ИИ-агента и в тестах сократила оценочную стоимость запуска на исходной модели B в 29 раз — с 36,21 до 1,24 доллара. Событие важно не само по себе как ценовой рекорд: оно показывает, что в многошаговых агентных сценариях существенная часть расходов может возникать из-за повторной передачи уже известного модели контекста. Как следует из описания эксперимента OpenAI, оптимизация затронула историю работы агента, а не его прикладную логику.
Почему история ломала кэш.
Браузерный агент на каждом шаге отправляет модели системные инструкции, описание доступных инструментов, текст просмотренных страниц и снимки экрана. Постоянная часть запроса уже попадала в кэш, но накопленная история — нет. При этом история регулярно менялась: агент удалял старые снимки и сокращал текст, чтобы уложиться в лимит. Для кэша критичен неизменный начальный фрагмент запроса: если правка происходит в ранней части истории, повторное использование контекста обрывается с этой точки.
Инженеры добавили историю в кэш, увеличили её текстовый бюджет со 120 тысяч до 480 тысяч символов и перешли от удаления снимков на каждом шаге к пакетной очистке. В техническом разборе StackAI описана политика 20:1: агент собирает до 20 снимков, затем оставляет один. Это позволяет сохранять неизменной большую часть истории примерно на 19 последовательных вызовов. По данным компании, чтение из кэша на протестированных моделях стоило от 0,05 до 0,1 от обычной цены входных токенов, поэтому эффект зависит и от тарифов конкретного провайдера.
Что именно сравнивали.
Проверка включала шесть политик кэширования и обработки снимков при двух лимитах истории, четыре модели и три запуска каждого условия — всего 144 основных запуска, а затем ещё 12 в дополнительной серии. В публикации Asana уточняется, что демонстрационный сценарий включал поиск сведений о 32 книгах в каталоге и подсчёт цен. Это полезный, но узкий тест: он измеряет работу агента с растущей историей страниц, а не все типы браузерной автоматизации.
Точные показатели для модели B приведены в сообщении о результатах исследования: оптимизированный вариант стоил в среднем 1,24 доллара за запуск и работал примерно вчетверо быстрее исходной конфигурации. В документации Asana также заявлено, что в лучшем сценарии 89% входных данных считывались из кэша. Это объясняет одновременно снижение стоимости и задержки: агент реже передаёт большой объём новых токенов, хотя число браузерных действий само по себе от этого не обязательно уменьшается.
Почему 76 раз не равно эффекту одной оптимизации.
Число в 76 раз относится к сравнению исходной конфигурации на модели B с оптимизированным агентом на GPT-6.1 Sol, где средняя оценочная цена запуска составила 0,47 доллара, а время — около четырёх минут. Поэтому его нельзя читать как результат одной правки кэша на одной модели. Как разбирает анализ методики сравнения, исправление рабочего процесса на модели B дало 29-кратное сокращение, а переход к GPT-6.1 Sol обеспечил оставшуюся разницу. Для Sol изменение политики истории и снимков при увеличенном бюджете отдельно снизило затраты примерно в четыре раза.
Такое разделение особенно существенно для закупок и архитектурных решений. Если сопоставлять новую модель со старой конфигурацией агента, итоговая цифра объединяет как свойства модели, так и ошибки в организации контекста. Сначала имеет смысл сравнить одну и ту же модель до и после изменений в prompt cache, а затем отдельно оценивать модельную замену по стоимости, времени и качеству выполнения задачи.
Практические последствия для команд.
Результат нельзя считать универсальным бенчмарком для всех агентов. Три модели в исследовании названы лишь Model A, B и C, а публично доступны не все детали, необходимые для воспроизведения. Кроме того, как отмечает независимый разбор отчёта, публикация не раскрывает полный набор задач, показатели успешности и влияние повторных попыток на ускорение. Компания сообщала, что ответы сравнивались с заранее подготовленным эталоном, но этого недостаточно, чтобы перенести коэффициенты на другой продукт.
Для разработчиков главный вывод — измерять агентный цикл целиком: долю токенов из кэша, объём нового ввода, число шагов, повторные заходы на страницу, задержку и успешность задачи. История должна оставаться append-only настолько долго, насколько это возможно; сокращать её лучше пакетно, а лимит текста выбирать с учётом реальной длины траекторий. История Asana не доказывает, что дорогие модели стали дешёвыми во всех сценариях, но показывает, что структура контекста может менять экономику браузерного агента сильнее, чем очередная замена модели.
