Wynik 76x agenta przeglądarkowego GPT-6.1 Sol: Co faktycznie zmierzyła Asana

Asana opublikowała 8 października 2026 r. analizę kosztów agenta przeglądarkowego, a deweloper GPT-6.1 Sol opisał ją następnego dnia pod nagłówkiem „Asana obniża koszty modelu 76x w testach przeglądarkowych z GPT-6.1 Sol”. Wartość 76x jest prawdziwa w tym sensie, że ktoś ją zmierzył, ale nie jest faktem na temat ceny GPT-6.1 Sol. Jest faktem na temat tego, co się dzieje, gdy naprawisz uszkodzony cache promptów w agencie przeglądarkowym, a następnie podmienisz model, który się za nim znajduje. Ta sama optymalizacja, uruchomiona na modelu, który Asana miała już w środowisku produkcyjnym — modelu, który nazywa Model B — sama obniżyła koszt 29x. Pozostałe 2,6x zapewnił GPT-6.1 Sol. Eksperymenty przeprowadził GPT-6 Astra pracujący w Codex, a model stojący za punktem odniesienia to model konkurenta, który Asana nazywa Model B, więc w tej historii występują dwa poziomy od tego samego dostawcy i jeden nienazwany rywal. To, co następuje, oddziela tę część wyniku, którą możesz zastosować już w poniedziałek, od tej części, która należy do konkretnego stosu technologicznego Asany.

Porównanie, ujęte dokładnie

Stos Asany do tego to StackAI, platforma automatyzacji przepływu pracy, którą przejęła, uruchamiająca agenta przeglądarkowego, który nawiguje po witrynach internetowych, wypełnia formularze i zbiera informacje bez kodu. Zadanie testowe było wąskie i konkretne: zebrać sześć pól dla każdej z 32 książek z publicznego katalogu demonstracyjnego. Jest to reprezentatywne dla tego, co uruchamiają niektórzy klienci, a także wystarczająco małe, aby badanie obejmujące 144 uruchomienia zmieściło się w tygodniu.

Projekt obejmował sześć polityk buforowania i zrzutów ekranu przy dwóch budżetach historii, po trzy przebiegi na warunek, dla czterech modeli — 144 przebiegi, plus 12 przebiegów uzupełniających. Koszty obliczono na podstawie własnych liczników tokenów każdego dostawcy, a każdą odpowiedź oceniano względem niezależnie przygotowanego wzorca. Cztery modele to trzy nienazwane modele czołowe (Modele A, B i C) oraz GPT-6.1 Sol. Model A to mniejszy, tańszy model z innego laboratorium, wydany jesienią 2025 r., w cenie o połowę niższej niż GPT-6.1 Sol. Model B to model, który był w produkcji, z tego samego laboratorium co A, wydany latem 2026 r., w tej samej cenie co GPT-6.1 Sol. Model C to nowsza wersja Modelu B, wydana jesienią 2026 r., również w tej samej cenie co GPT-6.1 Sol. Te trzy modele są nienazwane w obu opracowaniach, więc czytelnik nie może odtworzyć tego porównania — warto o tym wiedzieć, zanim potraktujesz 29x jako liczbę dotyczącą czyjegoś modelu. To są publikowane dane Asany i OpenAI, a nie niezależnie zweryfikowane.

Drabina wyników — wszystkie własne liczby Asany:

• Produkcja bazowa na Model B — co najmniej 36,21 USD na uruchomienie, co najmniej 22,5 minuty na uruchomienie. Niektóre uruchomienia bazowe osiągnęły limit kroków przed zakończeniem, więc średnia jest dolną granicą, a nie prawdziwą średnią.

• Model B, zoptymalizowany agent — 1,24 USD za uruchomienie, 4x szybszy niż poziom bazowy, 29-krotne obniżenie kosztów.

