Asana: agent przeglądarkowy 76x tańszy w testach z GPT-6.1 Sol

9 października 2026 OpenAI opublikowało studium przypadku Asany. Firma przebudowała przepływ pracy agenta przeglądarkowego w platformie StackAI i w swoich testach zeszła z kosztu co najmniej 36,21 USD do 0,47 USD na przebieg. Nagłówkowe 76x taniej i 5x szybciej to deklaracja z bloga OpenAI. Wynik pochodzi z jednego typu zadania i z szacunkowych kosztów, więc czytaj go jako dobrze opisany eksperyment, a nie gwarancję dla każdej firmy.

Czym jest agent przeglądarkowy w StackAI i co dokładnie zmierzono?

Asana kupiła StackAI, platformę, w której klienci bez pisania kodu budują przepływy pracy. Agent wchodzi na strony, wypełnia formularze i zbiera informacje. Przy skali Asany drobne nieefektywności szybko się sumują. Dlatego CTO StackAI, Frank Hidalgo, postanowił agenta przyspieszyć i potanieć.

Liczby z testów wyglądają tak:

• Zoptymalizowany przepływ na GPT-6.1 Sol: średnio 0,47 USD szacunkowego kosztu modelu i ok. 4 minuty na przebieg.
• Punkt odniesienia: pierwotne ustawienie produkcyjne na Modelu B, czyli modelu od innego laboratorium (źródło go nie nazywa), w tej samej cenie co GPT-6.1 Sol.
• Baseline to dolna granica: część oryginalnych przebiegów zatrzymał limit kroków, więc koszt wynosił co najmniej 36,21 USD, a czas co najmniej 22,5 minuty.

Dlatego „76x” i „5x” to w rzeczywistości „co najmniej tyle”. Baseline był po prostu bardzo zły, a agent klikający w kółko szybko nabija rachunek za tokeny.

Skąd wzięło się 76x i co naprawiono w agencie?

Liczba 76x nie pochodzi z jednej sztuczki. To iloczyn dwóch kroków. Na samym Modelu B optymalizacja obniżyła szacunkowy koszt do 1,24 USD na przebieg, czyli 29x. Przejście na GPT-6.1 Sol dało kolejne 2,6x, do 0,47 USD.

Historia przeglądania płacona w pełnej cenie

GPT-6 Astra w Codex przejrzał kod agenta i wyjaśnił, jak ten buduje każde zapytanie do modelu. Agent miał w pamięci podręcznej (cache) tylko stałe instrukcje i definicje narzędzi. Rosnąca historia tekstu stron i zrzutów ekranu nie trafiała do cache. Przy każdym zapytaniu leciała więc od nowa i kosztowała pełną stawkę.

Cache to mechanizm, w którym powtarzający się fragment zapytania model dostaje taniej. W teście Asany 89% wejścia na GPT-6.1 Sol pochodziło z cache, rozliczanego po 5% ceny wejścia bez cache. Pojedyncze wywołanie wyszło około 3x taniej.

Był jeszcze drugi problem. Agent przy niemal każdym kroku wyrzucał stare zrzuty ekranu i przycinał tekst. Każda taka zmiana modyfikowała historię, więc samo dodanie historii do cache niewiele by dało.

Trzy poprawki, które Hidalgo wybrał do testów

• rozszerzenie cache na historię przeglądania agenta,
• zwiększenie ilości tekstu, jaką agent może zachować,
• usuwanie zrzutów ekranu partiami, a nie przy każdym kroku.

Najlepsza polityka pozwalała zgromadzić do 20 zrzutów ekranu, po czym zostawiała tylko najnowszy. Dzięki temu wcześniejsza historia dłużej pozostawała niezmieniona, a cache działał. Razem z większym limitem historii (480 000 znaków zamiast 120 000) powstał zoptymalizowany przepływ.

Sam limit historii zmienił też wyniki. GPT-6.1 Sol z mniejszym limitem dał odpowiedź w 3 z 18 przebiegów, a z większym we wszystkich 18, każdy z poprawną odpowiedzią. Na samym GPT-6.1 Sol, przy większym limicie, nowa polityka obniżyła koszt 4x, z 1,97 do 0,47 USD na przebieg.

Ile wart jest ten test i gdzie ma ograniczenia?

Wynik jest konkretny, ale wąski. Zanim przeniesiesz go na własne wdrożenia, sprawdź, co dokładnie mierzono:

