Результат браузерного агента GPT-6.1 Sol с показателем 76x: что на самом деле измерила Asana

Asana опубликовала исследование затрат браузерного агента 8 октября 2026 года, а разработчик GPT-6.1 Sol на следующий день опубликовал материал под заголовком «Asana сокращает затраты на модель в 76 раз в браузерных тестах с GPT-6.1 Sol». Показатель 76x реален в том смысле, что кто-то его измерил, но это не факт о цене GPT-6.1 Sol. Это факт о том, что происходит, когда вы исправляете сломанный кэш промптов у браузерного агента, а затем заменяете модель, стоящую за ним. Та же оптимизация, применённая к модели, которая уже была у Asana в продакшене — модель, которую она называет Model B, — сама по себе сократила затраты в 29 раз. GPT-6.1 Sol обеспечила оставшиеся 2,6x. Эксперименты проводила GPT-6 Astra, работавшая в Codex, а модель, лежащая в основе базового варианта, — это модель конкурента, которую Asana называет Model B, так что в этой истории фигурируют два тира от одного и того же вендора и один неназванный конкурент. Далее мы отделяем ту часть результата, которую можно повторить уже в понедельник, от той, что относится к конкретному стеку Asana.

Сравнение, сформулированное точно

Стек Asana для этого — StackAI, приобретённая ею платформа автоматизации рабочих процессов, которая запускает браузерного агента, перемещающегося по веб-сайтам, заполняющего формы и собирающего информацию без кода. Тестовое задание было узким и конкретным: собрать шесть полей для каждой из 32 книг из публичного демонстрационного каталога. Это репрезентативно для того, что запускают некоторые клиенты, и при этом задача достаточно мала, чтобы исследование с 144 запусками уложилось в неделю.

Схема включала шесть политик кэширования и создания скриншотов при двух бюджетах истории, по три прогона на каждое условие, для четырёх моделей — 144 прогона плюс дополнительный набор из 12 прогонов. Затраты рассчитывались по собственным счётчикам токенов каждого провайдера, а каждый ответ оценивался по независимо подготовленному эталону. Четырьмя моделями были три неназванные фронтирные модели (модели A, B и C) и GPT-6.1 Sol. Модель A — меньшая и более дешёвая модель из другой лаборатории, выпущенная осенью 2025 года и стоящая вдвое дешевле GPT-6.1 Sol. Модель B — это модель, которая была в эксплуатации, из той же лаборатории, что и A, выпущенная летом 2026 года и стоящая столько же, сколько GPT-6.1 Sol. Модель C — более новая версия модели B, выпущенная осенью 2026 года и также стоящая столько же, сколько GPT-6.1 Sol. Все три остаются неназванными в обоих текстах, поэтому читатель не может воспроизвести это сравнение — стоит это знать, прежде чем воспринимать 29x как число о чужой модели. Это опубликованные цифры Asana и OpenAI, а не независимо проверенные.

Лестница результатов, все собственные цифры As:

• Базовое выполнение в продакшене на Model B — не менее $36,21 за запуск, не менее 22,5 минут за запуск. Некоторые базовые запуски упирались в лимит шагов, не успев завершиться, поэтому среднее значение — это нижняя граница, а не истинное среднее.

• Модель B, оптимизированный агент — $1.24 за запуск, в 4 раза быстрее базового показателя, снижение затрат в 29 раз.

• GPT-6.1 Sol, тот же оптимизированный агент — $0,47 за запуск, около четырёх минут, сокращение затрат в 76 раз и в 5 раз быстрее.

• GPT-6.1 Sol, до и после исправления — с $1.97 до $0.47 за запуск, сокращение в 4 раза только за счёт изменений в кэше и прунинге.

Поскольку базовый уровень — это нижняя граница, 76x сам по себе является минимальным значением. Честное прочтение — «как минимум 76x», а не «76x».

Что на самом деле изменилось и почему это не функция модели

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