• GPT-6.1 Sol, ten sam zoptymalizowany agent — 0,47 USD za uruchomienie, około czterech minut, 76-krotne obniżenie kosztów i 5-krotnie większa szybkość.

• GPT-6.1 Sol, przed i po poprawce — z $1,97 do $0,47 na przebieg, czterokrotne obniżenie wyłącznie dzięki zmianom w pamięci podręcznej i przycinaniu.

Ponieważ punkt odniesienia jest dolnym ograniczeniem, 76x samo w sobie jest minimum. Rzetelna interpretacja to „co najmniej 76x”, a nie „76x”.

Co tak naprawdę się zmieniło i dlaczego nie jest to funkcja modelu

Mechanizm to mechanika pamięci podręcznej promptów i warto go zrozumieć, ponieważ przekłada się na dowolnego agenta, którego uruchamiasz na dowolnym modelu. Agent przeglądarki wysyła ponownie swoje narzędzia, swój prompt systemowy i rosnącą historię tekstu strony oraz zrzutów ekranu przy każdym wywołaniu modelu. Buforowanie promptów udziela zniżki na powtarzającą się część, ale tylko na najdłuższy niezmieniony prefiks — w momencie, gdy cokolwiek w środku żądania się zmieni, ponowne użycie przestaje działać od tego punktu.

Produkcyjny agent Asany miał dwie usterki, które się nawzajem potęgowały. Przechowywał w pamięci podręcznej swoje stałe instrukcje i definicje narzędzi, ale nie historię przeglądania. Co więcej, modyfikował tę historię przy niemal każdym kroku: za każdym razem wyrzucał poprzedni zrzut ekranu i przycinał starszy tekst, aby zmieścić się w budżecie historii. Każda edycja unieważniała prefiks, więc buforowanie byłoby niemal bezużyteczne, nawet gdyby zostało włączone. W swoim opisie Asana zauważa, że w testowanych modelach odczyty z pamięci podręcznej kosztują od 0,05x do 0,1x standardowej ceny wejścia — więc potencjalna korzyść była duża, a agent systematycznie jej odmawiał.

Poprawka ma dwie części. Po pierwsze, zapisz też historię w pamięci podręcznej, ze znacznikiem pamięci podręcznej na najnowszym wyniku narzędzia. Po drugie, przestań ją edytować przy każdym wywołaniu: zachowuj zrzuty ekranu i przycinaj je partiami w stosunku 20 do 1, tak aby agent utrzymywał ich maksymalnie 20, a potem przycinał z powrotem do najnowszego. Około 19 kolejnych wywołań wykorzystuje wtedy niezmieniony prefiks. Podnieś budżet historii ze 120 000 do 480 000 znaków, aby stary tekst przestał być przycinany, i rachunek się zgadza: w GPT-6.1 Sol każde wywołanie kosztowało około 3 razy mniej, ponieważ 89% danych wejściowych pochodziło z pamięci podręcznej.

Najważniejsze tutaj ustalenie jest negatywne. Buforowanie historii bez przycinania wsadowego, przy większym budżecie, kosztowało więcej niż brak buforowania w ogóle w przypadku trzech z czterech modeli — pamięć podręczna była nieustannie przepisywana i rzadko odczytywana. Infrastruktura pamięci podręcznej włączona bez dyscypliny historii tylko do dopisywania to sposób na ponoszenie dodatkowego kosztu zapisu bez żadnego zysku. Ten tryb awarii jest niezależny od modelu i to dlatego ta sama poprawka zmieniła Model B 29-krotnie.

Gdzie wybór modelu faktycznie się opłacił

