Computer Use vs structured API: dlaczego klikanie myszą przez agenta AI jest 45 razy droższe od wywołania API

17 minut. Tyle średnio potrzebował agent AI klikający w panel administracyjny, żeby wykonać proste zadanie z zarządzania zamówieniami. Ten sam workflow przez wywołania API zajął 7,7 sekundy. Liczba tokenów? 550 tysięcy dla wersji vision, 12 tysięcy dla wersji API. Ten benchmark opublikował zespół Reflex.dev na początku maja 2026, a na Hacker News zebrał ponad 400 punktów dyskusji. Pokazujemy, co dokładnie zmierzono, czemu różnica jest aż tak drastyczna i kiedy mimo tego Computer Use ma jeszcze sens dla osoby budującej automatyzacje w n8n.

Co dokładnie zmierzył Reflex.dev

Zespół Reflex.dev wziął typowy panel administracyjny – aplikację inspirowaną reactowym demo “Posters Galore”, z trzema zasobami: klienci, zamówienia, recenzje. Workflow do wykonania brzmiał tak: znajdź klienta o nazwisku Smith z największą liczbą zamówień, znajdź jego najnowsze zamówienie ze statusem oczekującym, zaakceptuj wszystkie oczekujące recenzje tego klienta, oznacz zamówienie jako dostarczone. Klasyczne zadanie wymagające filtrowania, paginacji i łączenia danych z różnych zasobów – czyli takie, które codziennie wykonują ludzie w biurach zaplecza administracyjnego.

Następnie zespół zbudował dwie wersje agenta AI. Pierwsza, agent wizyjny, używała narzędzia browser-use 0.12 z Claude Sonnet do klikania w interfejs. Druga, agent API, wywoływała bezpośrednie punkty końcowe serwera. Te punkty Reflex 0.9 generuje automatycznie z funkcji obsługujących zdarzenia w aplikacji. Każda wersja przetestowana była na 3-5 próbach. W wariancie API testowano dodatkowo Haiku.

Stosunek tokenów wejściowych agenta wizyjnego do agenta API wyniósł około 45 do 1. Stąd 45x w nagłówku artykułu. Z kolei 130x dotyczy czasu wykonania, ale w porównaniu do najszybszego wariantu API Haiku (1003s vs 7,7s). Co więcej, agent wizyjny bez doprecyzowanego promptu nie ukończył zadania w ogóle. Obrabiał tylko jedną z czterech recenzji i nie radził sobie z paginacją. Reflex musiał napisać szczegółowy przewodnik na 14 kroków, żeby agent wizyjny dał radę.

Zastrzeżenie: Reflex.dev sprzedaje plugin do automatycznego generowania API w swoim frameworku, więc benchmark ma motyw sprzedażowy. Co nie zmienia faktu, że liczby są twarde, a dyskusja na HN nie skupiła się na podważaniu samej metodologii. Spór dotyczył raczej wniosków z wyników i wyboru narzędzi alternatywnych.

Czemu różnica jest aż tak drastyczna

Klucz jest architektoniczny. Agent wizyjny musi widzieć, żeby działać. Każdy krok to nowy zrzut ekranu, który model musi rozłożyć na tysiące tokenów wejściowych. Cytat z artykułu Reflex.dev brzmi precyzyjnie:

An agent that must see in order to act will always pay for the seeing. Each render is a screenshot is thousands of input tokens.

Agent API natomiast czyta strukturalną odpowiedź serwera, która już zawiera dokładnie te dane, które interfejs miał wyrenderować. Zamiast przepuszczać dane przez warstwę graficzną i potem rozpoznawać je z obrazu, agent dostaje JSON i działa. To różnica jak między oglądaniem dokumentu na ekranie z daleka a czytaniem go bezpośrednio z dysku.

Drugi czynnik to liczba kroków. Agent wizyjny potrzebował 53 kroków, agent API tylko 8. Każde kliknięcie w interfejs generuje nowy stan, który trzeba widzieć i analizować. API wykonuje tę samą logikę w jednym wywołaniu, bo ma dostęp do operacji wsadowych. Mnoży to różnicę ekonomiczną na trzech wymiarach: tokeny na krok, liczba kroków oraz czas poszczególnych zapytań.

W praktyce ceny Anthropic z maja 2026 wyglądają tak: Sonnet 4.6 to 3 dolary za milion tokenów wejściowych i 15 dolarów za milion wyjściowych. Pojedyncze zadanie kosztuje więc około 2,22 dolara w wersji wizyjnej i 0,05 dolara w wersji API. Dla workflow uruchamianego 100 razy dziennie wychodzi 217 dolarów kontra 5 dolarów. Sama różnica potrafi sfinansować nową automatyzację co tydzień.

Co o tym myśli społeczność deweloperów

Wątek na Hacker News zebrał ponad 400 punktów i 225 komentarzy. W dyskusji wyłoniły się trzy stanowiska, które warto streścić.

