Serverless Browsers and the Infrastructure Behind Computer-Using Agents

A browser must run somewhere

At StreamClub, Paul Klein IV built internal infrastructure to run headless browsers—browsers on servers, controlled through code. The difficulty extended beyond launching Chrome: running thousands of browsers meant managing secure environments, capacity and sessions that had to stay alive. Klein says Mux’s interest in that infrastructure drove its acquisition of StreamClub and motivated his next company, Browserbase.

Browserbase gives applications access to hosted browsers through APIs and software development kits, letting them click buttons and fill forms. In the February 2025 conversation, Klein describes a company approaching its first birthday, with 20 people and hundreds of AI-company customers. He positions its core expertise as browser infrastructure at scale.

Large language models (LLMs) increase demand for browsers in two ways. First, models can extract and summarize web content, but retrieving it may require JavaScript execution. Klein’s example is Airbnb: a curl request can miss content populated after the initial page loads. A browser runs the JavaScript and additional requests that make that content available.

Second, models can translate a shared intention into site-specific control code. Booking demo calls across 100 websites might otherwise require 100 scripts. Klein proposes one workflow that generates each site’s script at runtime; Browserbase’s Stagehand framework handles much of that translation. This is a programming-model example, not a measured result of 100 successful bookings.

Vision added a third driver that Klein had underestimated. He expected structured HTML to dominate automation inputs, but screenshot-driven computer-use models advanced faster than he anticipated. Those models also need browsers to render the pages they inspect.

Swyx discloses that he is a Browserbase investor. His thesis treated individual custom GPT capabilities as potential standalone businesses, with Browserbase supplying the browser. His initial hesitation was competition from established providers. Klein’s answer centers on developer experience: browser infrastructure should offer the clarity and polish he associated with Stripe, Clerk and Vercel. Clear messaging and presentation, he argues, help earn trust alongside API reliability.

The distributed system behind a local script

A Puppeteer, Playwright or Selenium script can work locally and still be difficult to deploy. In the deployment example, Chrome’s size creates a Lambda packaging obstacle, with layers or a lighter Chromium build suggested as workarounds. Resource constraints can also slow execution, though the example specifies neither a deployment configuration nor measured timings.

Moving Chromium to a larger server solves the immediate hosting problem. More users then require more browsers, potentially spread across multiple machines and managed through container orchestration. Active sessions constrain scaling: a browser must remain open while someone works with it. Capacity management has to preserve those ongoing connections.

Environment details become application dependencies. - A vision agent looking for an emoji needs the browser to have the corresponding fonts. - Extensions and ad blocking need configuration. - Debugging needs a record of a browser nobody can directly watch, potentially session videos and storage for them. These responsibilities accumulate around the original script.

Browserbase exposes a connect, control, disconnect model through familiar automation frameworks. Its serverless-like experience relies on warm pools—capacity kept ready for incoming work—with multiple browsers per node and Kubernetes scheduling. Starting thousands of browsers in milliseconds is explicitly described as a best-case scenario: a burst of 10,000 requests can encounter slower cold starts. No latency distribution accompanies that claim.

Browserbase reports using predictive scaling and regional browser pools. Region choice matters because automation makes many network round trips. The company describes Firecracker as supporting rapid scaling and isolation between customers, with controls planned to let users trade startup speed against cost.

The initial implementation used Amazon’s ECS and Fargate container services, then moved to lower-level infrastructure for greater control. The rationale is accountability: customers still depend on Browserbase when an upstream provider fails. Its stated principle is deep ownership of components on the critical path.

Reaching a website is another reliability problem

Browser location and website-visible location are separate controls. A locale setting can influence localized content, while a site may also choose content by source IP address. A browser running in Europe can use a US proxy to present a US source address. Browserbase describes selecting proxies according to the destination, including when data-center addresses make access harder.

Browserbase says it owns no proxies. It works with multiple providers, audits their sourcing and routes around failures. One diligence question is whether a proxy runs on someone else’s television. Provider redundancy matters because a healthy browser can still lose access when its only proxy stops working.