Pomiń poprawkę przepływu pracy i porównuj porównywalne: w przypadku tego samego zoptymalizowanego agenta GPT-6.1 Sol działał 2,6 razy taniej niż Model B, przy tej samej cenie katalogowej. Dodatkowym czynnikiem jest zachowanie trafień w pamięci podręcznej, a nie cennik. Sol odczytał 89% swoich danych wejściowych z pamięci podręcznej; Asana nie publikuje równoważnego udziału dla Model B, więc 2,6x to zmierzony wynik bez opublikowanego rozbicia. Traktuj to jako „ten model, przy tym obciążeniu, lepiej wykorzystał swoją pamięć podręczną”, a nie jako ogólną 2,6-krotną przewagę nad modelem, którego nie możemy nazwać.

Strona wykonawcza jest jednoznaczna: 5 razy szybciej niż poziom bazowy, ze zoptymalizowanym przepływem pracy Sol trwającym około cztery minuty w porównaniu z poziomem bazowym wynoszącym co najmniej 22,5 minuty. Szybkość ma znaczenie dla kosztów w agentach rozliczanych za tokeny, ponieważ wolny model, który się zapętla, płaci za swoje pętle.

Dla każdego, kto liczy sobie te koszty: standardowe stawki API GPT-6.1 Sol wynoszą 2,00 USD za milion tokenów wejściowych, 0,10 USD za milion buforowanych tokenów wejściowych i 10,00 USD za milion tokenów wyjściowych, a jego zniżka za odczyt z pamięci podręcznej to 0,05x stawki wejściowej — największa w obecnym cenniku OpenAI. GPT-6 Astra, model, który wykonał pracę inżynierską w Codex, kosztuje 10,00 USD za wejście i 50,00 USD za wyjście, co stanowi pięciokrotną różnicę, na której oparła się narracja premiery OpenAI. Powód, dla którego badanie dało uruchomienia po 0,47 USD, a nie po 2 USD, nie tkwi w cenniku; tkwi w tym, że 89% bardzo powtarzalnego żądania rozliczono po jednej dwudziestej stawki wejściowej. W agencie mocno korzystającym z pamięci podręcznej pozycja ze zniżką robi więcej niż cena nagłówkowa, a w naszym własnym katalogu ceny katalogowe dostawców przechodzą z 0% marży, więc gdy dostawca zmienia licznik buforowanych danych wejściowych, tego samego dnia odbija się to na Twoim rachunku.

Druga liczba w badaniu: budżet historii decydował o tym, czy agent w ogóle odpowiedział

Koszt pojedynczego przebiegu to liczba, którą wszyscy przytaczają, ale bardziej przydatny wynik badania dotyczy niezawodności — i to właśnie ten wynik operator powinien przeczytać w pierwszej kolejności.

Przy budżecie 120 000 znaków Model C nie odpowiedział w żadnym ze swoich 18 przebiegów, a GPT-6.1 Sol odpowiedział w 3 z 18 — większość przebiegów osiągnęła limit kroków, nie udzielając odpowiedzi.

• Przy 480 000 znaków każde uruchomienie na obu modelach udzieliło odpowiedzi, każde z poprawną odpowiedzią.

• Nowsze modele szybciej przepalały mniejszy budżet: Model C po raz pierwszy skrócił swoją historię przy wywołaniu 10, Model A przy wywołaniu 64.

• W zoptymalizowanym przepływie pracy każde uruchomienie ukończyło zadanie i zwróciło poprawną odpowiedź, a każde uruchomienie w najlepszych warunkach na każdym modelu napotkało wszystkie 192 fakty, które miało zebrać.

