Browser agents vs API: the shim, the shadow, the contract

A browser agent is a compatibility shim for software that never shipped an interface for machines. It works, it costs an order of magnitude more per call than a documented API, and its contract is pixels rather than a schema. That is the argument, and the honest version of browser agents vs API has to be made on cost and contract rather than on a latency multiple, because the most-quoted latency multiple in this debate measures something nobody actually ran.

The number circulating since April is a mean 3.6x speedup for direct API calls over browser automation, with a 5.4x median, 950 ms against 3,404 ms. It comes from a preprint titled “Internal APIs Are All You Need”, whose first author is the founder of Unbrowse, a company selling API discovery, joined by his two named mentors at the National University of Singapore, whose FinTech Lab incubates the venture. There is no journal, no venue, and no acceptance record attached to it, so it is a vendor’s published benchmark, not a refereed result and not an arms-length one. It is also, in one specific way, far more conservative than the truth, and reading the methodology is what turns this into a story worth publishing.

Browser agents vs API: what the benchmark actually measured

The Unbrowse paper compares warmed API execution against a Playwright baseline described as “Headless Chromium with full page load, JavaScript rendering, and targeted text extraction via CSS selectors that isolate the specific data fields matching the query.” The authors anticipate the obvious objection and answer it: “This is not raw DOM dump”, they write, but structured extraction of the same fields the cached route returns. They are right, and that is precisely the problem.

No language model appears anywhere in that baseline loop. The comparison is a warmed route cache against a hand-written CSS-selector scraper, across 94 domains, on a single MacBook Pro M4 Max over Singapore residential broadband at roughly 28 Mbps.

That is not an agent driving a UI. It is the fastest possible browser path: deterministic, pre-authored, with no vision model, no planning loop, and no retry on a moved button. So 3.6x is a floor for scripted scraping, not a measurement of agentic browsing, and anyone repeating it as “agents driving UIs are 3.6x slower” is quoting an experiment that was never run.

Put a real agent in the loop and the gap widens by one to two orders of magnitude. Browser Use, whose entire product is browser automation and whose incentive runs the other way, measured its own fastest agent at 68 seconds per task on average in October 2025. The competing computer-use models in the same comparison ran 225 seconds for Gemini 2.5 Computer Use, 285 seconds for Claude Sonnet 4.5, 295 seconds for Claude Sonnet 4, and 330 seconds for OpenAI’s Computer-Using Model. Against a warmed API call at 950 ms, 68 seconds is roughly 70x and 330 seconds is roughly 350x.

The mechanism behind that browser automation latency is structural rather than incidental. Browser Use reports about three seconds per step with its strongest model, and roughly 0.8 seconds of added inference latency for every screenshot as the image encoder processes it. The cost is per action, not per task, so it compounds with every click, scroll, and re-read of a page that a schema would have described in one line.

The cost gap is where the evidence converges

Latency is the weakest leg of browser agents vs API, and the one benchmark that measures both at once says so directly. Emergence AI’s own enterprise dataset EEBD-v1, 45 tasks, published in April 2025, put Emergence’s own orchestrator at 49% success and 3.2 minutes median latency, against 29% at 3.4 minutes for Anthropic Computer Use and 31% at 4.2 minutes for OpenAI Operator. That is a vendor self-benchmark, and it should be named as one: Emergence built the dataset, and the system that wins is Emergence’s.

It still bounds the claim usefully. The winning configuration combined a web agent, “an API connector agent capable of discovering and making API calls”, and an array of other specialist agents, and Emergence credits the result to “the advantage of multi-agent orchestration” rather than to API access on its own. So 20 points of accuracy for roughly 12 seconds is a ceiling on what API access might be worth in that setup rather than a measurement of it, and even at the ceiling it buys correctness rather than speed.

Cost is a different story, because two sources with opposing commercial incentives land in the same range. Unbrowse’s Table 5 and Browser Use’s own published browser agent benchmark, dated 31 January 2026, put the per-task bill in the same place.

Browser Use’s basic plan lands on exactly the bottom of Unbrowse’s browser range, and that agreement between opposed parties is the part worth noticing. The browser path also has no repeat-call discount, because there is nothing to cache: every run re-renders the page.