Продакшн-агент Asana имел два недостатка, которые усиливали друг друга. Он кэшировал свои фиксированные инструкции и определения инструментов, но не историю браузинга. И он редактировал эту историю почти на каждом шаге: каждый раз отбрасывал предыдущий скриншот и обрезал более старый текст, чтобы уложиться в бюджет истории. Каждое редактирование делало префикс недействительным, поэтому кэширование было бы почти бесполезным, даже если бы его включили. В отчёте Asana отмечается, что на протестированных моделях чтение из кэша стоит от 0,05x до 0,1x стандартной цены входных данных — так что выигрыш был большим, а агент систематически от него отказывался.

Исправление состоит из двух частей. Во-первых, кэшируйте также историю, с маркером кэша на последнем результате инструмента. Во-вторых, прекратите редактировать её при каждом вызове: сохраняйте скриншоты и удаляйте их пакетами в соотношении 20 к 1, так что агент хранит до 20, а затем сокращает до самого последнего. Тогда примерно 19 последовательных вызовов будут переиспользовать неизменённый префикс. Увеличьте бюджет истории с 120 000 до 480 000 символов, чтобы старый текст перестал обрезаться, и арифметика сходится: на GPT-6.1 Sol каждый вызов стоил примерно в 3 раза меньше, потому что 89% входных данных поступало из кэша.

Самый важный здесь вывод — отрицательный. Кэширование истории без пакетной обрезки при большем бюджете стоило дороже, чем полный отказ от кэширования, на трёх из четырёх моделей — кэш постоянно перезаписывался и редко читался. Инфраструктура кэширования, включённая без дисциплины истории, допускающей только добавление, — это способ платить надбавку за запись ни за что. Этот режим отказа не зависит от модели, и именно поэтому то же самое исправление ускорило Model B в 29 раз.

Где выбор модели действительно окупился

Отбросьте поправку на рабочий процесс и сравнивайте сопоставимое: на одном и том же оптимизированном агенте GPT-6.1 Sol обошёлся в 2,6 раза дешевле, чем Model B, при той же заявленной цене. Дополнительный фактор — поведение при попадании в кэш, а не тарифная сетка. Sol читал 89% своего ввода из кэша; Asana не публикует аналогичную долю для Model B, поэтому 2,6-кратная разница — это измеренный результат без опубликованной декомпозиции. Рассматривайте это как «эта модель на этой рабочей нагрузке лучше использовала свой кэш», а не как общее 2,6-кратное преимущество над моделью, которую мы не можем назвать.

Со стороны времени выполнения всё однозначно: в 5 раз быстрее базового уровня, при этом оптимизированный рабочий процесс Sol занимает примерно четыре минуты против как минимум 22,5 минут у базового варианта. Скорость важна для затрат в агентах, которые тарифицируются по токенам, поскольку медленная модель, зацикливаясь, платит за свои циклы.

Для тех, кто просчитывает стоимость: стандартные тарифы API GPT-6.1 Sol составляют $2,00 за миллион входных токенов, $0,10 за миллион кэшированных входных токенов и $10,00 за миллион выходных токенов, а скидка за чтение из кэша составляет 0,05x от тарифа на входные токены — самая глубокая в текущем прайс-листе OpenAI. GPT-6 Astra, модель, которая выполняла инженерную работу в Codex, стоит $10,00 за вход и $50,00 за выход — именно на эту пятикратную разницу опиралась подача запуска OpenAI. Причина, по которой исследование дало прогоны по $0,47, а не по $2, не в тарифной сетке; она в том, что 89% очень повторяющегося запроса тарифицировались по цене в одну двадцатую от тарифа на входные токены. В агенте с интенсивным кэшированием строка со скидкой делает больше, чем заявленная цена, а в нашем собственном каталоге прейскурантные цены поставщиков проходят с 0%-ной наценкой, поэтому если поставщик меняет тарификацию кэшированного ввода, это в тот же день отражается в вашем счёте.

Другое число в исследовании: бюджет истории определял, ответит ли агент вообще.

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

• При бюджете в 120 000 символов Model C не дала ответа ни в одном из своих 18 запусков, а GPT-6.1 Sol дал ответ в 3 из 18 — большинство запусков достигли лимита шагов, так и не сформировав ответ.