To inny argument niż „taniej”. Zbyt mały budżet historii w modelu o dużych możliwościach tworzy agenta, który zawodzi z powodu braku miejsca, a zawodzi przez osiągnięcie limitu kroków, co jest najdroższym sposobem poniesienia porażki — płacisz za cały przebieg i nie dostajesz nic. Zwiększenie budżetu podniosło koszt na jedno wywołanie i obniżyło koszt na odpowiedź, a to jedyna liczba, jaką powinien śledzić właściciel środowiska produkcyjnego. Jeśli oceniasz niesprawdzony model pod kątem agenta takiego jak ten, wzorcem niskiego ryzyka jest pozostawienie trasy produkcyjnej na modelu, któremu ufasz, i umieszczenie nowego modelu za mechanizmem przełączania awaryjnego lub trasą rozdzieloną, tak aby awaria limitu kroków ujawniła się jako fakt dotyczący routingu, a nie jako incydent. Każdy model w tym porównaniu jest dostępny przez jedno API dla ponad 200 modeli z cennikiem listowym dostawców przekazywanym bez zmian, co dodatkowo sprawia, że zniżka za odczyt z pamięci podręcznej jest porównywalna u różnych dostawców na tej samej fakturze, a nie na pięciu pulpitach.

Co z tego wyciągnąć, po kolei

Jeśli prowadzisz agenta przeglądarkowego lub agenta obsługującego komputer, trzy dźwignie w badaniu Asany warto pociągnąć, zanim spojrzysz na cennik:

• Spraw, aby prefiks żądania był przeznaczony wyłącznie do dopisywania. Jakakolwiek modyfikacja w środku historii wprowadzana przy pojedynczym wywołaniu zeruje ponowne wykorzystanie pamięci podręcznej od tego miejsca wzwyż.

• Przycinaj partiami. Kolejna analiza Asany wykazała, że zachowywanie każdego zrzutu ekranu kosztowało o 1,2x mniej na wywołanie niż najlepszy warunek przycinania w przypadku Modelu B i GPT-6.1 Sol, a około 5% mniej w przypadku Modelu C. Przycinanie wciąż ma znaczenie w długich zadaniach, przy małych oknach kontekstowych i kosztownych odczytach z pamięci podręcznej — ale argument za współczynnikiem partii 20:1 dotyczy stabilności pamięci podręcznej, a nie samych zrzutów ekranu.

• Ustaw budżet historii dla każdego modelu i sprawdź go względem limitu kroków. Budżet, który wystarcza jednemu modelowi, może głodzić kolejny.

Dwa zabezpieczenia z badania łatwo pominąć, a nie należy. Żaden przebieg nie osiągnął budżetu 480 000 znaków, więc budżet nigdy nie ograniczał tych przebiegów — ale dryfujący agent zbliża się do swojego limitu kontekstu, a jeśli pamięć podręczna zawiedzie, każde wywołanie kosztuje pełną cenę. Limity liczby kroków, tokenów i kosztu na przebieg są tym, co ogranicza zły przebieg. Osobno: w badaniu użyto trzech lub czterech przebiegów na warunek, ze zmienną liczbą wywołań, co — jak sama Asana twierdzi — wystarcza do pokazania ogólnych wzorców, a nie do rozróżnienia warunków różniących się o kilka procent. Nie wyciągaj z tego różnicy 5% i nie przebudowuj wokół niej swojego potoku.

Ta część, która jest naprawdę nowa, i ta, która nie jest.

Zastrzeżenia dotyczące konfiguracji warto podać wprost: cztery modele, trzy z nich nienazwane, jedno wąskie zadanie obejmujące 32 książki, własne, instrumentowane liczniki Asany i własna publikacja dostawcy zawierająca wynik. Nic z tego nie zostało odtworzone poza Asaną. Ale mechanizm jest w pełni określony — historia tylko do dopisywania, znacznik pamięci podręcznej przy ostatnim wyniku narzędzia, przycinanie wsadowe, większy budżet, pomiar odczytów z pamięci podręcznej za pomocą liczników dostawcy — i jest to ten rodzaj odkrycia, który przetrwa przypisanie go niewłaściwemu laboratorium. 76x to wynik Asany dla obciążenia Asany. Powód, dla którego warto to czytać, jest taki, że pokazuje regułę, którą można sprawdzić w jedno popołudnie: agent, który na każdym kroku edytuje własną historię, płaci pełną cenę za rozmowę, którą już odbył.