CAPTCHA solving adds another set of integrations. Browserbase describes combining several solver vendors with in-house work, monitoring failures and finding alternatives. It reports little to no known abuse, attributing that to customer vetting and restricting certain solving capabilities to selected plans. Longer term, it hopes to identify acceptable agents to websites, potentially working with companies such as Cloudflare. That collaboration is an aspiration.

Agent identity and human takeover

Agent authentication would let websites grant access deliberately. One proposal is a notification asking the user to approve an agent’s access to an Airbnb account. Approval would let it proceed without sharing the person’s password. Authentication is presented as potentially a larger obstacle than CAPTCHAs, with this approval flow proposed as a future design.

Another participant proposes a short-lived agent identity paired with the human’s identity. The agent acts for the person while remaining distinguishable from them. An OAuth-like approval flow would grant narrowly scoped permissions—for example, booking an apartment without permission to message anyone. A further delegation question remains open: whose identity is being authenticated when an application acts for its user through another service?

The broader proposal is to adapt existing authentication protocols and services while retaining much of the web. Dedicated agent APIs could cover major use cases; browser agents could handle many other tasks through existing websites. Access would not depend on every service first building a new agent interface.

For workflows that still need a person, Browserbase offers live view. It began as a trust feature: embed the cloud browser in an application’s iframe so customers can watch automation run. Two-way communication then added pausing, clicking and typing. The implementation streams PNG images through the Chrome DevTools Protocol’s screencast API and sends input events back to the remote browser.

An unsolved CAPTCHA or a two-factor authentication code received by text message gives takeover a concrete purpose: 1. pause automation, 2. let the person complete the interaction, 3. then resume. Showing the browser avoids building a custom interface for every intervention. This remains a cloud-browser model; streaming the user’s existing desktop into Browserbase is not the direction described.

Forking means copying an interactive session

Browser forking would let an agent explore alternative navigation paths in parallel, find a successful route and remember it. Asked about making a hundred copies of the current browser state, Browserbase describes a roadmap idea the team had not implemented.

A half-completed form exposes the difficulty: opening the same URL in a new tab does not reproduce the work already done. True forking might require pausing a container, duplicating its memory and restarting from that state, which could be slow. Copying a page object is considered insufficiently robust. The desired unit of duplication is the interactive session, including its state.

Stagehand supplies tools; the application owns the loop

Stagehand grew from a repeated pattern: pass the page’s structured representation, its DOM, to an LLM and ask for Playwright code that performs an action. The framework makes natural language part of its API. In the version discussed, it extends Playwright with three operations: - act performs an action, such as clicking a button or filling a form. - extract requests information in natural language, optionally using a Zod schema to specify structured output. - observe lists possible actions before the agent chooses one.

For a purchasing task, observe can return buying-related options such as buying immediately, adding to a cart or viewing shipping. The application passes those choices to its model, which selects a step according to the larger goal. This repeated process of choosing and executing steps—the agent loop—stays with the application, where goals and strategies differ. Stagehand handles browser control and the associated Playwright code generation and execution.

Stagehand is described as MIT-licensed, open source and usable with a local browser and the developer’s chosen model. Browserbase earns revenue when users choose its hosted browsers. At the time, the framework prioritized reliability over speed and cost optimization. Intensive automation and browser tools for agents were the intended fit; workflows mainly fetching HTML, converting it to Markdown and querying it were less suitable.

A testing disagreement sharpens the distinction. One participant sees natural-language actions as durable expressions of intent that survive page-structure changes. The response is that some tests should fail when structure changes unexpectedly. Automatically adapting could conceal the change a test is meant to detect. Reported Stagehand testing use is closer to usability testing: can the task still be accomplished?

The discussion of Operator separates visual reasoning from action targeting. The Browserbase speaker welcomes models that reason over screenshots and produce steps, while preferring actions anchored to actual page elements over mouse coordinates. That reliability preference is experience-based, without a comparative benchmark. Direct hover support remains unresolved.

Open Operator puts the pieces together

Open Operator is Browserbase’s open-source reference implementation inspired by Operator. It shows developers how to assemble an application from available models and infrastructure; Browserbase was not yet pursuing an end-user product strategy with it.

