How do browser-automation sessions compare with generated API calls for software without an API?

What runs on each call

Supergood is one vendor of the generated approach; Browserbase, Browser Use, Skyvern and Steel sell hosted browsers or browser agents.

The cleanest way to think about the pair is borrowed from programming languages. A browser agent is an interpreter: it works out what to do at runtime, on every run, and you pay for that working-out every time. A generated integration is a compiler: it does the working-out once, from a recording, and ships something that simply executes. Nobody argues about which is better in the abstract. You interpret while you explore and compile the hot path, and how often a task repeats decides which side it belongs on.

Where each one fails

Browser bots have earned their reputation for breaking, but they usually break noisily. A selector stops matching, a step times out, the run goes red.

A generated integration that parses HTML can break more quietly. On an ASP.NET WebForms parcel portal in our 8 to 10 September 2026 field test of Supergood, a table header carried a line break between "Gross" and "Area". Text extraction ran the two words together and silently broke the mapping for the area fields: nothing crashed, the data was simply wrong. The agent's own replay self-test against the recording caught it, and the corrected mapping matched the portal's figures on a live call. That one header is the maintenance argument in miniature. A direct call's speed is pleasant, but what you are really buying is the checking around it.

Bad input is the opposite story. When we sent a Supergood auction integration the documented placeholder service account on 15 September 2026, it rejected all 10 calls with HTTP 400 at a displayed median of 36 ms, and its error log said retrying with the same arguments would fail identically. A browser bot typically learns the same thing several page loads into a metered session.

Measured latency of a generated call

Supergood's dashboard showed the deployed parcel-records integration answering 10 of 10 of our calls with HTTP 200 on 15 September 2026, at a median of 490 ms and a slowest of 516 ms. The target was a public US county portal. Earlier readings agree: 458 ms for a live lookup during the field test, and upstream requests of 446 to 475 ms in the builder's sandbox on 14 September, inside sandbox totals of 5,912 to 6,322 ms that time the test harness rather than the endpoint.

Half a second, consistently, from a portal with roughly 2008-vintage WebForms controls is a good result. How much faster than a browser session depends on the site, so no margin is claimed here.

Browser infrastructure is priced per hour, credit or token

The missing column is a per-call price. Browser vendors sell time, credits or tokens, so a task's cost depends on how long its session runs and how many steps it takes. We don't convert these into per-call figures, because the assumptions behind the conversion decide the answer.

The per-call numbers you will see quoted come from Supergood. In a 15 May 2026 post on Supergood's blog, founder Alex Klarfeld puts hosted browser costs at "$0.12-$0.24 per call at their lowest" and "closer to $1-$1.50" in real-world use. That is a competitor making its case, not an independent benchmark. The structural point stands without it: the browser meter runs on every call, while a generated integration's effort is mostly spent before the first one, plus whatever Supergood charges, which it does not publish.

When a browser session is the right call

Use a browser session when the job is a one-off or still being figured out, since a generated integration needs a recording, generation and a reviewed diff before its first call. Use one when the output is the rendered page itself, such as screenshots or visual regression checks, and when each next step depends on judging what is on screen rather than following a fixed request pattern. Use neither when the vendor already has an official API; Supergood's own documentation, read 8 September 2026, says "If a vendor offers an official API, we highly recommend it."

Neither route gives you permission to automate a site. Terms of service apply to browser traffic and direct requests alike, as What is browser automation and how does it work? explains. We read each target's robots.txt before the September 2026 tests; the auction portal's allowed the public search and listing paths and disallowed only logged-in account routes. Cheap, scheduled access makes that check more important, not less.

Editor's Note: People will lift the 490 ms median from our recent calls, but the detail that matters is a line break. During our 8 to 10 September field test, a table header on an old WebForms portal split "Gross" and "Area" across two lines, the parser glued them together, and the area fields went quietly wrong. A browser bot would more likely have gone red; this integration could have returned a healthy-looking 200 with bad data had its own replay self-test not caught the bug. So ask how each approach tells you it is wrong, and how often the task repeats. The same integration rejected bad input at a displayed median of 36 ms, with a log note that retrying would fail identically, which is the other half of knowing when something is wrong. — Rafal Fila, ShadowGen