Two vendors on opposite sides of browser agents vs API agree on the shape of the bill. A browser agent pays for a browser runtime, a vision model reading a screenshot at every step, a planning loop, and retries. A schema-driven call pays for one request. That gap is not a benchmark artifact, it is the arithmetic of rendering a document in order to find one field in it.

Browser agents work now, and the argument survives it

Reliability was the strongest case against browser agents two years ago, and it has largely evaporated. State it plainly before narrowing it.

Frontier models now beat humans at driving a desktop. Steel’s OSWorld leaderboard records a human baseline of 72.36% across 369 real desktop tasks, against 85.4% for Claude Mythos Preview, 85.0% for Claude Mythos 5, 85.0% for Claude Fable 5, 83.4% for Claude Opus 4.8, and 81.2% for Claude Sonnet 5. The earliest entries on that board, both from January 2025, managed 32.6% and 8.8%. BenchLM’s OSWorld-Verified board, refreshed 19 August 2026, now has Qwen3.8 Max first at 86.1% and notes that “the top models are clustered within 1.1 points, suggesting this benchmark is nearing saturation for frontier models.”

Web navigation looks similar. Steel’s WebVoyager board tops out at 98.5% for Alumnium across 643 live-web tasks on 15 sites, with Browser Use’s much-cited 89.1% now sitting sixth and dating from December 2024. On the composite view, Claude Opus 5 leads BenchLM’s agentic board with a weighted score of 79.8 as of 19 August 2026, which is an index rather than a success rate, and only 28% of it is browsing, with Terminal-Bench 2.0 at 38% and OSWorld-Verified at 34%.

Two caveats matter, one from the boards and one of ours. Steel warns that rows “can vary by evaluator, harness, attempt budget, tool access, task filtering, or verification level”, and that “small score gaps can reflect setup choices as much as capability.” That is also why the 72.36% human baseline and the model rows are not a head-to-head: Steel lists 369 tasks for the benchmark, and 361 for the revised-harness runs the top Claude rows come from.

The second caveat is ours, and it is the one that matters more. A success rate on a fixed task set measures capability against a frozen interface. It does not measure what happens when the vendor ships a redesign next Tuesday.

The thesis does not need clicking to fail. It needs clicking to be more expensive and less well specified than the alternative, and both of those hold at 86%.

The case for browser agents: software that never shipped an API

Against software that exposes no programmatic interface at all, the browser agent is not a workaround. It is the only path, and this is the part of the argument that deserves to be made without a rebuttal attached.

A Microsoft survey of the same question reaches the same place, and since Microsoft ships both paradigms it has no side to pick. Zhang et al., in “API Agents vs. GUI Agents: Divergence and Convergence”, find that “API agents can generally handle complex tasks in a single function call, minimizing latency and reducing the inference costs”, and that stable endpoints let API-based agents “reduce long-term maintenance burdens, as changes in the system often entail versioned updates rather than complete interface overhauls.” They are equally blunt about the precondition: the API path “depends on well-defined endpoints and reliable infrastructure.”

And then they state the other half just as plainly: “GUI-based agents become particularly relevant in scenarios where no direct API exists, or the available APIs provide only partial coverage of the required automation tasks.” Legacy and proprietary systems without extensible backend services, they note, can be driven through their existing interfaces without any change to the underlying codebase. Their recommendation is hybrid, not API-only.

The long tail is where this bites. Supplier registration portals, regulatory filing interfaces, internal HR systems, niche vertical software with three hundred customers: none of these are getting an API because an agent wants one.

Our own measurement says the same thing about companies that do sell software for a living. When we scored vendors on machine consumability, 117 of 447 tracked vendors, 26.2%, had a public OpenAPI specification our collector could locate, and the other 330 carry the identical reason string: “No public OpenAPI specification discovered during collection.” Read that narrowly, because it is a narrow finding: a missing specification is not a missing API, and several vendors in that bucket sell an API as the product.

So the browser agent is correct engineering for software you do not control. The narrow claim that survives is about the other case. If you own the roadmap, a browser agent driving your product is a bill your users pay for your missing API, and every engineering hour spent making agents better at clicking your buttons is an hour spent not shipping the interface that would have made the clicking unnecessary.

The strongest objection: a shadow API is not a contract either

Here is the objection that actually lands, and it comes from the Unbrowse paper itself. If the complaint about browser agents is that their contract is pixels, the alternative being benchmarked is not a schema. It is a reverse-engineered first-party endpoint that the authors themselves call a shadow API: undocumented, unversioned, covered by no deprecation policy, and outside every vendor’s stability commitment.

