Браузерный ИИ-агент в 76 раз дешевле: что на самом деле сделали Asana и StackAI

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

9.10.2026 OpenAI опубликовала исследование Asana / StackAI. StackAI — платформа, через которую клиенты Asana без кода собирают процессы: агент ходит по сайтам, заполняет формы, собирает данные. Технический директор StackAI в Asana Фрэнк Идальго поручил GPT-6 Astra в Codex разобрать код агента, предложить улучшения и прогнать сравнение. Оптимизированный процесс работает на GPT-6.1 Sol.

Итог по данным источника: в среднем 0,47 доллара расчётных затрат на модель и около четырёх минут на запуск. Это в 76 раз дешевле и примерно в 5 раз быстрее исходной рабочей настройки.

Отдельная деталь, которую я бы не пропускала: работу, на которую вручную, по оценке Идальго, ушло бы один-два месяца, сделали примерно за неделю. Человек задавал цель и проверял выводы, агент ставил эксперименты.

Где утекали деньги

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

У StackAI было две проблемы.

1. В кэш попадали только постоянные инструкции и инструменты. Растущая история страниц и скриншотов шла по полной цене с каждым запросом.
2. Почти на каждом шаге агент удалял старые скриншоты и сокращал текст. Любая такая правка меняет начало истории, и кэш перестаёт совпадать. Хуже того, потеряв уже прочитанное, агент возвращался на те же страницы и повторял действия.

Получается, деньги уходили не на «умную» работу модели, а на бесконечную пересылку одного и того же контекста и на повторные шаги.

Три подхода, которые проверили

• кэш истории браузера;
• больше сохранённого контекста;
• пакетное удаление старых скриншотов.

На практике это выглядело так: историю тоже стали кэшировать, лимит истории подняли со 120 000 до 480 000 символов, а скриншоты перестали удалять по одному. Лучшей оказалась схема, при которой снимки копятся до 20, после чего остаётся только последний. Между такими «уборками» ранняя часть истории не меняется, и кэш работает.

Почему «в 76 раз» — это не про смену модели

Это главное место, где кейс легко пересказать неправильно. Разложу цифры.

Что из этого следует:

• Самый большой рычаг — архитектура. На той же модели, что уже работала в рабочей среде, затраты упали в 29 раз без смены поставщика.
• На одной Sol оптимизация контекста дала снижение в 4 раза: каждый вызов стал примерно втрое дешевле, потому что 89% входных данных шли из кэша.
• «В 76 раз» появляется, только когда одновременно меняются модель и архитектура. Если вы просто переключите агента на новую модель и оставите старую схему памяти, такого результата ждать не стоит.

Ещё один показательный результат: при малом лимите истории GPT-6.1 Sol дала ответ только в 3 запусках из 18, при большом — во всех 18, и все ответы были правильными. То есть экономия на памяти агента бьёт не только по деньгам, но и по способности вообще довести задачу до конца.

Что я бы мерила у себя

Asana смотрела не на «стало дешевле», а на набор показателей. Я бы взяла те же:

• доля кэшированных токенов;
• размер повторного контекста;
• повторные действия;
• стоимость успешной задачи.

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

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

Ограничения, о которых нельзя молчать

• Одновременно менялись модель и архитектура. Вклад каждого фактора виден только в отдельных сравнениях из таблицы выше.
• Ограниченный набор задач с повторами. Все конфигурации решали одну задачу: собрать шесть полей для 32 книг из открытого демонстрационного каталога, по три запуска на каждый вариант, всего 144 запуска.
• Не переносить на любые сценарии. Длинные задачи, другие сайты, модели с другим окном контекста и другой ценой чтения из кэша дадут другие цифры. Сама Asana в своём блоге пишет, что при трёх-четырёх запусках на условие видны общие закономерности, а не разница в несколько процентов.
• Даже сама пакетная обрезка — не универсальный рецепт. В дополнительном эксперименте Asana сохраняла все скриншоты без всякой обрезки: вызов вышел в 1,2 раза дешевле лучших условий для исходной модели и GPT-6.1 Sol и примерно на 5% дешевле для обновлённой версии исходной модели. Asana делает вывод, что в этой задаче обрезка, возможно, вообще не нужна, но остаётся важной для длинных задач, небольших окон контекста и более дорогого чтения из кэша.

Что делать, если у вас уже работают агенты

1. Посмотрите, что ваш агент пересылает на каждом шаге и какая часть этого попадает в кэш. Это видно по счётчикам токенов у поставщика модели.
2. Проверьте, не переписывает ли агент историю на каждом шаге. Обрезка «по чуть-чуть» почти всегда ломает кэш.
3. Подберите лимит истории под модель: слишком маленький лимит заставляет агента забывать прочитанное и повторять шаги.
4. Сравнивайте варианты на одной и той же задаче и считайте стоимость успешного результата, а не одного вызова.
5. Только после этого решайте, нужна ли другая модель.

Мой вывод

Этот кейс я читаю не как рекламу новой модели, а как напоминание: расходы на ИИ-агентов во многом определяет инженерия памяти. Кэш, лимит истории и порядок «уборки» контекста дают кратный эффект ещё до смены модели. Новая модель усиливает этот эффект, но не заменяет его.

О том, как считать бюджет на нейросети через токены, я писала в статье «Бюджет на нейросети: токеномика AI и экономия бизнеса». А почему контекст — это актив, а не мусор, который надо постоянно чистить, — в материале «Накопленный контекст в ИИ как профессиональный капитал».