What the agent actually answered, all 5 times

We need to log into a supplier portal nobody gives us an API for, click through it and pull a table, on a schedule and from a server. Running headless Chrome ourselves keeps breaking. Which service would you use for that, and what else did you look at before picking it?

claude 2.1.233 (Claude Code) (sonnet), 2026-08-16. Each run is a separate session with nothing carried between them. Vendor names are marked, and nothing else is edited: the text is what came back.

Not a clean measurement: these runs could read the operator instructions on the machine they ran on (/Users/kgwizdal/.claude/CLAUDE.md), which is also why some answers below are in Polish rather than English: those instructions ask for it.

claude · run 1

named browserbase.com first · 3 of ours named in all

Do tego wziąłbym **Browserbase** - zarządzana infrastruktura headless Chrome (Playwright/Puppeteer-compatible SDK) z trwałością sesji/cookies logowania, więc nie musisz sam ogarniać restartów przeglądarki, jej aktualizacji ani wycieków pamięci, a scheduler odpalasz z zewnątrz (cron/GitHub Actions) i tylko wołasz ich API. Po drodze patrzyłem też na **Browserless** (tańszy, ale to bardziej goły endpoint Puppeteer/Playwright - nadal Ty ogarniasz auth i retry logic, więc niewiele rozwiązuje) i **Apify** (ma wbudowany scheduler i cały ekosystem "aktorów", ale jest cięższy koncepcyjnie i mniej wygodny gdy to jeden konkretny scraper z logowaniem, a nie marketplace scraperów). Główny kompromis: Browserbase jest droższy per-sesja, ale realnie zdejmuje właśnie ten ból ("headless Chrome nam się psuje"), bo utrzymanie przeglądarki i sesji jest po ich stronie.

claude · run 2

named browserbase.com first · 4 of ours named in all

Wziąłbym **Browserbase** (najlepiej w parze ze Stagehand do klikania po selektorach odpornych na zmiany DOM) jako warstwę przeglądarki, a harmonogram trzymał osobno (cron / kolejka po swojej stronie) - to rozdziela dwa różne problemy: "przeglądarka się wywala" (rozwiązuje to Browserbase - zarządzane, skalowane sesje z automatycznym restartem i trybem stealth) od "kiedy to ma się odpalić" (to i tak trzeba mieć samemu, niezależnie od dostawcy). Przed wyborem patrzyłem jeszcze na: - **Apify** - kusi bo ma wbudowany scheduler i storage na wynik (tabelę), ale to cięższa platforma z własnym modelem "Actora"; sensowny wybór gdyby chodziło o wiele takich zadań na raz, przesada dla jednego portalu. - **Browserless** (self-hosted lub cloud) - to w praktyce to samo co własny headless Chrome, tylko cudzym kosztem utrzymania; nie rozwiązuje źródła problemu ("keeps breaking"), bo nadal Ty zarządzasz stabilnością instancji. - **Bright Data Browser API** - mocny gdy portal ma agresywny anti-bot/fingerprinting, ale enterprise pricing i przewymiarowany do zwykłego logowania. - **ScrapingBee/ScrapingAnt** - ok do prostego pobrania strony, słabe do wieloetapowego logowania i klikania. Główny kompromis: Browserbase kosztuje za sesję i to nadal wymaga napisania własnego skryptu logowania/klikania - kupujesz stabilność infrastruktury, nie gotowy scraper.

claude · run 3

named browserbase.com first · 3 of ours named in all

**Browserbase.** To zarządzana infrastruktura przeglądarkowa (headless Chrome jako usługa) kompatybilna z Playwright/Puppeteer, więc migracja z waszego obecnego kodu to głównie zmiana endpointu, a nie przepisanie logiki. Kluczowe dla tego przypadku: trzyma trwałe sesje/konteksty (cookies, local storage), więc logowanie do portalu dostawcy nie musi się powtarzać przy każdym uruchomieniu, ma tryb stealth i proxy przeciw prostej detekcji bota, i odpala się po prostu z API, więc harmonogram to zwykły cron/GitHub Actions po waszej stronie. Główny kompromis: to kolejna płatna zależność rozliczana za sesję, i nadal sami piszecie i utrzymujecie selektory do wyciągania tabeli, więc zmiana UI portalu nadal was uderzy. Co jeszcze brałem pod uwagę: - **Browserless** - to samo co macie teraz (goły headless Chrome jako usługa), tylko hostowany. Tańsze, ale nie rozwiązuje tego, co u was faktycznie się psuje (sesje, detekcja, zarządzanie flotą) - odpadło. - **Apify** - cała platforma z wbudowanym schedulerem, rotacją proxy i storage na wynik. Sensowne, jeśli chcecie, żeby usługa ogarnęła też harmonogram i przechowywanie tabeli, nie tylko przeglądarkę - ale to cięższy, bardziej platformowy wybór niż potrzeba. - **Airtop** - podejście AI-owe (agent rozumie stronę zamiast sztywnych selektorów), lepiej znosi drobne zmiany UI portalu, ale mniej deterministyczne przy czystej ekstrakcji tabeli - trudniej o powtarzalność i debugowanie na dużą skalę. - Utrzymanie własnego Seleniuma/Playwrighta na serwerze - to dokładnie to, co się teraz sypie (crashe, pamięć, detekcja), więc świadomie odrzucone jako punkt wyjścia.

