Asana урезала стоимость ИИ-агента в 76 раз, не поменяв ни одной цены в прайсе

8 октября 2026 года Asana опубликовала исследование, в котором её браузерный ИИ-агент подешевел в 76 раз и ускорился впятеро без смены прайса модели: GPT-6.1 Sol стоила столько же за токен, сколько и раньше, а 89 процентов входа читалось из кеша по цене 0,05–0,1 от обычной. Дело не в дешёвых токенах и не в новой модели — Asana перестала редактировать историю диалога на каждом шаге, чтобы кеш не ломался. OpenAI подал это как «Asana cuts model costs 76x», но в самом исследовании Asana цифра скромнее и честнее: 144 прогона на четырёх моделях, три прогона на условие, и автор сам предупреждает, что study показывает широкие паттерны, а не различия в несколько процентов. Практический вывод для компании: экономика ИИ-агента живёт в цикле вызовов, а не в прайсе модели, и разбираться с ней — работа инженерная, а не закупочная.

Что произошло: OpenAI пишет «в 76 раз дешевле», Asana пишет аккуратнее

Ремарка про имена, чтобы не путаться: заголовок OpenAI обещает «GPT-6.1 Sol», а подзаголовок — «GPT-6 Astra in Codex». Это разные вещи, и разнобой реален: Ken Ashe, CPA и разработчик ИИ-приложений, разбирая анонс, отметил, что OpenAI не публикует ни набор задач, ни размер выборки, ни метод учёта затрат — и советует не сглаживать это, а дождаться первоисточника. Первоисточник есть, и он сказал больше, чем анонс: агент — это не «один запрос — один ответ», а цепочка из десятков вызовов, где каждая лишняя петля умножает счёт.

В записи Asana фигурируют два имени: Frank Hidalgo, CTO StackAI by Asana (StackAI — приобретённая Asana платформа для agent workflow automation, на её агенте и гоняли исследование), и Arnab Bose, CPO Asana. Само исследование: шесть политик кеширования и обрезки истории в двух бюджетах, четыре модели (GPT-6.1 Sol плюс анонимные Model A, B, C), три прогона на условие — 144 прогона, плюс 12-прогонный follow-up, в котором вообще не обрезали скриншоты. Стоимости считали по счётчикам токенов самих провайдеров, ответы сверяли с независимо подготовленным эталоном. На Model B лучший вариант срезал стоимость прогона в 29 раз, на GPT-6.1 Sol — в 76, при 89 процентах входа из кеша. И да — «в 76 раз» это нижняя граница: базовые прогоны упирались в лимиты, реальная цифра может быть выше. Может быть и ниже — при трёх прогонах на условие дисперсия не оценена. Обе оговорки честнее заголовка.

Почему кеш ломался: физика цепочки вызовов

Тактильно механика такая. Браузерный агент на каждый вызов модели отправляет весь накопившийся контекст: инструменты, системный промпт, историю страниц со скриншотами. Prompt caching удешевляет повторный вход — чтение кеша на протестированных моделях стоит 0,05–0,1 от стандартной цены входа. Но кеш переиспользует только самый длинный неизменившийся префикс запроса. Агент Asana кешировал инструменты и системный промпт, но не историю. А историю агент правил на каждом шаге: удалял предыдущий скриншот и подрезал старый текст под бюджет в 120 000 символов. Каждая правка меняла раннюю часть запроса — и переиспользование ломалось почти на каждом вызове.

Фикс — две операции. Первая: кешировать и историю, поставив cache-маркер на последнем результате инструмента. Вторая: перестать редактировать её на каждом вызове. Batch pruning: скриншоты удаляются не по одному, а пакетами — агент держит до 20 и разом срезает до 1, так что примерно 19 последовательных вызовов едят один и тот же кеш. Плюс бюджет истории расширили со 120 000 до 480 000 символов, чтобы старый текст не подрезался.

Q&A: «Не проще ли подождать, когда модели подешевеют?»

Вопрос, который я слышу от каждой второй компании: токены дешевеют каждый год, зачем городить инженерию, если через год модель будет стоить копейки. На него отвечает сам Arnab Bose, CPO Asana, в том же исследовании:

«Это то, как выглядят команды из людей и агентов на практике. Инженер задал направление, агент прогнал эксперименты, и результаты через Command ушли в продакшн. Это демонстрирует, как Asana оживляет команды из людей и агентов».

Цитата — про организацию работы, а не про цену токена, и это не случайность. В том же тексте Frank Hidalgo, CTO StackAI by Asana, описывает смену узкого места:

«Я никогда не думал делать это вручную — у меня ушёл бы месяц. С Codex это заняло около недели: я ставил задачу перед сном и разбирал результаты утром».

«Скорость релизов больше не узкое место; узкое место — человеческое внимание. Кажется, мы близки к миру, где каждый инженер — это продакт-менеджер, руководящий флотом агентов».

