ХабрПостыНовостиМегапосты?

Asana снизила стоимость браузерного ИИ-агента в 29 раз, исправив кэш истории

Команда Asana 8 октября рассказала, как оптимизировала браузерного ИИ-агента в платформе StackAI, которая автоматизирует работу с сайтами и веб-формами. По замерам компании, изменения в хранении истории запросов снизили оценочные расходы на одну задачу на исходной модели в 29 раз. Более громкая цифра — 76 раз — получилась при сравнении с оптимизированным вариантом на другой модели, GPT-6.1 Sol.

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

Инженеры стали кэшировать и историю, увеличили допустимый объём сохраняемого текста со 120 до 480 тысяч символов и заменили поштучное удаление скриншотов пакетным. В одной из проверенных политик агент накапливал до 20 снимков, а затем оставлял последний. Так большая часть префикса запроса оставалась неизменной между очистками.

На исходной анонимизированной модели B оценка стоимости прогона упала как минимум с 36,21 до 1,24 доллара — примерно в 29 раз. На оптимизированном GPT-6.1 Sol средняя оценка составила $0,47 и около четырёх минут. Заявленные 76-кратная экономия и пятикратное ускорение сравнивают этот вариант с исходной конфигурацией на модели B, а не одну и ту же модель до и после изменений. Только для Sol изменение политики кэша и скриншотов при большем бюджете сократило расходы в четыре раза.

В исследовании было 144 основных запуска и 12 дополнительных на четырёх моделях. Каждая конфигурация решала одну задачу: собрать шесть полей о 32 книгах из демонстрационного каталога, обычно с тремя повторами. Это не независимый отраслевой бенчмарк и не доказательство, что любой агент станет дешевле в 76 раз. Практический вывод: перед сменой модели стоит измерить долю попаданий в кэш, частоту изменения истории и стоимость полностью завершённого задания.

@reddice
11.10.2026 18:22 UTC
Первоисточник

Комментарии

@melliewar
11.10.2026 13:44 UTC
+1

Странно, что сравнивали не с Астрой.

11.10.2026 14:39 UTC
0

Видимо, цифра получалась меньше :)

@Flux
11.10.2026 15:52 UTC
+1

“Мы написали (нам написала LLM) говнокод который ломал кеширование, а потом починили его. С кешированием дешевле чем без него”.

О чем, собственно, статья? Почему исправление ошибки которую 5 лет назад не допустил бы даже джун сейчас подается как оптимизация, достойная отдельной статьи в блоге?

11.10.2026 16:53 UTC
+2

Если бы вайб-кодеры умели читать, они бы очень расстроились

11.10.2026 17:15 UTC
0

🥺