Asana знижує витрати у 76 разів у тестах із GPT‑6.1 Sol
З GPT‑6 Astra в Codex Asana знизила витрати на браузерного агента у 76 разів і прискорила його вп’ятеро в тестах, щоб пропонувати клієнтам потужніші моделі.
76×
Нижчі розрахункові витрати на модель завдяки оптимізованому процесу на GPT-6.1 Sol
5×
Швидше виконання в браузері завдяки оптимізованому процесу на GPT-6.1 Sol
0,47 дол. США
Середні розрахункові витрати на модель в оптимізованому процесі на GPT-6.1 Sol
Завдяки експериментам із GPT‑6 Astra в Codex компанія Asana оптимізувала робочий процес свого браузерного агента на GPT‑6.1 Sol: він став у 76 разів дешевшим і вп’ятеро швидшим.
Asana допомагає клієнтам автоматизувати роботу в бізнес-застосунках через StackAI(відкривається у новому вікні) — платформу, яку компанія придбала(відкривається у новому вікні). У StackAI клієнти можуть без написання коду створювати робочі процеси, які переходять між вебсайтами, заповнюють форми та збирають інформацію. За масштабів Asana навіть дрібні недоліки в ефективності цих процесів накопичуються.
Френк Ідальго, PhD, технічний директор StackAI в Asana, вирішив прискорити роботу браузерного агента й знизити витрати на неї. Він доручив GPT‑6 Astra в Codex дослідити агента, протестувати вдосконалення та порівняти результати. Робота, яка, за його оцінкою, вручну зайняла б один-два місяці, тривала близько тижня.
У дослідженні Asana зі 144 запусками(відкривається у новому вікні) протестували GPT‑6.1 Sol і три інші передові моделі, названі тут моделями A, B і C. Отриманий оптимізований процес на GPT‑6.1 Sol у середньому потребував 0,47 дол. США розрахункових витрат на модель і близько чотирьох хвилин на запуск — у 76 разів дешевше й уп’ятеро швидше за початкову робочу конфігурацію на моделі B.
«Ось як на практиці працюють команди людей і агентів. Інженер задав напрям, GPT-6 Astra провела експерименти, а результати через Command потрапили в робоче середовище. Це показує, як Asana втілює в життя співпрацю людей і агентів у командах».
Щоб швидко просунутися вперед, Ідальго спершу доручив GPT‑6 Astra в Codex дослідити структуру кодової бази й пояснити, як агент формує кожен запит до моделі. GPT‑6 Astra виявила, що агент кешує незмінні інструкції та визначення інструментів, але не накопичувану історію текстів сторінок і знімків екрана. Тому кожен запит повторно надсилав цю історію за повною ціною.
Агент також майже на кожному кроці видаляв старі знімки екрана й обрізав текст. Кожне таке редагування змінювало історію, тож самого лише її кешування було б недостатньо. А через втрату фактів агент міг повторно відвідувати вже прочитані сторінки.
Ідальго розглянув запропоновані GPT‑6 Astra виправлення й вибрав три для тестування:
Поширити кешування на історію перегляду агента
Збільшити обсяг тексту, який він може зберігати
Видаляти знімки екрана пакетами, а не на кожному кроці
GPT‑6 Astra почала зі швидких тестів, щоб визначити, які змінні мають значення. Оскільки код не був призначений для контрольованих експериментів, модель виконала рефакторинг: тепер один фронтенд і бекенд могли підтримувати багато паралельних процесів, кожен зі своїми налаштуваннями.
Astra провела повне дослідження: ліміти історії у 120 000 і 480 000 символів та шість політик кешування й обробки знімків екрана. Кожну комбінацію протестували тричі на кожній із чотирьох моделей (див. таблицю нижче). Найкращий результат дала політика, за якої знімки екрана накопичувалися до 20, а потім залишався лише найновіший. Завдяки цьому попередня історія довше залишалася незмінною між видаленнями. Разом зі збільшеним лімітом історії це стало основою оптимізованого робочого процесу. Кожна конфігурація виконувала те саме завдання: збирала шість полів для кожної з 32 книг у загальнодоступному демонстраційному каталозі. Це типовий приклад завдань, які деякі клієнти Asana виконують у StackAI.
Модель | Опис | Ціна |
|---|---|---|
Модель A | Менша й дешевша модель іншої лабораторії передових моделей, випущена восени 2025 року | Удвічі дешевша за GPT‑6.1 Sol |
Модель B | Модель, яку спочатку використовували в робочому середовищі; створена тією ж лабораторією, що й модель A, і випущена влітку 2026 року | Та сама ціна, що й у GPT‑6.1 Sol |
Модель C | Оновлена версія моделі B, випущена восени 2026 року | Та сама ціна, що й у GPT‑6.1 Sol |
GPT‑6.1 Sol | Модель OpenAI |
GPT‑6 Astra запускала процеси й аналізувала запити, записи про використання та вихідні дані, а в окремих сеансах моделі перевірялася виконана робота. Запити, трасування даних і результати кожного сеансу записувалися в Command(відкривається у новому вікні) — платформі Asana для випуску програмного забезпечення. Так команда могла згодом переглянути все дослідження. На основі висновків у Command створили завдання, потім — запити на злиття коду, а зміни впровадили в робоче середовище.
«Вручну це зайняло б у мене один-два місяці. З GPT-6 Astra в Codex знадобилося близько тижня: перед сном я задавав ціль через /goal, а вранці переглядав результати».
Для моделі B оптимізація знизила розрахункові витрати на модель зі щонайменше 36,21 дол. США (деякі початкові запуски досягали ліміту кроків до завершення) до 1,24 дол. США за запуск — у 29 разів. Оптимізований процес на GPT‑6.1 Sol був ще у 2,6 раза дешевшим — 0,47 дол. США. Кожен запуск оптимізованого процесу завершував завдання й повертав правильну відповідь.
Середні значення за 3 запусками. ≥: базова конфігурація містить запуски, зупинені лімітом, тому її середнє значення — це нижня межа.
Два коефіцієнти праворуч показують порівняння з оптимізованою конфігурацією моделі B. Модель B тестували на етапі 1, а модель C і Sol 6.1 — на етапі 2 того самого дослідження (пунктирна лінія).
На самій GPT‑6.1 Sol зі збільшеним лімітом історії нова політика кешування й обробки знімків екрана знизила витрати вчетверо: з 1,97 до 0,47 дол. США за запуск. Кожен виклик став приблизно втричі дешевшим, адже 89% вхідних даних надходили з кешу за 5% ціни некешованих даних. Запуски також прискорилися: зі щонайменше 22,5 хвилини в початковій конфігурації на моделі B до приблизно чотирьох хвилин в оптимізованому процесі на GPT‑6.1 Sol.
Середнє за 3 запусками; вуса показують стандартне відхилення. ≥: середнє враховує запуск, зупинений лімітом або незавершений, тому фактичне значення не менше за вказане.
Стовпчики оформлено в синіх тонах. Оцінюйте вплив кешування порівняно зі стовпчиком більшого ліміту — 480 тис.
Маркери запусків і вуса стандартного відхилення приблизно відтворено з вихідного зображення; початкові показники запусків і стандартні відхилення були недоступні.
Середнє за 3 запусками; вуса показують стандартне відхилення. ≥: середнє враховує запуск, зупинений лімітом або незавершений, тому фактичне значення не менше за вказане.
Стовпчики оформлено в синіх тонах. Оцінюйте вплив кешування порівняно зі стовпчиком більшого ліміту — 480 тис.
Маркери запусків і вуса стандартного відхилення приблизно відтворено з вихідного зображення; початкові показники запусків і стандартні відхилення були недоступні.
Дослідження також показало, як керування історією впливає на те, чи агент узагалі надасть відповідь. Збільшення обсягу історії перегляду, яку могла зберігати GPT‑6.1 Sol, підвищило кількість запусків із відповіддю з трьох із 18 за меншого ліміту до всіх 18 за більшого. Усі ці відповіді були правильними. Для Ідальго цінність для бізнесу полягає в тому, щоб надавати клієнтам доступ до швидших і потужніших моделей, зберігаючи операційні витрати на прийнятному рівні.
«Раніше вартість обмежувала вибір моделей, які ми могли пропонувати клієнтам для цих завдань. Підвищивши ефективність агента, ми можемо надати клієнтам кращу й швидшу модель і водночас знизити операційні витрати».
Asana вже впровадила зміни в браузерну навігацію StackAI й розробляє інструменти, які спростять повторення подібних експериментів. Згодом команда планує включити це тестування до системи оцінювання платформи, щоб клієнти й внутрішні команди могли порівнювати витрати, час виконання та якість відповідей під час налаштування агентів.
«Тепер вузьке місце — не швидкість випуску, а людська увага. Ми наближаємося до світу, де кожен інженер — це менеджер продукту, який керує цілою групою агентів».
Тепер Asana використовує GPT‑6 Astra в Codex для перевірки функцій продукту перед випуском: Astra переходить між розділами платформи, випробовує різні вхідні дані та повідомляє про помилки фахівцям із забезпечення якості. Ідальго вбачає в цьому основу нового життєвого циклу розробки ПЗ, у якому багато хмарних сеансів агентів паралельно тестують функції.
Повне дослідження доступне в блогах Asana(відкривається у новому вікні) і StackAI(відкривається у новому вікні).