• Jedno zadanie. Każda konfiguracja zbierała sześć pól dla 32 książek z publicznego katalogu demo. Według źródła to typ pracy, który wykonują niektórzy klienci Asany w StackAI.
• 144 przebiegi. Test objął GPT-6.1 Sol i trzy inne modele graniczne (A, B, C), każdą konfigurację trzykrotnie na każdym modelu. Średnie na wykresach pochodzą więc z 3 przebiegów.
• Koszty szacunkowe. Źródło mówi o „estimated model costs”, nie o rachunku z faktury.
• Wykresy są częściowo zrekonstruowane. Znaczniki przebiegów i odchylenia standardowe to przybliżenia z obrazu źródłowego, bo dokładne wartości nie były dostępne.
• Źródło ma interes. To blog OpenAI, a głównym bohaterem jest jego model i jego narzędzie.

Jest też niuans, który łatwo przeoczyć. GPT-6.1 Sol nie był najszybszy: zoptymalizowany Model C zszedł do 3,5 minuty i 0,66 USD, Sol do 4,0 minuty i 0,47 USD. Przy cenie Sol wygrywa. Pod względem czasu to remis z drobną przewagą konkurenta. Cena API GPT-6.1 Sol to 2 USD za 1 mln tokenów wejścia i 10 USD za 1 mln wyjścia (stan na 23.09.2026), a Model B kosztuje według źródła tyle samo.

Jak GPT-6 Astra w Codex skrócił miesiące pracy do tygodnia?

Hidalgo szacuje, że ręcznie zajęłoby to 1-2 miesiące, a z GPT-6 Astra w Codex zajęło około tygodnia. To jego szacunek, nie pomiar. Opisuje to tak: „ustawiałem /goal przed snem i przeglądałem wyniki rano”.

Astra najpierw zrobił szybkie testy, żeby ustalić, które zmienne mają znaczenie. Kod nie był zaprojektowany pod kontrolowane eksperymenty, więc Astra przepisał go tak, żeby jeden frontend i backend obsługiwały wiele przepływów równolegle, każdy z własnymi ustawieniami. Potem przeprowadził całe badanie. Osobne sesje modeli przeglądały jego pracę, a każde zapytanie, ślad danych i wynik trafiły do Command, platformy Asany do dostarczania oprogramowania. Stamtąd wnioski zamieniono w tickety, potem w pull requesty i wdrożono na produkcję.

Podział ról był wyraźny. Człowiek wybrał trzy poprawki do przetestowania i ocenił propozycje Astry, a agent wykonał żmudną część. Astra kosztuje w API 10 USD za 1 mln tokenów wejścia i 50 USD wyjścia (stan na 23.09.2026), czyli pięć razy więcej niż Sol. Podobne wzorce pracy z agentami opisywaliśmy przy okazji agentów robiących research z GPT-6 Astra oraz pracy jednego inżyniera z AI przy nowych funkcjach wideo.

Co z tego wynika dla użytkowników i kiedy zobaczysz to w produktach?

Asana wdrożyła zmiany w nawigacji przeglądarkowej w StackAI i pracuje nad narzędziami, które ułatwią powtarzanie takich eksperymentów. Z czasem zespół planuje włączyć takie testy do ewaluacji platformy, żeby klienci i zespoły wewnętrzne mogły porównywać koszt, czas działania i jakość odpowiedzi przy konfigurowaniu agentów. To plan, nie funkcja, którą już dziś klikniesz. Ceny i dostępność StackAI w Polsce sprawdź na stronie producenta.

Asana używa też GPT-6 Astra w Codex do testowania funkcji produktu przed wydaniem. Astra nawiguje po platformie, próbuje różnych danych wejściowych i zgłasza błędy recenzentom QA. Hidalgo uważa to za fundament nowego cyklu tworzenia oprogramowania, w którym wiele sesji agentów w chmurze testuje funkcje równolegle.

Sens biznesowy Hidalgo ujmuje wprost: koszt ograniczał wcześniej wybór modeli oferowanych klientom, a teraz może dać im lepszy, szybszy model przy niższych kosztach operacyjnych. To główna lekcja dla firm, które liczą rachunki za API: zanim zmienisz model na tańszy, sprawdź, jak Twój agent buduje zapytania. W tym teście największy zysk dała organizacja historii i cache, a nie sama zmiana modelu. Do podobnych wniosków prowadzą inne case studies, jak agenci AI z pamięcią instytucjonalną czy Astra for Law w kancelariach.

Werdykt: 76x to wynik z jednego, dobrze opisanego testu, z baseline'em, który sam był wyjątkowo kosztowny. Zapamiętaj mechanizm (stała część zapytania w cache, usuwanie zrzutów partiami, większy limit historii), a nie sam mnożnik. Czy to samo zadziała na Twoich zadaniach, pokaże dopiero własny test.