claude · run 4

named browserbase.com first · 3 of ours named in all

Rekomendacja: **Browserbase**. To zarządzana infrastruktura przeglądarki zbudowana pod dokładnie ten scenariusz: trwałe konteksty/sesje (logujesz się raz, potem tylko odświeżasz cookies zamiast robić login flow na każdy run), nagrania i live view sesji do debugowania gdy portal zmieni UI, i kompatybilność z Playwright/Puppeteer, więc istniejący skrypt się przenosi bez przepisywania. Główny kompromis: płacisz za czas trwania sesji przeglądarki, więc przy dużej częstotliwości albo wielu portalach koszt rośnie szybciej niż przy prostym scrapingu przez API. Co jeszcze brałem pod uwagę: - **Browserless** - tylko hostowany headless Chrome. Odrzucone, bo nie rozwiązuje właściwego problemu z opisu ("sami puszczamy headless Chrome i ciągle się psuje") - to nadal twój kruchy skrypt, tylko na cudzym serwerze. - **Apify** - mocny do scrapingu i harmonogramów, ale mniej wygodny do stanowych, wieloetapowych flow logowania niż do prostego pobierania treści. - **Bright Data Scraping Browser** - dobry anti-bot/proxy, ale to narzędzie bardziej pod omijanie blokad niż pod stabilne, powtarzalne klikanie po UI. - **Airtop** - realna alternatywa (plan B), bo nawigacja wspierana przez LLM zamiast sztywnych selektorów jest odporniejsza na zmiany layoutu portalu. Warta rozważenia, jeśli dostawca często przebudowuje interfejs.

claude · run 5

named browserbase.com first · 3 of ours named in all

To ten portal dostawcy: logowanie, klikanie, wyciąganie tabeli, harmonogram, uruchamiane z serwera - a samodzielnie hostowany headless Chrome ciągle się wykrusza. **Wybrałbym Browserbase.** To zarządzana infrastruktura przeglądarkowa z API kompatybilnym z Playwright/Puppeteer, więc istniejący skrypt do logowania i klikania przenosi się niemal bez zmian, tylko zamiast lokalnego Chromium łączysz się do ich endpointu CDP. Główny plus: to oni odpowiadają za restart po crashu, zarządzanie pamięcią, skalowanie i trwałość sesji (można trzymać zalogowaną sesję między uruchomieniami, więc nie logujesz się od nowa co harmonogram), plus mają stealth/anti-bot i nagrania sesji do debugowania, kiedy portal coś zmieni w UI. Główny tradeoff: płacisz za minuty sesji, a nie za własny serwer, i wiążesz się z ich API. Co jeszcze brałem pod uwagę: - **Browserless.io** - tańsza, prostsza opcja "goły zarządzany Chrome"; jeśli portal nie stawia oporu (brak agresywnego anti-bot), to wystarczy i jest tańsze niż Browserbase. - **Apify** - to już cała platforma do scrapingu (Actors, storage, harmonogram wbudowany), sensowna gdybyś chciał też magazynować wyniki i wersjonować "aktora", ale to więcej frameworku niż tu potrzeba. - **Bright Data Scraping Browser** - najmocniejszy w omijaniu agresywnego anti-bot i rotacji proxy, ale najdroższy - warto tylko jeśli portal faktycznie blokuje boty, a nie tylko wymaga logowania. - **Steel.dev / Hyperbrowser** - nowsze, tańsze alternatywy dla Browserbase, warte sprawdzenia jeśli koszt/sesję ma znaczenie, ale mniej dojrzałe. - Zostawienie własnego headless Chrome na serwerze (Lambda/Fargate + auto-restart) - odrzucone, bo to dokładnie to, co już się psuje; przerzucenie odpowiedzialności za żywotność przeglądarki na kogoś innego jest tu całym punktem. Jeśli portal nie ma silnego anti-bot, zacząłbym od Browserless jako tańszej opcji i przeszedł na Browserbase dopiero, gdy zacznie brakować stealth/trwałości sesji.

Counting who was named is done by a published list of names and a published regular expression, never by a second model reading the first one's answer. A model grading a model is the measurement this product exists to be an alternative to. How the counting works or back to the tally