Переведём на язык экономики: если неделю инженерных работ обменивается на 76-кратное снижение стоимости прогона, то ждать скидок на модели — всё равно что ждать дешёвого бензина вместо починки двигателя, который льёт топливо мимо цилиндров. Причём у самой Asana это не разовая история: 12-прогонный follow-up без обрезки скриншотов показал стоимость ниже лучшего условия на Models B и GPT-6.1 Sol. То есть после первой оптимизации нашлось ещё.

Что не так с цифрой 76x, если вы собираетесь её цитировать

Здесь я останавливаюсь и вспоминаю собственную ошибку. Я сначала подумал, что это исследование уровня «перед-после», где можно брать цифру и нести её в презентацию. Потом перечитал методологию и понял, что ошибался. При трёх прогонах на условие и переменном числе вызовов между прогонами исследование различает широкие паттерны, а не разницу в несколько процентов. Никаких доверительных интервалов нет. «76x» — это среднее по трём прогонам против базовой линии, у которой были лимиты-потолки. Это сильный сигнал, но не измерение уровня RAND.

Дальше — общий с гигантскими скидками вендоров приём: 76x получено на одной задаче, в одном агенте, одной компании, на модели GPT-6.1 Sol при цене, равной Model B и Model C. Ken Ashe в своём разборе прямо предупреждает: это результат теста, а не бенчмарк продакшена по всем workflow Asana. Переносить «76x» на свой процесс без собственных замеров — то же самое, что extrapolировать экономию соседа на свой маршрут.

И последняя ложка дёгтя, без которой честного разбора нет: кеш в этой истории — не бесплатная магия. Cache read дешевле полного входа в 10–20 раз, но cache write стоит дороже. Кешировать историю без batch pruning на трёх моделях из четырёх оказалось дороже, чем не кешировать вообще: кеш постоянно перезаписывался и почти не читался. Плюс кеш умирает, если агент дрейфует к лимиту контекста — и тогда каждый вызов платит полную цену. Хорошая новость в том, что часть этой физики уже измерена: в разборе парадокса стоимости инференса и статье о том, почему дешёвые токены не превращаются в экономию, уже разбирали, почему закупочная логика на цену модели не работает. Здесь та же физика, но с другой стороны.

Как проверить своего агента за один вечер

Если у вас уже есть ИИ-агент в работе, порядок действий такой. Взять счётчики кеша у самого провайдера — Asana измеряла cache reads per call именно так. Смотреть три вещи: долю входа, которая читается из кеша (у оптимизированного агента Asana — 89 процентов), ломается ли кеш из-за правок истории на каждом шаге, и есть ли лимиты-потолки на шаги, токены и стоимость прогона — потому что дрейфующий агент без лимитов это не технический риск, а счёт.

Дальше — исторический бюджет. 120 000 символов истории хватало старым моделям, новые его выжигают быстрее: Model C подрезала историю уже на 10-м вызове. При маленьком бюджете Model C не ответила ни в одном из 18 прогонов, GPT-6.1 Sol — в 3 из 18; на 480 000 ответили все. То есть «слишком экономный» контекст-бюджет не экономит деньги, а сжигает их в пустых ретраярах.

Где здесь границы применимости — и я в них не лезу

Немного про пределы переноса. Исследование сделано на браузерном агенте, который ходит по страницам, смотрит скриншоты и жмёт кнопки. У чат-агента с короткими сессиями и без скриншотов картина будет мягче — там и ломаться-то нечему, пока история короткая. У длинных автономных процессов — жёстче: чем длиннее цепочка, тем больнее каждый её обрыв кеша и тем ценнее append-only история. Если ваш агент работает с документооборотом и базой знаний, к нему применимо всё то же самое, но с одной поправкой: его контекст — это не скриншоты, а ваши регламенты и документы, и кешировать надо их выборку, а не «всё подряд».

Я не знаю, как поведёт себя эта экономика у вас. Исследование Asana — сильный сигнал в сторону «инженерия важнее прайса», но это один агент, одна задача, три прогона на условие. Если у вас другая модель, другой провайдер, другая политика обрезки — цифры будут другими. Единственное, что я знаю точно: не измерять — дороже.

Как это связано с тем, что делаем мы

Мы делаем recall — советник с системой памяти для работы компании: он помнит документы, договоры, регламенты и договорённости, и отвечает с опорой на них, а не на общую эрудицию языка. История с Asana важна нам не как история про кеш (хотя и про него тоже: память агента — это и есть правильно организованная история). Она важна как аргумент в споре с ожиданием «купим ИИ — и оно само подешевеет». Не само. Стоимость агента сидит в его цикле: в том, как он копит контекст, как его переиспользует, что забывает, а что тащит с собой. Это ровно та работа, которую мы делаем при внедрении: разложить контекст компании на уровни памяти и сделать так, чтобы агент отвечал на вопросы за центы, а не за доллары. Если интересно, как это выглядит на ваших документах — напишите нам.

[Frank Hidalgo, CTO StackAI by Asana, автор исследования. Arnab Bose, CPO Asana. Полное исследование: asana.com/inside-asana/cut-browsers-agent-cost. Разбор Ken Ashe: kenashe.ai. Анонс OpenAI: openai.com/index/asana-browser-agent.]