• При 480 000 символах каждый прогон на обеих моделях дал ответ, причём каждый — правильный.

• Более новые модели быстрее израсходовали меньший бюджет: модель C впервые сократила свою историю на вызове 10, модель A — на вызове 64.

• В оптимизированном рабочем процессе каждый запуск выполнял задачу и возвращал правильный ответ, и каждый запуск в наилучших условиях на каждой модели обнаруживал все 192 факта, которые он должен был собрать.

Это аргумент иного рода, нежели «дешевле». Слишком маленький бюджет истории на способной модели порождает агента, который терпит неудачу из-за нехватки места, и терпит её, упираясь в лимит шагов, — а это самый дорогой способ провалиться: вы платите за весь прогон и не получаете ничего. Повышение бюджета увеличивало стоимость за вызов и снижало стоимость за ответ, а это единственный показатель, за которым стоит следить владельцу продакшена. Если вы оцениваете непроверенную модель для такого агента, то малорискованный паттерн — оставить ваш продакшен-маршрут на модели, которой вы доверяете, а новую поставить за фейловером или разделённым маршрутом, чтобы отказ по лимиту шагов проявлялся как факт маршрутизации, а не как инцидент. Каждая модель в этом сравнении доступна через один API для 200+ моделей с ценами провайдеров по прайс-листу, переданными без изменений, что также делает скидку за чтение кэша сопоставимой между вендорами в одном и том же счёте, а не на пяти разных дашбордах.

Что из этого взять, по порядку

Если вы запускаете браузерный агент или агент для работы с компьютером, в исследовании Asana есть три рычага, которые стоит задействовать, прежде чем смотреть на прайс-лист:

• Сделайте префикс запроса доступным только для добавления. Любое изменение середины истории, вносимое в рамках отдельного вызова, обнуляет повторное использование кэша начиная с этой точки.

• Сокращайте пакетами. Дополнительное исследование Asana показало, что сохранение каждого скриншота стоило в 1,2 раза меньше на вызов, чем лучшее условие сокращения на Model B и GPT-6.1 Sol, и примерно на 5% меньше на Model C. Сокращение по-прежнему важно для долгих задач, небольших контекстных окон и дорогостоящего чтения из кэша — но аргумент в пользу соотношения пакетов 20:1 связан со стабильностью кэша, а не с самими скриншотами.

• Задавайте бюджет истории для каждой модели отдельно и сверяйте его с лимитом шагов. Бюджет, который подходит одной модели, может обделить следующую.

Два защитных механизма из исследования легко пропустить, и этого делать не следует. Ни один запуск не достиг бюджета в 480 000 символов, поэтому бюджет никогда не ограничивал эти запуски — но дрейфующий агент растёт, приближаясь к своему лимиту контекста, и если кэш сломается, каждый вызов платит полную цену. Именно ограничения на шаги, токены и стоимость за запуск сдерживают плохой запуск. Отдельно: в исследовании использовалось три или четыре запуска на условие с переменным числом вызовов; сама Asana говорит, что этого достаточно для выявления общих закономерностей, но недостаточно, чтобы разделить условия, различающиеся на несколько процентов. Не усматривайте в этом разницу в 5% и не перестраивайте под неё свой пайплайн.

Та часть, которая действительно новая, и та часть, которая — нет.

Оговорки по поводу этой постановки стоит изложить прямо: четыре модели, три из которых не названы, одна узкая задача на 32 книги, собственные инструментированные счётчики Asana и собственный отчёт вендора, в котором опубликован результат. Ничто из этого не было воспроизведено за пределами Asana. Но механизм полностью описан — история только с добавлением, маркер кэша на последнем результате инструмента, пакетная обрезка, больший бюджет, измерение чтений кэша с помощью счётчиков провайдера — и это как раз тот результат, который не теряет силы, даже если его припишут не той лаборатории. 76x — это число Asana на нагрузке Asana. Причина, по которой это стоит прочитать, в том, что это демонстрирует правило, которое можно проверить за один день: агент, который редактирует свою собственную историю на каждом шаге, платит полную цену за разговор, который уже состоялся.