Asana удешевила браузерного агента StackAI в 76 раз в тестах на GPT-6.1 Sol
Asana через платформу StackAI, которую компания приобрела, помогает клиентам автоматизировать работу в бизнес-приложениях: без написания кода можно собирать рабочие процессы, которые переходят по сайтам, заполняют формы и собирают информацию. CTO StackAI в Asana Frank Hidalgo, PhD, решил сделать браузерного агента быстрее и дешевле и поручил модели GPT-6 Astra в Codex изучить агента, проверить улучшения и сравнить результаты. По его собственной оценке, работа, на которую вручную ушло бы один-два месяца, заняла около недели.
GPT-6 Astra сначала разобрала кодовую базу и показала, как агент формирует каждый запрос к модели. Выяснилось, что агент кэшировал фиксированные инструкции и описания инструментов, но не растущую историю текста страниц и скриншотов, поэтому каждый запрос заново отправлял эту историю по полной цене. К тому же почти на каждом шаге агент выбрасывал старые скриншоты и обрезал текст: каждая такая правка меняла историю, и кэширование одной лишь истории ничего бы не дало. Потеря этих данных могла заставить агента повторно заходить на уже прочитанные страницы.
Hidalgo просмотрел предложенные исправления и выбрал три для проверки: расширить кэширование на историю просмотра, увеличить объём сохраняемого текста и удалять скриншоты пачками, а не на каждом шаге. Код не был рассчитан на контролируемые эксперименты, поэтому модель сначала провела быстрые пробные прогоны, а затем переработала код так, чтобы один фронтенд и бэкенд поддерживали много рабочих процессов параллельно, у каждого со своими настройками.
Полное исследование проводила Astra: два бюджета истории (120 000 и 480 000 символов) и шесть политик кэширования и работы со скриншотами, каждая по три раза на каждой из четырёх моделей. Всего получилось 144 запуска; кроме GPT-6.1 Sol в тесте участвовали три другие передовые модели, названные в материале Model A, B и C. Лучшая политика позволяла накапливать до 20 скриншотов, после чего оставляла только последний: ранняя часть истории дольше оставалась неизменной между удалениями. В сочетании с большим бюджетом истории это и стало оптимизированным процессом. Задача во всех конфигурациях одна: собрать шесть полей для каждой из 32 книг из публичного демонстрационного каталога; по словам Asana, она представляет то, что запускают некоторые клиенты в StackAI.
Итог по версии материала: оптимизированный процесс на GPT-6.1 Sol в среднем обходился в $0,47 оценочной стоимости модели и занимал около четырёх минут за запуск, что в 76 раз дешевле и в 5 раз быстрее исходной production-конфигурации на Model B. Для самой Model B оптимизация снизила оценочную стоимость с как минимум $36,21 (часть исходных запусков упёрлась в лимит шагов и не завершилась) до $1,24 за запуск, то есть в 29 раз; GPT-6.1 Sol оказалась ещё в 2,6 раза дешевле, $0,47. На одной только GPT-6.1 Sol при большем бюджете истории новая политика снизила стоимость в 4 раза, с $1,97 до $0,47 за запуск: каждый вызов подешевел примерно втрое, потому что 89% входных данных пришло из кэша по цене 5% от цены некэшированных. Время запуска сократилось с минимум 22,5 минуты на исходной конфигурации Model B до примерно четырёх минут. Каждый запуск оптимизированного процесса выполнил задачу и вернул правильный ответ.
Отдельное наблюдение: на GPT-6.1 Sol увеличение бюджета истории подняло число запусков, дошедших до ответа, с трёх из 18 до всех 18, и все ответы были верными. Для Hidalgo практическая ценность в том, что клиенты получают доступ к более быстрым и мощным моделям при устойчивых операционных расходах.
Asana уже выпустила изменения в навигации браузерного агента в StackAI и разрабатывает инструменты, чтобы такие эксперименты легче повторялись. Со временем команда планирует встроить это тестирование в оценочные проверки платформы, чтобы клиенты и внутренние команды могли сравнивать стоимость, время работы и качество ответов при настройке агентов. Кроме того, Asana теперь использует GPT-6 Astra в Codex для проверки функций продукта перед выпуском: Astra ходит по платформе, пробует разные входные данные и сообщает об ошибках для проверяющих людей. Все сессии исследования записывались в Command, платформе поставки ПО Asana, откуда выводы превращались в задачи, затем в запросы на слияние кода и попадали в продакшен.
Ключевые факты
- В исследовании Asana на 144 запуска сравнивались GPT-6.1 Sol и три анонимизированные модели (A, B, C): оптимизированный процесс на GPT-6.1 Sol в среднем стоил $0,47 оценочных расходов и занимал около четырёх минут за запуск.
- Цифры 76x и 5x сравнивают оптимизированный процесс на GPT-6.1 Sol с исходной конфигурацией на Model B, а не одну и ту же модель до и после; на самой GPT-6.1 Sol выигрыш по стоимости составил 4x ($1,97 → $0,47), на Model B после оптимизации, 29x (с минимум $36,21 до $1,24).
- Причина дороговизны: агент не кэшировал растущую историю страниц и скриншотов и менял её почти на каждом шаге. Лучшая политика накапливала до 20 скриншотов перед сокращением и сочеталась с бюджетом истории 480 000 символов.
- Увеличение бюджета истории на GPT-6.1 Sol подняло число запусков с ответом с трёх из 18 до всех 18, и все ответы были верными.
- По оценке Hidalgo, работа на один-два месяца заняла около недели; изменения уже выпущены в StackAI.
Почему это важно
Кейс показывает, что цена и скорость браузерных агентов во многом определяются не выбором модели, а тем, как собирается запрос. Здесь основная утечка денег была в том, что растущая история страниц и скриншотов отправлялась повторно по полной цене и ломала кэш из-за постоянных правок. По словам из материала, стоимость раньше ограничивала, какие модели можно предлагать клиентам для таких задач, а теперь Asana может давать клиентам более качественную и быструю модель, снижая собственные расходы. Вторая линия сюжета: инженер задал направление, а модель в Codex провела эксперименты, и результаты дошли до продакшена через платформу поставки ПО Command.
Кому это важно
Командам, которые строят агентов, работающих в браузере или с длинным контекстом из страниц и скриншотов, и платят за каждый вызов модели. Также тем, кто использует модели вроде Codex для исследовательской инженерной работы: по описанию Asana, модель картировала код, предлагала гипотезы, перерабатывала код под параллельные эксперименты и проводила полное исследование. Клиентам StackAI релевантно, что изменения в навигации браузерного агента уже выпущены.
Как это применить
Из описанного в кейсе следуют несколько практических шагов. Выяснить, какая часть запроса действительно кэшируется, и не отправлять растущую историю по полной цене. Не менять историю на каждом шаге: удалять скриншоты пачками (в лучшей политике они накапливались до 20, после чего оставался последний), чтобы начало запроса дольше оставалось неизменным. Проверить, хватает ли агенту бюджета истории: в тесте при 120 000 символов ответ выдали три запуска из 18, при 480 000, все 18. Для сравнения конфигураций Asana сделала код пригодным для параллельных контролируемых экспериментов и записывала запросы, трассы данных и результаты в Command. Цены за токены в материале не приводятся, так что экономию стоит пересчитывать под свои тарифы. Asana планирует со временем встроить такое тестирование в оценочные проверки платформы; сроков в материале нет.
Можно ли доверять
Материал опубликован на сайте OpenAI как рассказ о клиенте, и все цифры, это данные самой Asana о собственном исследовании; независимой проверки в тексте нет. Стоимость везде названа оценочной, а не по реальным счетам. Заголовочные 76x и 5x сравнивают разные конфигурации и разные модели: оптимизированный процесс на GPT-6.1 Sol против исходного на Model B, причём исходные стоимость ($36,21) и время (22,5 минуты) заданы как нижние границы, потому что часть запусков упёрлась в лимит шагов. Что за модели A, B и C, не раскрыто. Реплики в тексте не подписаны конкретными людьми. Полное исследование, по материалу, лежит в блогах Asana и StackAI.
Риски и подводные камни
Не стоит читать 76x как экономию на одной модели: на самой GPT-6.1 Sol улучшение составило 4x, а основная часть общей цифры возникает из-за сравнения с исходной конфигурацией на другой модели. Тест состоял из одной задачи, сбора шести полей по 32 книгам из публичного демонстрационного каталога; сведений об экономии в масштабе всех клиентов в материале нет. Оценка Hidalgo про один-два месяца вручную против недели, его собственная прикидка. Хотя в тесте каждый запуск оптимизированного процесса вернул верный ответ, на небольшом бюджете истории большинство запусков (15 из 18) до ответа вообще не дошло, так что настройки бюджета критичны. В одной из неподписанных реплик материала говорится, что узким местом теперь становится человеческое внимание: результаты агентов всё равно нужно проверять.
«Раньше стоимость ограничивала, какие модели мы могли предлагать клиентам для таких задач. Сделав агента эффективнее, мы можем дать клиентам более качественную и быструю модель и при этом снизить собственные операционные расходы.»
— из кейса Asana на сайте OpenAI; говорящий в тексте не назван