Its agent loop follows a simple sequence: 1. Break a high-level goal into steps. 2. Feed a screenshot and the current step to an LLM to generate an action. 3. Execute the action through Stagehand. An embedded live view displays the running browser. The implementation described uses no dedicated computer-use model: planning, browser execution and the user interface are separate components.

Expectations about an Operator API differ. One speaker is unsure whether OpenAI will release one; another imagines reliable API-driven browsers booking restaurants in the background on roughly a five-year horizon, while acknowledging that current reliability falls far short. The participants place this kind of workflow automation in the robotic process automation category alongside UiPath.

Use a browser when the workload needs one

Browserbase reports that most of its workload is browser automation, correcting a host’s assumption that scraping dominates. The service is relatively expensive for scraping, so the recommended data-collection architecture is a waterfall: 1. Try a direct curl request. 2. If that fails, try a scraping-specific API such as ScrapingBee. 3. Escalate to Browserbase to load the page and execute its JavaScript. The real browser handles pages that need JavaScript rendering; it is not a measured guarantee of success for every request.

The customer examples also show useful automation without AI. One reported workflow lets people receiving food assistance photograph receipts, submits them for eligible rebates and deposits the proceeds into their accounts. It uses maintained, hard-coded scripts. Lighthouse, described as a customer working on O-1 visas, illustrates another opportunity to remove tedious form-filling from people’s lives.

Search APIs, extraction services, browsers, virtual machines and code-execution environments offer different interfaces for agents. Browserbase’s founder expects higher-level platforms to bundle these tools, while arguing that browser complexity warrants dedicated infrastructure. Many early computer-use tasks he observed primarily controlled a browser, making a full graphical operating system unnecessary for those tasks.

The founder estimates that efficiently orchestrated browsers can provide roughly 90% of the functionality at 10% of the cost of a full operating system, without defining the workload or cost methodology. There are concrete exclusions: Browserbase does not support legacy electronic health record systems requiring Internet Explorer and Windows. Those leave room for operating-system-specific infrastructure, such as the Windows environments described in the discussion of pig.dev.

Software using software changes the interface

The founder’s broader thesis is software using software on a person’s behalf. His proposed accounting workflow begins with a button in a business application. Behind it, software opens Gmail, finds a relevant message and uploads a receipt. APIs and browser interaction could both participate.

That changes the interface as well as the backend. The founder reports customers building chat interfaces, human-in-the-loop flows and asynchronous interactions that accommodate slower AI operations. Best practices remain unsettled. A participant challenges the broader thesis as too general to be falsifiable; the founder responds by predicting that Browserbase will become a billion-dollar company and proposing a check-in in five years.

Team ownership and the limits of automation

The founder argues that solo founding can accelerate decisions by removing a separate co-founder alignment step before aligning the company. For developer tools, someone who can build the product, explain it and talk with customers may not need a separate business co-founder. The conditions are demanding: recruit, establish clear principles, hire quickly and assemble a capable team.

Team ownership makes that model work. Employees shape Browserbase’s website and day-to-day product decisions. The described office rhythm is Monday through Friday, with the first meeting at 10 a.m. and departures around 5–6 p.m. Those hours do not encompass all work: the speaker also expects some work at home and frames weekends as opportunities for projects outside the roadmap.

Former founders and chief technology officers are described as strong early hires who can take ownership of clear execution opportunities. Recruiting remains deliberately personal, through referrals and targeted messages to people doing interesting work. The preference is to contact a creator after discovering their work, rather than automate mass outreach to infrastructure specialists.

Building in public and a Monday running club complement the in-person culture. The team spans early-career employees and people with decades of experience. The founder treats office attendance as an explicit commitment that helps select for alignment, while suggesting that other teams could choose different shared commitments.

A closing business idea returns to web-accessible information: analyze underused recordings of real-world conversations and turn discoveries into decisions. The hypothetical example is monitoring town-hall recordings for approval of a new Walmart, then buying nearby property in anticipation of appreciation. It is a proposed strategy, with no implementation or investment return reported.

The final anecdote returns to presentation. A Stagehand promotional video used people wearing boxes on their heads as a practical effect, repeated over roughly five takes. The props were worn, not held—a small correction that reveals the human work behind the launch.