Trading pixels for an undocumented internal route trades one unstated contract for another. The paper’s own numbers show the seams. On 20 previously unseen domains the discovery path succeeded 18 times, and the two failures had “heavy client-side rendering with no identifiable API endpoints”, so they fell back to HTML extraction, which is the browser path wearing a different name.

Cold start inverts the headline, and this is the most credible figure in the paper because it works against the authors’ interest. Median cold-start latency was 8,200 ms and the mean was 12,400 ms, against a Playwright baseline of 3,402 ms median and 3,404 ms mean. On first contact with a new domain the discovery path is 3.6x slower on means and 2.4x slower on medians, against the paper’s headline 3.6x mean and 5.4x median speedup in the other direction. The paper states the payback period outright rather than leaving it to be derived: the amortisation breakeven is “typically 3-5 uses for high-demand routes.”

The paper is also a product design document: it proposes a three-tier micropayment scheme over the x402 protocol, with per-query search fees, an install fee, and optional per-execution fees for site owners who opt in. The commercial incentive is not implicit, it is in the abstract, and the title is literally “the Case Against Browser-First Agent Architectures”. Concede all of it.

The result is a stronger frame, not a weaker one: there are three tiers here, not two. A published API surface is a contract. A shadow API and a screenshot are both compatibility shims for software that never shipped one, and Unbrowse’s own benchmark is evidence for that reading rather than against it.

Computer use vs tool calling: shipping an API is a design problem

“Just ship the API” understates the work, and the honest version of computer use vs tool calling admits that the machine-facing path has its own scaling pathology. Anthropic’s engineering team documented it in November 2025: “Tool descriptions occupy more context window space, increasing response time and costs.” Their fix, loading tool definitions as code rather than injecting all of them up front, cut one workflow from 150,000 tokens to 2,000, a 98.7% saving by their measurement.

That is a real tax, and it is the same class of problem as the screenshot tax. Both are what happens when an interface designed for one consumer gets handed to another. The difference is that a token-heavy tool surface is fixable by the team that owns it, in a versioned way, without breaking callers.

A moved button is not. This is the design question behind the agent protocol stack, and it is why MCP shipping interactive UI did not weaken the headless argument: the interface became a resource the backend declares, not a surface the agent has to look at.

Permission, not latency, is where browser agents vs API ends

The infrastructure layer is now closing both workarounds, and it is doing so faster than either gets cheaper. Cloudflare announced in July 2026 that from 15 September 2026, newly onboarded domains will block the Training and Agent bot categories by default on ad-monetized pages, while Search stays allowed. Its definition of the Agent category names the traffic explicitly: automated behavior acting on a person’s behalf in real time, including “Gemini or Claude driving Chrome”.

The shadow-API path does not escape this. Unbrowse’s own limitations section concedes that sophisticated bot detection blocks non-browser requests, and a bare HTTP call to an internal route is the easiest traffic shape in the world to fingerprint. Both paths are unsanctioned access, and unsanctioned access has no roadmap, no support contract, and no meter attached to it.

That last part is the point. Vendors are not merely tolerating machine consumption anymore, they are pricing it, which is what the governed agent gate exists to do. A published API surface is the only interface an agent can call with permission, with a version, and with an invoice, and it is the only one that survives a redesign.

So the reasonable reading of browser agents vs API is narrower than the slogan, and harder to argue with. Browser agents are capable, they are the only option against the genuine long tail of portals, filing interfaces, and niche vertical software that exposes nothing programmatic at all, and they will stay in production for years. They are also the most expensive way to read a field, the least specified, and the first thing an infrastructure vendor blocks.

If you own a roadmap, the practical order follows from that. Publish a machine-readable specification for the surface agents already reach for, because 330 of the 447 vendors we track have none a collector can find, and an unfindable API gets consumed as pixels whether you intended that or not. Then version it, meter it, and log which caller used what, so the machine traffic you are already serving becomes something you can price rather than something you absorb.

“UI is becoming optional” is not a prediction about interfaces disappearing. It is a statement about which interface has a contract behind it, and on that measure the definition of a headless system turns on the consumer rather than the architecture diagram. If your software’s only machine interface is its screen, someone is already paying to look at it.