Stanowisko pierwsze: API jako wybór domyślny, agent wizyjny jako ostateczność. Najpopularniejszy komentarz brzmiał: “Czas na zegarze mówi mi wszystko. Model wizyjny zajął prawie 20 minut. Jedyny powód, żeby nie wybrać API, to gdyby nie był dostępny” (janalsncm). Inny głos: “Strukturalne API są nie tylko 40 razy tańsze, ale przede wszystkim wystarczająco deterministyczne, żeby zbudować na nich stabilny produkt” (jacktu).

Stanowisko drugie: Computer Use ma sens dla starych systemów. Część deweloperów wskazywała, że agent wizyjny to jedyny sposób na pracę z systemami sprzed ery API. Cytat: “Świat, w którym rzeczy budowano przed OpenAPI i przed specyfikacjami, dalej istnieje” (orliesaurus). To głównie stare ERPy, systemy księgowe sprzed 2015 roku, niedostępne aplikacje SPA bez publicznego punktu końcowego. Tam Computer Use jest droższy, ale jedyny.

Stanowisko trzecie: hybrydy oparte na DOM i dostępności wygrają. Trzecia grupa wskazywała na narzędzia takie jak Playwright z lokalizatorami dostępności, interfejsami dostępności systemów operacyjnych albo integracją MCP. To sposób na ominięcie drogiej ścieżki “zrzut ekranu plus model wizyjny”. Komentarz merlindru z getinvoke.com: “Okazuje się, że drzewo dostępności to po prostu dobre DOM w ogóle”.

Reszta zdania, którą warto zapamiętać z dyskusji: jeśli budujesz agenta AI od zera w 2026 roku, traktuj Computer Use jak ostatnią deskę ratunku, a nie pierwszy wybór.

Co to znaczy dla osób budujących workflow w n8n

Tu dochodzimy do najbardziej praktycznej części. n8n od dawna ma węzeł “AI Agent” połączony z węzłem “HTTP Request”. To dokładnie ten architektoniczny wzorzec, który w benchmarku Reflex’a wygrał wszystkie kategorie. Jeśli budujesz automatyzację z LLM-em pośrodku, a system docelowy ma API, sprawa jest prosta i tania.

Pytanie ekonomiczne pojawia się, kiedy systemu docelowego API nie ma. Trzy typowe scenariusze, w których osoba budująca workflow w n8n staje przed dylematem:

Stary system bez API. Polskie firmy często używają systemów ERP albo księgowych z okresu 2010-2015, które nie wystawiają punktów końcowych REST. Tutaj węzły społecznościowe typu Puppeteer czy Playwright dla n8n są tańszą alternatywą niż klasyczne Computer Use. Działają jednak na drzewie DOM, a nie na pikselach, więc liczba tokenów wejściowych spada o rząd wielkości w porównaniu do “zrzut ekranu plus model wizyjny”.

Aplikacja SaaS bez publicznego API. Część dostawców blokuje publiczne API, żeby zmusić klientów do droższych planów dla firm. Tutaj często warto napisać samemu prostą nakładkę API w ciągu jednego dnia (oczywiście zgodnie z regulaminem usługi), zamiast codziennie płacić za agenta wizyjnego. Koszt jednorazowej pracy kontra rosnący koszt zapytań – matematyka zwykle wychodzi po stronie nakładki.

Workflow okazjonalne, jednorazowe. Tu Computer Use ma sens. Jeśli zadanie wykonujesz 5 razy w roku i w sumie kosztuje 11 dolarów dla agenta wizyjnego, budowa integracji za 200 dolarów jednorazowo nie zwróci się. Zostań przy ekranie i klikaniu – to nie jest wstyd, to ekonomia. O szerszym kontekście budowania agentów AI z dostępem do narzędzi pisaliśmy w bezpieczeństwie serwerów MCP dla agentów AI, gdzie ten wybór ma też wymiar bezpieczeństwa.

Reguła kciuka: wybieraj API, kiedy tylko możesz. Sprawdź nakładki przed Computer Use. Computer Use trzymaj jako ostatni krok dla starych systemów i zadań jednorazowych.

Kurs n8n 2.0 · Kodożercy

Ile godzin tygodniowo tracisz na powtarzalne zadania?

n8n pozwala zautomatyzować to co robisz ręcznie – przesyłanie danych, powiadomienia, raporty. Kurs n8n 2.0 na Kodożercach pokaże Ci jak, krok po kroku, bez pisania kodu.

Sprawdź kurs n8n 2.0 →

Podsumowanie

Benchmark Reflex.dev pokazuje twardo to, co większość deweloperów podejrzewała intuicyjnie. Klikanie w interfejs przez agenta AI jest drogie, wolne i zawodne w porównaniu do wywołania API, które robi tę samą rzecz w tle. Liczby są dramatyczne (45x tokenów, 130x czasu) i przekładają się na realne pieniądze przy automatyzacjach uruchamianych setki razy dziennie. Dla osób budujących workflow w n8n wniosek jest jasny: zawsze najpierw szukaj API. Jeśli nie ma, sprawdź węzły społecznościowe typu Puppeteer/Playwright. Jeśli i to nie wystarczy, rozważ napisanie prostej nakładki. Computer Use w wersji wizyjnej zostawiaj na koniec, dla starych systemów bez alternatywy oraz dla zadań wykonywanych raz na kwartał. To narzędzie potężne, ale dziś zdecydowanie nie domyślne.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.