Read more about Browserbase - a web browser for your AI - the company, product, features, and news on the Browserbase blog

Browserbase Blog: Automate the web

The Browser Blog

Paul Klein

>Try our new product, [Director.ai](https://director.ai) today

In this hyper-fast world of AI, in order to compete you have to keep up. Even since starting Browserbase 16 months ago, I’ve seen the promises of AI turn into production-ready reality. 

We're proud to be part of this transformation, building the infrastructure that makes web automation accessible to everyone. What started with a thesis that AI agents would require great browser infrastructure, has turned into billion dollar companies using Browserbase to deliver better outcomes for their customers.

## Building on a foundation of primitives

The most transformative technology companies (Twilio, Stripe, Vercel) all share something in common: they're primitives. They provide the fundamental building blocks that enable developers to create powerful applications.

Browser infrastructure represents the next critical primitive. It's the foundation that will change how people interact with and automate the web, empowering developers to build software that fundamentally transforms online work.

## The opportunity ahead

Think about how often we interact with a web browser: buying products, sending messages, deploying code. Now consider all the routine online tasks, from sending emails to booking travel, that consume our time every single day.

The future of browsing is selective automation. Humans will still do the joyful, discovery-driven tasks. But repetitive, time-consuming work should be done by software. That’s what we’re building for.

This vision where AI handles the boring parts while humans focus on what matters, represents a massive business opportunity. If Browserbase can become the rails of this new era, we'll be enabling an entirely new category of applications.

And yes, maybe developers are inherently lazy, we build tools to avoid repetitive work. Browserbase is the ultimate expression of that philosophy.

## Expanding our platform

Along with our Series B announcement and lots of small product improvements, we're announcing three main platform upgrades:

1. [**Director.ai**](http://director.ai/): Browserbase has always been built for developers, and we plan to always help developers automate the web, but in this era of AI, everyone can be a developer. And that's why we're launching Director. Director is here to let anyone automate the web, generate Stagehand scripts and deploy them on Browserbase. It's empowering. And it's transformational for infrastructure companies like us, which traditionally only sold to developers, but now we can sell or support everybody. I think that's monumental.
2. **Stagehand for Python**: We're now working with two of the most popular programming languages, Python and Node.js. And I'm very excited for that. The Python version also comes with enhanced observability features built into the Browserbase dashboard, including session recordings, token usage tracking, and comprehensive logging.
3. **We're lowering our prices**: We've been hard at work improving our infrastructure to continue to offer better pricing and value. We hope to make automation a more accessible tool for all builders. Here are the key changes, but you can see all the details here. 
    - **~~Hobby~~ Developer plan**: 50% price reduction to get started, from $39 to $20/month for 100 browser hours and 1 GB of proxies.
    - **More concurrent browsers**: From 3 to 25 on the Developer plan & doubled concurrency from 25 to 50 browsers on the Startup plan.
    - **New feature**: Variable-size browsers for scale customers, choose from our pre-configured small, medium, or large instances.


 ## Series B & beyond

The product release coincides with a $40 million Series B financing round led by Notable Capital, with participation from existing investors CRV and Kleiner Perkins. This new funding marks our commitment to the long haul. Our team, investors, and most importantly, our customers share a vision of a future where people operate with unprecedented leverage through intelligent automation.

The journey ahead is substantial. Browser infrastructure still needs deep innovation—in the browser technology itself, the surrounding infrastructure, and all the supplemental features required to build powerful applications on this foundation.

The market opportunity attracts competition, which we welcome. In markets this large, innovation benefits everyone, pushing the entire ecosystem forward and delivering better solutions for customers.

Looking ahead to the next year at Browserbase, our mission remains clear: help everyone automate the web. We're building the best browser infrastructure platform, the most powerful framework, and the most accessible application to make that vision reality.

We can't wait to see what everyone builds.

We're excited to announce our Series B funding, major platform updates, and our plans for building the primitive infrastructure that will enable AI to automate the mundane work we do online every day.

Building the future of web automation

Harsehaj Dhami

**This week we fixed the worst part of Browserbase.**

I’m not clickbaiting you either. For a long time, session replay was the weakest feature in our product. People tried it, got confused or frustrated, and stopped trusting it. 

The irony is that we should have known better.

Recording what happens on a screen and showing it back to you accurately is [not a new problem for many of us on the team](https://www.mux.com/blog/stream-club-is-joining-mux). But at Browserbase, we deliberately tried something different. Instead of recording pixels, we used a library called [rrweb](https://github.com/rrweb-io/rrweb) to capture DOM mutations (HTML, CSS, and user events) and replay them later.

On paper, this looked elegant. It was cheaper to store and it avoided video encoding. It felt more *“web-native.”*

In reality, it constantly broke.

Websites don’t agree on how to represent HTML and CSS. Nested iframes, shadow DOM, canvas elements, and video players all push DOM-based replay past its limits. The replays would be incomplete, incorrect, or subtly wrong. Worse, they often **looked** correct at first glance while lying about what **actually** happened.

At some point, our conclusion became unavoidable: the easiest and most reliable way to show what happened in a browser is to **just record what was on the screen.**

So we’ve rebuilt exactly that.

This post explains how we rebuilt session recordings from scratch, why we made the architectural choices we did, and how we turned what used to be our weakest feature into something we’re confident putting in front of the most demanding users.

## Why DOM reconstruction fails in the real world

rrweb works by observing DOM mutations, serializing them as events, and replaying those events later to reconstruct page state. The idea is clever. In a controlled environment, it can even be more *semantically* correct than video. You’re replaying intent, not pixels.

The problem is that the web is not a controlled environment. 🤷‍♀️

Nested iframes break this model almost immediately. An iframe is a document boundary. Nest them deeply enough (which real applications do) and you end up with parts of the page that the recorder can’t see, can’t reason about, or can’t reliably replay. We saw sessions where large sections of the page simply didn’t render during replay.

Canvas, WebGL, video elements, shadow DOM - anything that isn’t *“normal”* HTML becomes either flaky or invisible.

![](https://cdn.sanity.io/images/v773ixxh/staging/1da388c7258d4c6b7fd82e3f0a241e6edbb3bc1d-2386x824.png?)

Even when replay **does** work, it can lie in subtler ways. 

Replay a session days later and you might see **today’s** data instead of what was on screen at the time. A weather widget updates, the clock advances, or perhaps an API response changes. rrweb faithfully replays DOM instructions, but the environment has moved on.

That mismatch destroys trust. As developers, we don’t look at session replays for vibes. We look for causality.

At some point, our conclusion became unavoidable: the easiest and most reliable way to show what happened in a browser is to just *record what was on the screen.*

## Record the screen, not the theory of the screen

Our new system records what the browser actually renders.

At the core is a [Chrome DevTools Protocol (CDP)](https://chromedevtools.github.io/devtools-protocol/) screencast that captures screenshots of the browser viewport. Conceptually, it’s the simplest possible thing: take a picture of the screen whenever it meaningfully changes.

Not at a fixed frame rate, and not 60fps for the sake of it. If nothing changes for ten seconds, we capture nothing. If the page is animating, we capture more.

Each frame is timestamped with sub-second precision.

We deliberately capture frames as PNG, not JPEG.

JPEG compression is lossy and CPU-intensive, so the video compression is worse. We want the browser doing as little work as possible so it can focus on the customer’s automation, not our observability pipeline. PNGs are larger, but they’re fast to produce and lossless. We stream them off the browser immediately. Nothing resembling video encoding runs anywhere near the browser.

## Asynchronous encoding and constant-time recordings

Now, what we end up with is a stream of timestamped PNGs per tab.

Turning that into video is computationally expensive, so we do it asynchronously as frames land in object storage. Every ten seconds of session time, the browser emits a message indicating a segment boundary.

Encoder workers consume those messages, pull the frames, and **independently** encode a ten-second HLS fMP4 segment using H.264.

This gives us a non-obvious property: encoding time is independent of session length. A six-minute session and a six-hour session take roughly the same wall-clock time to become playable, assuming enough workers, because all segments can be encoded in parallel.

![](https://cdn.sanity.io/images/v773ixxh/staging/4a09b4f550655ba98c34343f8a7da5a31159904f-5162x2870.png?)

This is also why we never used WebRTC. Anything that compresses video in the browser steals CPU from the workload. Hard pass on that. 😬

## Binary surgery on fMP4 segments

But, parallel encoding introduces a timing problem. ffmpeg encodes every fMP4 segment as if it starts at time zero. There is no flag, filter, or muxer option that fixes this for HLS.

So we patch the files!

After encoding, we open each segment and overwrite the timing fields directly (`earliest_presentation_time` and `base_media_decode_time`) with the correct offset derived from the segment index and timescale. Once patched, the segments stitch together seamlessly.

It’s byte-level surgery. It’s blunt, and she’s perfect. 🤌

![](https://cdn.sanity.io/images/v773ixxh/staging/421a00eb1650fa029b7409196db6d2a9d8e236db-1722x1420.png?)

## HLS as an delivery primitive

We deliver recordings using HLS.

HLS gives us chunked delivery, instant seeking, and CDN-friendly caching. Players request a playlist, then pull segments just ahead of the playhead.

This is an observability problem, and HLS turns out to be a pretty great observability transport.

## Multi-tab recordings without flattening reality

We record up to ten tabs simultaneously. 

Each tab is captured and encoded as its own stream, but all streams share the same global timeline. This is represented using an HLS multi-variant playlist. Normally variants mean bitrates, but we repurpose them to mean tabs.

Switching tabs in the recordings UI is switching variants, without changing the timestamp.

If something happened in a background tab while you were interacting with another one, you can actually see it. It’s not a guess. 

## Secure playback, segment by segment

Session recordings are sensitive. 

The playlists are generated dynamically. Every segment URL is signed with a short-lived token, and validation happens at the CDN edge. The tokens expire, old links die, and authorization is enforced per segment. 

The player doesn’t know. It just plays video.

## Cost, scale, and just-in-time encoding

Encoding video is expensive. Encoding video no one watches breaks the bank.

We encode everything, but only roughly 8% of sessions are ever replayed.

The new architecture supports just-in-time encoding: eagerly encode the first ~30 seconds so playback starts instantly, then encode the rest only if someone actually watches.

Because encoding is parallel and constant-time, even a six-hour session can be made watchable quickly when requested. The tradeoff is brief buffering when jumping to unseen regions, which we’ve deemed acceptable for debugging.

This is how we get reliability and reasonable economics at scale.

## What this unlocks going forward

Once we stop pretending a replay is a DOM simulation and treat it as a real recording, a lot of problems disappear.

The timing becomes deterministic, multi-tab behaviour is understandable, exporting a recording seems trivial, and retention turns into a storage problem instead of a data-modelling problem.

It also simplifies the browser itself. We run less code inside customer sessions than before. There’s no mutation observers injected into pages, or recordings-specific logic racing application code. **The browser does one thing: render pages. We observe the result.**

Session recordings is rolling out now for Browserbase customers.

**If you tried our old session replays and hated them, this session recordings rebuild is for you.**

At some point, our conclusion became unavoidable: the easiest and most reliable way to show what happened in a browser is to just record what was on the screen.

This week we fixed the worst part of Browserbase

Nick Sweeting

Browser automation shouldn’t depend on the language or driver you happen to use. Today, Stagehand becomes canonical: one implementation that works everywhere.

## Canonical Stagehand: one implementation, every language

Browser automation with [**Stagehand**](https://www.stagehand.dev/) unlocks the ability to do complex open-ended tasks without having to write a lot of code.

Stagehand allows developers to compose powerful, resilient automations with a few simple words instead of having to hand-code long, brittle scripts using xpaths and x/y coordinates:

```python
observe('find the button to sort the price column in ascending order')

act(’click on the “add to cart” button in the upper right’)

extract(’extract company names of the top 8 results shown on this page’)

agent('fill out this complex multi-page workflow')

```

However, developers in languages like Rust, PHP, C#, Kotlin have been left out of this new revolution in browser automation, and have been stuck with the early 2000’s approach of hand-coding selectors.

We’re pleased to announce that we’re changing that today with the new multi-lingual Stagehand SDK, bringing a unified first-class browser automation interface across a wide range of languages:

- Typescript (our existing stagehand library)
- Python (upgraded today to v3 support)
- Golang (new)
- Java (new)
- Ruby (new)
- Rust (new, beta)
- Php (new, alpha)
- C# (new, alpha)
- Kotlin (new, alpha)
- REST API (new), for direct use from Claude Code/MCPs/curl/n8n/etc.

With the release of these new SDKs, we’re also proud to announce two new headlining features.

## NEW: Bring-your-own-browser-driver support

Typically, AI browser automation libraries are highly opinionated and only work with a specific driver like Playwright or Puppeteer, or they force you to use their own. Our new API is actually browser-driver agnostic and work with all of them! 

That means you can use your browser driver library of choice to set up the browser, perform custom logic in and around AI-powered logic, load cookies, and more, and it won’t interfere with stagehand’s AI automation. We also don’t depend on any driver internally, so you won’t have the stealth impact of loading Playwright or Puppeteer, which often lead to excessive captchas and challenge pages even when configured by experts.
	
	This means you can use any of these:

- stagehand + chromiumoxide in rust
- stagehand + go-rod or chromedp in golang
- stagehand + playwright, pydoll, pyppeteer, in python
- stagehand + selenium in java
or any other combination you can think of!

![](https://cdn.sanity.io/images/v773ixxh/staging/00cc42bf8b9cfc61c628a13031422fbe1bf4c9fe-2036x1080.gif)

## NEW: Parallel multi-browser support!

The second headlining feature that we’re excited about is the ability to scale scripts and control dozens of browsers at once with only a single extra parameter: `session_id`. 


![](https://cdn.sanity.io/images/v773ixxh/staging/5dae41e7abaf0845dbb8ecdbfdc450f8cd8a0c89-1280x832.png)


Simply do `stagehand.sessions.start(...)` to launch as many browsers as you need in parallel, then pass  `act(session_id, ...)`, `extract(session_id, ...)`, etc. to subsequent calls to control each specific session.

Here are some ideas of things you can build with this new ability:
- Starting one browser to do a search, then the top 10 results in a separate browsers to scrape at 10x speed!
- Having one browser filling out a form, and have 5 browsers collecting the data to fill in in parallel
- Logging in with 10 different accounts to the same site to test load or collaboration features

… just to name a few use cases.

This should make it significantly less cumbersome to manage launching, authenticating, proxying, and driving multiple browsers in parallel in our cloud.


## A concrete example
Imagine you’re extending a PHP wordpress site with a plugin that needs to extract structured data from a page after a complex login flow.

Before, your options were ugly:

- run a Node service alongside your app,
- call out over HTTP,
- pass state back and forth,
- debug failures across language boundaries.
- handling chrome launching, cleanup, and task queueing manually

With Stagehand v3, the PHP SDK can drive a browser directly without needing and entire additional backend service to manage your browsers.

With a simple call like `observe('find the phone number on the bottom right')` Stagehand reasons about the page, performs the extraction, and returns structured data.

We’re excited to see what people can build from ecosystems that were previously deprived of this ability. With Kotlin you can even build native Android apps that control browsers directly, a first in the ecosystem! We hope to announce Swift support later this year as well.

## Providing a high quality, consistent developer experience across multiple languages is a tough problem.

It’s hard to implement well-designed APIs consistently across a range of languages. Every language has unique conventions for basic things like parameter names, union types, error handling, async, etc.

Our new multi-language support is powered by Stainless†, which allowed us to implement a client-server RPC interface within our library, then generate a range of native SDK clients against that interface. Stainless powers other high-quality SDKs you know and love from Anthropic, OpenAI, Google, and Cloudlfare, and their platform made it easy to manage this process end-to-end.

Traditionally SDK’s are used to connect to a remote cloud service, and our library *does* use your BROWSERBASE_API_KEY to launch browsers in our stealth cloud by default, but we took it one step further and implemented a system to allow you to control local browsers using the same API.

This presented a unique engineering challenge: the core battle-tested part of our library is written in Typescript, and porting many thousands of lines of complex logic across all languages while maintaining perfect feature parity is nearly impossible, there would inevitably be drift.

So we followed in the footsteps of Playwright, which solves this challenge by shipping a high-performance Node SEA binary powering the core driver, and then wrapping it in per-language client APIs that automagically launch the inner binary when needed, without any config required.

Don’t worry! The entire package is still open source, you can find the source for the node package in our main repo `browserbase/stagehand`, and the full source code for the client layers in each language repo like `browserbase/stagehand-go`, `browserbase/stagehand-ruby`, etc.

<small>† Note: excluding the Rust SDK, which is not powered by Stainless yet.</small>

## What's launching today

Stagehand v3 launches with support for:

**Python, Java, Ruby, Rust, and Go**

All with the same core capabilities. The same behavior. The same guarantees.

We also have ALPHA SDKs available for early testing: 

PHP, C# .NET, Kotlin 

Our existing Python users can use [this migration guide](https://docs.stagehand.dev/v3/migrations/python) to see how to upgrade to the latest SDK.

Browser automation has quietly become critical infrastructure. It powers testing, onboarding, data pipelines, QA, and entire product features. But until now, it’s been locked to a small corner of the programming world.

We think that’s backwards.

Stagehand v3 is our attempt to make browser automation **portable:** across browser drivers, operating systems, languages, and ecosystems. The goal isn’t to win one community. It’s to stop forcing teams to choose between their language and their capabilities.

One automation framework.

Every language.

**Get started here**: [https://docs.stagehand.dev](https://docs.stagehand.dev/)

Canonical Stagehand introduces one browser automation API that works across every language, any browser driver, and supports parallel multi-browser workflows.

The best browser automation framework, in every language

Anyone can automate a browser. Doing it reliably and at scale, however, can be incredibly painful. Let me dig into this gap, and what changes for the better when you stop hosting browsers yourself. 
## Browser automation still sucks, at scale
In theory, browser automation seems simple enough: spin up Chromium, point it at a page, automate a few page interactions like scrolling or clicking buttons, and then collect the results. Easy, *right*?

Wrong. If we’re being honest, the first time I get a script working locally, it **feels** simple. This is exactly why the issue of scaling web automation is so demoralizing. I ship it, wire it into CI, and relish in the dopamine hit of a week of green runs. Then one random morning, unaware of my impending doom, I’ll open my laptop to a wall of red, despite zero code changes. 

My logic didn’t break, but Chromium starts going haywire once you move it into containers and shared cloud runners. Well, of course it does - your laptop has a full desktop stack, stable fonts, a GPU, predictable RAM for your one job, and OS behaviours you know like the back of your hand. 

Then you play a completely different hand: [CI changes the OS](https://mindfulchase.com/explore/troubleshooting-tips/testing-frameworks/troubleshooting-browser%2C-test%2C-and-ci-cd-issues-in-puppeteer.html), the resource envelope, and the Chromium binary in subtle ways, and Chromium is sensitive enough that those **subtleties turn into [flaky automation](https://github.com/microsoft/playwright/issues/28705).** When people say *“automation is brittle,”* this is what they mean when you end up debugging the runtime instead of the script. It’s frustrating because you did everything “*right*” and the environment still changed underneath you. 

### Why things start falling apart

Chromium is architected as a [multi-process system](https://www.chromium.org/developers/design-documents/multi-process-architecture/). Even a single tab fans out into browser, renderer, GPU, and network processes, and [cross-origin iframes](https://developer.chrome.com/docs/chromium/renderingng-architecture) often land in their own renderers too. That design is great for security and crash isolation, but in automation, it means **one** browser is really a small swarm of OS processes competing for resources. Modern pages amplify this because they’re iframe-dense by default (ex., ads, analytics, embeds, auth widgets), so a seemingly simple navigation can secretly become dozens of renderer processes doing layout, JS, and painting in parallel. On a high-RAM dev laptop, that overhead is basically invisible. In a virtual machine with tight CPU shares and a couple of gigs of RAM, the difference between something working and timing out forever becomes evident.

Scaling hurts because Chromium is [already fighting memory pressure](https://developer.chrome.com/docs/devtools/memory-problems) on normal modern websites with pages constantly allocating big JS heaps and DOM state, and not all of it getting cleaned up. In UI-less ([headless](https://developer.chrome.com/docs/chromium/headless)) automation, you stress those paths harder with rapid navigations, repeated reloads, screenshots, tracing, and long-lived sessions. So when you run lots of sessions or long-lived automations in parallel, that baseline memory churn turns into real RAM growth and instability. In fact, Chromium runs have been [reported](https://issues.chromium.org/issues/422449026) to steadily eat RAM or [fail to release it](https://issues.chromium.org/issues/327583144) until the process is killed. In one [experiment](https://datawookie.dev/blog/2025/06/playwright-browser-footprint/), a single Playwright/Chromium instance peaked around [~700MB-1GB](https://datawookie.dev/blog/2025/06/playwright-browser-footprint/), which is fine **once**, but **terrifying at 50x parallelism.**

![](https://cdn.sanity.io/images/v773ixxh/staging/d2e6ddae97416b0b2a3bdc4764d0a2baad4151b1-1344x576.png)
Total memory consumption via Chromium ([Source](https://datawookie.dev/blog/2025/06/playwright-browser-footprint))

Going from a few browsers to dozens doesn’t necessarily introduce a new class of bugs since it’s just multiplying the same CPU, memory, and process overhead **until the VM hits its limits**. At that point, the system starts degrading in predictable ways when the network calls slow or fail, your automation waits drift, and eventually the OS kills a Chromium renderer when memory runs out.

This is the moment where race conditions show up *“for no reason.”* Not because the web suddenly got nondeterministic, but because your timing assumptions were made on unconstrained hardware, and now the browser is fighting for oxygen.

**TL;DR:** the automation logic can be taken care of by a skilled developer and [existing automation frameworks](https://www.stagehand.dev/). The reason browser automation still sucks at scale is that you’re trying to run a complex, resource-hungry, multi-process rendering engine in environments it wasn’t designed to live in, and then asking it to behave like a deterministic function.

**Try this interactive browser infra demo:**
<iframe src="https://browser-meltdown.vercel.app/" title="Browser meltdown" width="100%" height="400" allowfullscreen loading="lazy"></iframe>


![](https://cdn.sanity.io/images/v773ixxh/staging/4467fa65b8e1c9bcaa373417a0228e72ea8e19a1-717x330.png)

**We’re asking for a little too much.** So, we end up doing **a lot.**

You end up building a second system whose job is just to keep the first one alive with custom Docker images, pinned Chromium builds, cleanup scripts, CI hacks, [*“known good”*](https://peter.sh/experiments/chromium-command-line-switches/) flags, Slack threads full of *“why is this failing now?”* and defeatedly accepting a certain amount of flake as the cost of doing business. 

After you do that long enough, you (hopefully) start asking a very pragmatic question that has nothing to do with scraping or testing and everything to do with ownership: *why the hell am I running browsers at all?*

Here’s an idea: **just stop managing them.**

## What are serverless browsers, really?

If running Chromium yourself keeps turning into an infrastructure project, the obvious question is what it would look like to keep the automation and outsource the runtime.

**I present to you: serverless browsers.** 

It’s the same Chromium engine, the same DevTools protocol, the same Playwright or [Stagehand](https://www.stagehand.dev/) code you already write, but the browser lives in someone else’s cloud instead of on your laptop or inside your Docker images. Instead of babysitting that environment, you ask an API for a fresh, isolated browser hosted in the cloud, connect to it over CDP, run your script, and then throw the whole thing away.

It’s browser infrastructure as a service. I get clean, ephemeral, single-use environments that spin up fast, behave consistently, and disappear when I’m done. There are no machines to provision, no containers to update, no Chromium binaries to pin or patch, and no browser-state to clean up. Instead of launching a local browser, you’re dialing into a preconfigured Chromium instance whose entire job is to execute your automation once and then vanish.

It feels surprisingly natural in practice because the automation scripts don’t change. You still write:

**Stagehand script:**
```TypeScript 
import { z } from "zod/v3";
import { Stagehand } from "@browserbasehq/stagehand";

(async () => {
  // Initialize Stagehand
  const stagehand = new Stagehand({
    env: "BROWSERBASE",
    apiKey: process.env.BROWSERBASE_API_KEY,
    projectId: process.env.BROWSERBASE_PROJECT_ID!,
    model: "openai/gpt-4o",
    // Your OPENAI_API_KEY is automatically read from your .env
  });

  await stagehand.init();
  const page = stagehand.context.pages()[0];

  await page.goto("https://docs.browserbase.com");

  // Preview an action before taking it
  const suggestions = await stagehand.observe("click 'Stagehand'");

  // Take a suggested action
  console.log(suggestions[0]);
  await stagehand.act(suggestions[0]);

  // Read the NPM install command
  const { npmInstallCommand } = await stagehand.extract(
    "Extract the NPM install command",
    z.object({
      npmInstallCommand: z.string(),
    })
  );

  console.log(npmInstallCommand);
  await stagehand.close();
})().catch((error) => console.error(error.message));
```

**Playwright script:**
```TypeScript
// Attach to an existing Chromium instance via the Chrome DevTools Protocol
// (this can be local, remote, or serverless)
const browser = await playwright.chromium.connectOverCDP(
  "http://localhost:9222"
);

// Reuse the default browser context created by the remote instance
const defaultContext = browser.contexts()[0];

// Grab an existing page (or create one if needed)
const page = defaultContext.pages()[0];

// From here on, this behaves exactly like a locally launched browser
```

The automation code doesn’t really change, but the execution model does. Instead of spawning a local Chromium process and inheriting whatever your host environment happens to look like, you request a remote Chromium instance and attach to it over CDP the same way Playwright or [Stagehand](https://www.stagehand.dev/) already does. The browser is provisioned per task, isolated to that task, and torn down when the session ends. In other words, the things you’ve been encoding in Dockerfiles, shell scripts, and CI configuration move out of your deployment surface and into the platform boundary.

That shift matters because most of the failure modes you fight at scale are runtime failures, not automation failures. When you host browsers yourself, you end up solving two intertwined problems at once: both writing correct automation and keeping a fleet of Chromium processes stable under load. With a serverless model, the second problem is externalized. Your code’s unit of work is mapped from one task → one fresh browser, which is a cleaner abstraction for parallel systems than X number of tasks sharing Y number of long-lived browsers on some machine.

*Okay … so isn’t that just a cloud browser?* Not quite. A cloud browser is a browser running somewhere else. A serverless browser is a **browser you don’t run at all.**

Let’s talk about what changes once you drop that responsibility.

## What actually happens when managing browsers is no longer your problem

Once new browser instances are spun up and torn down per run, state becomes explicit instead of accidental. Every task starts from a clean profile with no previous cookies, storage, or service worker residue. That alone removes a big class of heisenbugs where a test passes or fails depending on what ran earlier. When something does fail, you can usually attribute it to the script or the target site rather than to leftover browser state.

Concurrency also becomes a queueing problem instead of a hardware-tuning problem. In other words, you’re not deciding how many browsers a specific VM can tolerate before Chrome starts thrashing. You’re deciding how many tasks you want to run in parallel, and the platform maps that onto independent browser instances. The practical effect is that your concurrency limit is set by throughput goals and cost, not by whether a particular machine has 3 GB of RAM left.


![](https://cdn.sanity.io/images/v773ixxh/staging/a3e8311ff895914d7d478d567ea524cb43ca278c-840x428.png)
Viewing all concurrent browser sessions in [one dashboard](https://www.browserbase.com/)

Don’t get me wrong, browsers still crash (I fear that’s unavoidable), but a crashed instance won’t jeopardize the rest of your job anymore. If a renderer dies, it takes down that one task’s browser, not a shared pool. Recovery is just a “*new instance, same task”* rather than digging through a hung machine to clean up Chrome’s mess. This makes long-running workflows easier to reason about, since failure becomes per-task and restartable instead of systemic and sticky.

Network configuration moves in the same direction. Instead of engineering routing, proxy rotation, and regional outbound traffic as part of your own infrastructure, you request the network properties you need for a task and treat them like parameters. The browser runs with that outgoing network and isolation, and your automation remains the same.

**Stagehand script:**
``` TypeScript
import { Stagehand } from "@browserbasehq/stagehand";

const stagehand = new Stagehand({
  env: "BROWSERBASE",
  apiKey: process.env.BROWSERBASE_API_KEY,
  projectId: process.env.BROWSERBASE_PROJECT_ID,
  browserbaseSessionCreateParams: {
    proxies: true,
    region: "us-west-2",
    browserSettings: {
      viewport: { width: 1920, height: 1080 },
      blockAds: true,
    },
  },
});

await stagehand.init();
console.log("Session ID:", stagehand.sessionId);
```

Finally, good riddance to Chromium maintenance. You’re no longer tracking Chrome builds against Playwright versions, not adjusting sandbox flags per base image, and not rebuilding Docker layers when a system dependency changes. The browser runtime becomes an external dependency with a stable interface (CDP), and your scripts run against that interface rather than against your own carefully-maintained environment.

## A love letter to serverless browsers

Serverless browsers are compelling less because they’re novel and more because **they align browser automation with the rest of modern compute.** A browser becomes an ephemeral unit of execution: allocate, attach, run, dispose. You still write Playwright or Stagehand exactly the way you already do, but the operational work of keeping Chromium healthy under cloud constraints is no longer mixed with your automation logic. 

Serverless feels obvious in hindsight, but it only becomes the clear solution after someone trudges through the unglamorous work you’ve been putting up with for years. They must take Chromium seriously as production infrastructure, customize it for headless reliability and scale, and then operationalize it as a cloud-native runtime with sane isolation, networking, and lifecycle semantics. 

That’s the part many teams never want to own long-term, because it’s a tax that keeps compounding. At Browserbase, we bet that this tax should live in one place, rather than every company’s CI and Dockerfiles. 

If that resonates, don’t overthink it and start writing automation that scales: `npx create-browser-app.`


A deep dive into why browser automation breaks at scale, how Chromium behaves under cloud constraints, and why serverless browsers change the execution model.

How serverless browsers unlock scalable web automation

Peyton Casper

We’re excited to announce that Browserbase, in partnership with Coinbase, now enables **frictionless agent-to-browser automation**, with **no API keys, no billing setup, and instant USDC settlement**.

As LLMs become the primary way users and developers discover new services, platforms must be legible and usable by agents from the first interaction. Any LLM can now **discover Browserbase through the x402 Bazaar**, understand our pricing, and **pay per browser session**, all programmatically.

This allows agents to spin up a real browser, navigate live websites, interact with UI elements, submit forms, and extract data as **part of an autonomous workflow**, without human approval or credential management.

## Leveraging Coinbase business: accepting USDC via x402 with accounting, tracking, and yield optimization

To receive payment for each session, Browserbase uses Coinbase Business as its settlement layer. This means that every x402 call instantly deposits USDC into our Coinbase account, providing:
* **automatic yield** on idle balances
* **institutional-grade custody**
* **real-time visibility** into usage and revenue
* **no reconciliation work**, no fraud risk, and no credit cards to manage

This setup allows Browserbase to focus on delivering great browser automation rather than managing a billing system.

## Try it out
Developers and agent builders can start experimenting today with the **x402 Endpoint Documentation** [here.](https://docs.browserbase.com/integrations/x402/introduction)

Read the full announcement on Coinbase's Developer Platform [here.](https://www.coinbase.com/developer-platform/discover/launches/browserbase-x402-usdc)

With Browserbase and x402, agents can now use the web the way it actually exists, by navigating real pages, interacting with real interfaces, and paying for compute autonomously.

If you’re building agents, automation systems, or AI-native products that require real browser interaction, this unlocks a new class of workflows that were previously impossible without human setup.


We’re excited to announce that Browserbase, in partnership with Coinbase, now enables frictionless agent-to-browser automation, with no API keys, no billing setup, and instant USDC settlement.

Browserbase enables agentic payments with Coinbase and x402

Kyle Jeong

The very first AI system, a [Neural Network](https://en.wikipedia.org/wiki/Neural_network_(machine_learning)), was not built for language or code. It was not trained on internet-scale data. It was a simple machine created in 1957 by Frank Rosenblatt, called the [Perceptron](http://neuralnetworksanddeeplearning.com/chap1.html), assembled from motors, wires, and a grid of photocells. It learned from crude, low-resolution images projected onto a board of light sensors.

<iframe   data-desktop-height="903px" 
  data-mobile-height="738px" width="100%" src="https://blog-animations.vercel.app/perceptron"></iframe>

It could only learn very simple patterns, yet it introduced a new idea: instead of programming rules directly, we can train a machine by showing it examples.

Neural networks evolved slowly. Minsky and Papert documented the limits of the [Perceptron in 1969](https://mitpress.mit.edu/9780262630221/perceptrons/). Backpropagation revived the field in the 1980s ([Rumelhart et al.](https://www.nature.com/articles/323533a0)). Convolutional nets gained traction in the 1990s (LeCun). Deep learning reached mainstream credibility after [AlexNet in 2012](https://dl.acm.org/doi/10.1145/3065386).

The [Transformer](https://arxiv.org/pdf/1706.03762) architecture (Vaswani et al., 2017) shifted the field's focus from images to sequences, enabling models to process and generate language at scale, which opened the door to general-purpose reasoning systems. 

[Supervised fine-tuning (SFT)](https://huggingface.co/learn/llm-course/en/chapter11/3) emerged as the standard approach: collect labeled data, train the model to predict outputs from inputs. This worked for classification, translation, and eventually language generation. But complex sequential tasks required a different approach. 

[Reinforcement learning](http://incompleteideas.net/book/ebook/node12.html)[^1], which had roots in control theory and animal behavior research from the 1950s, offered a solution. Instead of learning from static demonstrations, agents could learn from trial and error; taking actions, observing outcomes, and optimizing for rewards. [DeepMind's DQN](https://deepmind.google/blog/deep-reinforcement-learning/) playing Atari games (2013) and [AlphaGo](https://deepmind.google/research/alphago/) defeating world champions (2016) demonstrated RL's potential for complex decision-making.

<iframe height="600" width="100%" src="https://ppobunny.vercel.app/"></iframe>

[Credits to Noah Soloman for making this interactive demo of PPO](https://github.com/noahgsolomon/PPO-Bunny)

By the early 2020s, researchers began combining both paradigms: SFT to bootstrap from human demonstrations, then RL to refine behavior through interaction. 

In 2025, multimodal models[^2] like Claude 4.5 Sonnet can take a screenshot as input, parse the layout, understand what is interactive, and return structured actions such as:

```json
"output": [
    {
        "type": "reasoning",
        "id": "rs_67cc...",
        "summary": [
            {
                "type": "summary_text",
                "text": "Clicking on the browser address bar."
            }
        ]
    },
    {
        "type": "computer_call",
        "id": "cu_67cc...",
        "call_id": "call_zw3...",
        "action": {
            "type": "click",
            "button": "left",
            "x": 156,
            "y": 50
        },
        "status": "completed"
    }
]
```

This is no longer simple classification. It is perception, reasoning and action in a single loop.

In other words, the same idea demonstrated in 1957 has become the basis for agents[^3] that can now operate computers. Pixel trained models can interpret websites, identify buttons, understand form fields and decide what to do next. Combined with structured outputs, they can complete digital tasks that used to require a human sitting at a keyboard.

A machine that once recognized simple shapes and curves is now helping build more advanced machines that can use software.


## What are "computer use models"?

Alright so, what exactly is "computer use"?

A **computer use model** (sometimes called a "computer use agent") is a vision language model that is trained to use a computer. It knows to interact with software via the standard user interfaces we humans use: clicks, keystrokes, scrolls, screens, and windows. 

The key point is that the agent does not require programmatic APIs or backend integrations. It uses the *frontends* that already exist, such as web browsers and [GUI](https://en.wikipedia.org/wiki/Graphical_user_interface) applications.

### Why is that important?

Traditional automations such as macros, RPA and custom scripts often requires specially built connectors or brittle scripts. Computer use models promise **general purpose automation** across many apps without custom integrations. Their interface is the one humans already use, and such agents can scale to various tasks and domains out of the box. 

When developing autonomous vehicles, Tesla faced a choice: either rebuild roads with special sensors, markers, and infrastructure designed for robots, or train AI models to navigate the messy, imperfect roads that already exist. Tesla chose the latter, training their models on real-world conditions: faded lane markings, unexpected obstacles, human drivers behaving unpredictably, and roads in every state of repair or disrepair.

>Computer use models follow the same philosophy for the digital world.

Rather than waiting for every website, application, and system to be rebuilt with clean APIs and AI-friendly interfaces, these models learn to navigate the internet and software as it exists today: clicking buttons, filling forms, reading screens, and adapting to inconsistent interfaces, just as humans do. The "roads" are the legacy systems, outdated interfaces, and countless applications that will never be modernized. The AI learns to drive on them anyway.

This opens the door to a new class of AI and software interaction where the human role shifts from direct operation to supervision and orchestration.[^4]


## The two paths: vision-based vs. text-based agents

When you build a system that uses software like a human, there are two fundamental ways for it to perceive and act. One is by "seeing" the literal screen itself (vision). The other is by reading the interface structure ([DOM](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model), [accessibility trees](https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree), or similar). 

Let's dive into both.
## Vision-based models

Vision-based agents treat the interface as images or video frames. They receive screenshots, process them with vision, and output actions/tool calls such as "click at (x, y)", "type this text", "scroll down". The models are trained on a set viewport (ie [1288 x 711](https://github.com/browserbase/stagehand/blob/main/packages/core/lib/v3/agent/OpenAICUAClient.ts#L27) or 1024 x 768) and can identify interact-able objects within a screenshot and find the exact pixel on the screen to interact with.

Since the agent uses the same visual interface as a human does, it can in principle operate any UI in existence: browsers, desktop apps, mobile apps, legacy tools with no API support, and so on. The model mimics how a human operates, and can handle unfamiliar sites or applications that were not in the initial training data. 

But Vision processing is expensive. Interfaces change. Layout shifts, colors change, elements move a bit. The model can misinterpret what is clickable or where something is on screen. The models are also trained for accuracy on a very specific viewport/aspect ratio so any changes and the model effectively breaks. 

Also, a screenshot does not always reveal internal state. For example, whether a form field is valid, or whether a button is disabled. The agent may need repeated observations or trial and error. For many tasks, seeing **everything** is overkill when structure is available. Vision often adds latency and increased token cost compared to textual representations.

### Examples:

[OpenAI's Operator](https://openai.com/index/introducing-operator/) is an example of a "computer use agent". The AI took screenshots and returned mouse and keyboard actions which are [translated to Playwright](https://platform.openai.com/docs/guides/tools-computer-use). It required no specialized integration into the target application, because it worked with what a human user would see. Under the hood their product uses the [computer-use-preview](https://platform.openai.com/docs/models/computer-use-preview) model, which was trained specifically to interact with pixels on the screen.

<iframe height="1025" width="100%" src="https://cua.browserbase.com/"></iframe>

We built an open source implementation of Operator for people to experiment with the model and see how it works. 

Google DeepMind's [Gemini 2.5 Computer Use](https://blog.google/technology/google-deepmind/gemini-computer-use-model/) model works similarly. Screenshots go in, actions (with reasoning traces) come out. This model differs slightly from the one from OpenAI, in that it will return multiple actions at once (assuming future browser state) so the agent harness is able to complete them sequentially, leading to net faster execution of tasks. 

![](https://cdn.sanity.io/images/v773ixxh/staging/a1dd90a3f3b4bedf49c040e163026f4e15edbe6c-1944x1304.png)


There's also frontier research on [SLMs](https://www.ibm.com/think/topics/small-language-models) for Computer-use. [Fara-7B from Microsoft](https://www.microsoft.com/en-us/research/blog/fara-7b-an-efficient-agentic-model-for-computer-use/) is a small but mighty computer use model meant to be deployed and run directly on every Windows 11 machine. The model is a [Qwen2.5-VL](https://huggingface.co/Qwen/Qwen2.5-VL-7B-Instruct) fine tune, trained using SFT with data from an experimental CUA multi-agent synthetic data generation pipeline. The system uses one AI agent to propose diverse web tasks, another multi-agent system ([Magentic-One](https://www.microsoft.com/en-us/research/articles/magentic-one-a-generalist-multi-agent-system-for-solving-complex-tasks/)) to attempt solving those tasks and generate step-by-step demonstrations, and finally three verifier agents to check if the solutions were successful, creating a large synthetic training dataset without needing human annotators. 

This yielded SOTA performance within the model's size class, outperforming [UI-Tars-1.5](https://huggingface.co/ByteDance-Seed/UI-TARS-1.5-7B) and OpenAI's [computer-use-preview](https://platform.openai.com/docs/models/computer-use-preview) model on the [WebVoyager](https://huggingface.co/papers/2401.13919) benchmark. 


![](https://cdn.sanity.io/images/v773ixxh/staging/dd9e0b80978ed7c29e9e0f9e4c5a36958a46f9cb-1848x1394.png)


Here's a quick start to get you up and running and deploying Computer use models in production. 

```bash
# Create a sample script that runs a Computer Use Model with Stagehand
npx create-browser-app@latest -t gemini-cua
```

Then running the agent itself in code is simple. 

```typescript
const agent = stagehand.agent({
  cua: true,
  model: {
    modelName: "google/gemini-2.5-computer-use-preview-10-2025",
    apiKey: process.env.GOOGLE_API_KEY
  },
  systemPrompt: "You are a helpful assistant that can use a web browser."
});

const result = await agent.execute({
  instruction: "Tell me what Stagehand.dev does."
});
```

## Text/DOM Based Agents

Instead of looking at pixels, a text-based agent accesses the internal representation of the UI: the HTML DOM tree, accessibility snapshots, roles, labels, attributes, event handlers, and so on. It reasons over that structure ("there is a button labeled 'Submit' under a `<form>` element") and then invokes automation primitives to take action in a webpage.

For example, [Stagehand](https://www.stagehand.dev/) (our open source web automation framework), takes a snapshot of the DOM and accessibility tree, parses it using an LLM, and then decides what actions to take based on the webpage structure. 

The following is an interactive demo showing the difference between the literal DOM of a webpage and the parsed version that is fed to the LLM in Stagehand:

<iframe height="600" width="100%" src="https://stagehand-vision.vercel.app/"></iframe>

If you try the example on the [Browserbase landing page](https://www.browserbase.com/), you'll see the raw HTML is a whopping 27k tokens[^5], while our truncated DOM/A11y tree is only 6k. Research shows LLMs are able to make better decisions when their [context isn't clogged](https://research.trychroma.com/context-rot) with unnecessary information, so Stagehand's custom snapshot is key to better-performing agents.  

Structured data typically provides fewer ambiguities. You can target a specific element instead of guessing a position on screen, improving reliability and speed. Instead of sending full images to the model, you can send a compact version of the DOM subtree, reducing tokens, latency and cost. 

And the more you look at how the web is actually built, the more natural this form factor becomes. Web automation is often inherently structured: Forms, tables, lists, search results and dashboards are all built from elements with attributes and are a natural fit for text-based Agents.

While text-based agents seem efficient, they have their faults. The model may know there exists a `<button id="buy">Buy</button>` but not whether it is visible, covered by a modal, off-screen, or partially obscured. Visual context can still matter in a lot of tasks. 


To try a text-based agent, we'll use the built in [Stagehand Agent](https://docs.stagehand.dev/v3/basics/agent), which uses a driving model with access to 3 tools/primitives: act, observe, and extract to complete tasks on the web.

The code is very similar to the computer use agents, but instead of specifying a computer-use model, we leave that parameter blank. 

```typescript
// we don't specify CUA: true here to use the built-in agent
const agent = stagehand.agent({
  systemPrompt: "You are a helpful assistant that can use a web browser."
});

const result = await agent.execute({
  instruction: "Tell me what Stagehand.dev does."
});
```

This agent uses a purely text based approach (no vision). Given the DOM/A11y ([Accessibility](https://developer.mozilla.org/en-US/docs/Glossary/Accessibility_tree)) Tree Hybrid we mentioned earlier, the agent parses it, and decides what Stagehand primitives to use to complete the task. [Act](https://docs.stagehand.dev/v3/basics/act) completes actions on the page, [observe](https://docs.stagehand.dev/v3/basics/observe) finds and returns all possible actions on the page (clickable buttons, fillable textboxes, etc), and [extract](https://docs.stagehand.dev/v3/basics/extract) gives you customizable structured output of the page data. 


## Cool, now how does this change my life?

Now that we've covered *how* they work, let us talk about *why* they matter.

For decades, automation has required precise documentation of what needs to be automated. Think cron jobs, macros, [RPA bots](https://www.uipath.com/rpa/robotic-process-automation) or hand coded scripts. Or it has meant calling various custom APIs.

Computer use models enable something different: **general purpose autonomy**. An AI can operate across multiple applications, across domains, and can adapt to new tasks and interfaces. You specify what you want, and the agent uses a computer to get there. That is much larger than "run this script every night" or "call this API with these parameters".

Many valuable tasks remain manual because there is no clean API or no engineering time to build custom integration. A computer use agent can bridge that gap. If a human can do the task via the UI, the agent should be able to as well. If a computer-use agent can fill forms, collate data from ten websites, schedule meetings and log your expense reports, you spend your time interpreting results, designing systems, building relationships and solving non routine problems.

A study done by [McKinsey](https://www.mckinsey.com/mgi/our-research/a-new-future-of-work-the-race-to-deploy-ai-and-raise-skills-in-europe-and-beyond) shows AI could automate activities that take up 60-70% of current work hours, especially in knowledge-based roles. This doesn't mean those jobs suddenly vanish. Instead the repetitive parts shrink and the human attention budget can now move to creative and strategic work.

With agents, software starts to look more like a service that works for you. The control flow becomes:

<iframe height="500" width="100%" src="https://blog-animations.vercel.app/agent-flow"></iframe>

> Human describes an outcome → Agent interprets this and plans actions → Agent operates the software stack

Instead of learning the ins and outs of every dashboard and admin panel, you spend effort on describing goals and constraints while the agent handles the operation. This is analogous to the move from [command-line interfaces](https://en.wikipedia.org/wiki/Command-line_interface) to graphical ones. GUIs reduced the mental overhead of remembering long commands. Agents will reduce the overhead of endless clicking and context switching.


## The future of work

Instead of humans bending their workflows around software, software, embodied as agents, begins to bend itself around human goals. The tradeoffs between vision-based and DOM-based approaches are real. The infrastructure is still maturing. Standards and identity are being hammered out. There is still a lot of work ahead.

But the direction is clear. As AI models learn to operate computers, not just reason about them, the nature of work, software and systems shifts. We transition from "I click the buttons" to "I describe what I want done and my agent clicks the buttons."

And when machines handle the clicking, humans get their time back for what truly matters.


## Footnotes

[^1]: Learn more about [Reinforcement Learning](https://www.geeksforgeeks.org/machine-learning/what-is-reinforcement-learning/)

[^2]: Models that are able to take in both text & image inputs to return a response.

[^3]: Everyone defines agents differently. I define an agent as a system in which AI autonomously decides what actions/steps to take given the state it's given.

[^4]: Early visions of software agents go back decades. Think of the "smart assistant" concepts from the 1990s. They mostly tried to suggest help while you did the work. The AI and interface capabilities simply were not there. With modern models, that vision is finally becoming practical.

[^5]: We're calculating the tokens using the get_encoding function from a tiktoken fork with js bindings: [Repo](https://github.com/dqbd/tiktoken)


A deep dive into the state of Computer Use and Web Agents. 

What’s the big deal about computer use?

Miguel Gonzalez

The variety of models capable of interacting with the internet to automate real tasks continues to expand. Today, Microsoft is announcing [**Fara-7B**](https://www.microsoft.com/en-us/research/blog/fara-7b-an-efficient-agentic-model-for-computer-use/), a small computer-use vision language model (VLM) that achieves new state-of-the-art results for its size.

Training and evaluating browser-based agents at scale requires reliable access to real websites, high concurrency, and consistent execution environments. Meeting these requirements directly impacts both reinforcement learning workflows and the accuracy of model evaluation.

That is why **Microsoft has exclusively partnered with Browserbase** to train, evaluate, and deploy their next generation of open-source computer-use models. As [Corby Rosset](https://www.linkedin.com/in/corbyrosset/), Principal AI Researcher at Microsoft, put it:

> “Without Browserbase, it would not have been possible to seamlessly train our model with reliable access to real-world websites.”
> 

Building upon our [existing work with Deepmind](https://www.browserbase.com/blog/evaluating-browser-agents), we were able to integrate, host, and independently evaluate Fara-7B on Browserbase within a week to provide fair and reliable benchmarking

The results were surprising… a good surprise.

## Introducing Fara-7B - a small but mighty model

Fara-7B delivers **unmatched speed and cost efficiency** for its size, with meaningful real-world capability. When benchmarked on the publicly available 595-task WebVoyager dataset updated in collaboration with Microsoft and using human-verified scoring, Fara-7B significantly outperformed similar open-source models.

Here are the results (pass@1 with up to 5 retries):



![](https://cdn.sanity.io/images/v773ixxh/staging/96598833c836894fdf10c277024620a29e4a4fc6-1920x962.png)



Small computer-use models like Fara-7B meaningfully change the unit economics of browser agents. Sub-second inference and dramatically lower compute costs enable running multiple agents in parallel, unlocking workflows that simply are not feasible with large proprietary models.

## Browserbase evaluation criteria

To ensure fairness, we evaluated **7B-size models only**, using Microsoft’s updated version of Web Voyager.

We used **pass@1 with up to 5 retries**,  reflecting real-world deployment patterns for small self-hosted models. All evaluations ran on [**Browserbase’s deterministic browser infrastructure**](https://browserbase.com/), ensuring consistent environments without variability from rate limits, random states, or anti-bot checks. Every task was **human-verified**, with evaluators reviewing screenshots, full web trajectories, and the final task state to confirm completion. We measured **accuracy**, **cost**, and **speed** across all 595 tasks.

We will continue expanding this evaluation approach, including re-running Gemini, OpenAI CUA, and other frontier models using the same retry-friendly methodology to make comparisons fully consistent.

## Why independent evaluation matters

Evaluation of computer-use models across the industry is fundamentally inconsistent, which is why UI-Tars 1.5-7B performed far worse than its published numbers.

Here is what we consistently see:

- **LLM judging is unreliable.** Different evaluators use different judge models, thresholds, prompts, or exclude failures.
- **Websites change.** Benchmarks using live websites break, get redesigned, rate-limit, or show entirely different flows.
- **Strictness varies widely.** One judge model passes an action, another flags it as incorrect.

When we evaluated UI-Tars, we found that many tasks reported as “successful” were incomplete or incorrectly executed, including cases where an LLM judge passed trajectories that a human evaluator would not consider correct.

This is exactly the motivation behind the [Stagehand Evals CLI](https://docs.stagehand.dev/v3/basics/evals) and and our broader benchmarking work, which allows you to run real models on real websites using reliable browser infrastructure that eliminates site-level noise, provides fully observable sessions with screenshots and logs, and incorporates human verification to catch what automated judges miss. 

Standards produce reliable computer-use model evaluation, and reliability builds trust. That trust is why leading research teams like Microsoft and DeepMind partner with us to benchmark their models and make results reproducible for the community.

## Open source and available today

Fara-7B is available today, with full open weights on [HuggingFace](https://huggingface.co/microsoft/Fara-7B) and [Azure AI Foundry](https://ai.azure.com), and [Stagehand](https://stagehand.dev) has built-in support for it out of the box. You can deploy it via:

- **[Azure Foundry](https://ai.azure.com/)** (hosted directly by Microsoft)
- **[Fireworks](https://fireworks.ai/)**, which made running both models effortless and supported fair inference comparisons

You can **try it out on Stagehand** by running:

``` Bash
# TypeScript
npx create-browser-app --template microsoft-cua
```

Huge thanks to the Fireworks team for fast hosting and model support.

## Calling all researchers
We are excited about the next generation of small, fast, open models, and equally committed to building the infrastructure required to evaluate them correctly.

This collaboration highlights a broader shift in how computer-use models are being built. The most successful approaches tend to share several traits: training on the real web instead of synthetic environments, grounding models through interaction and feedback, optimizing for practical deployment rather than benchmark-only performance, and maintaining transparency through shared trajectories and verification.

If you are training or fine-tuning a computer-use model, [**reach out**](http://browserbase.com/contact).

We would love to help evaluate your model, validate it with human verification, and share feedback that helps move the ecosystem forward.

## Footnotes

- [Fara 7B - Webvoyager](https://evals-hub.vercel.app/)
- [UI Tars 1.5 7B - Webvoyager](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/UI-Tars-1.5-7B-agent%2Fwebvoyager_browserbase_20251121182847?c=agent/webvoyager_browserbase_20251121182619)

Microsoft has exclusively partnered with Browserbase to train, evaluate, and deploy their next generation of open-source computer-use models

Evaluating computer use models with Microsoft

Amel Bajramovic

One of the most painful parts of building browser infrastructure for AI is that, historically, websites would block out **all** web automation because of harmful activity like spam or fraud. Browsers were designed with that assumption baked in.

But the world has changed.

AI now drives real, useful automation, whether it’s agents performing research or running across hundreds of pages. These agents **are** legitimate users, just acting on someone’s behalf.

The problem is that browsers didn’t evolve for this. They were built to run on personal machines rather than servers. They were never meant to be programmatically controlled for long periods, and they certainly weren’t meant to act like real browsers while being automated.

At Browserbase, we’re building browser infrastructure for this new reality, where automation is a core part of how people use the web. That means our browsers must behave exactly like Chrome from the outside. The same APIs, same identity, and same long-running stability.

To do that, we had to take control of the foundation itself and crack open the black box. Just patching over Chrome at the JavaScript level didn’t give us enough control over customization. 

So we forked [Chromium](https://github.com/chromium/chromium).

## Navigating the Chromium labyrinth
The sheer complexity of the Chromium source tree presents unique challenges for implementing meaningful modifications. Unlike typical software projects with clear architectural boundaries, Chromium’s functionality is distributed across multiple rendering engines, JavaScript interpreters, network stacks, and platform abstraction layers.

Identifying *where* to change something often means tracing a behavior through hundreds of seemingly unrelated code modules.

For example, modifying something as simple as a navigator property requires understanding how that value is generated across several subsystems. The `navigator.userAgent` string alone appears in platform detection modules, network headers, JavaScript bindings, and compatibility layers. A property like `navigator.hardwareConcurrency` touches threading libraries, worker systems, and performance monitors. All of which need to remain in sync to avoid breaking runtime expectations.

This challenge is compounded by Chromium’s rapid release cycle. New versions ship roughly every six weeks, with hundreds of commits landing daily. Each release can disrupt custom patches, forcing us to track upstream changes, validate compatibility, and rework affected code paths.

Maintaining this level of precision demands a continuous engineering investment and a deep, evolving understanding of Chromium’s internals.
## Building through the chaos
When we first started building out our own custom Chromium binary, there were no reliable build guides. Most community posts are outdated or incomplete. And with a codebase that spans millions of files, every small step forward required experimentation.

So we did what any reasonable engineering team would do: **we f’’ed around and found out.**

![](https://cdn.sanity.io/images/v773ixxh/staging/467ac2ba49954963d3e3ac3eed740f7237948af2-577x418.png)

The first month was pure exploration, tracing through code, guessing where to patch, and rebuilding again and again to see what broke.

Rebuilds are notoriously slow. A full Chromium build can take 3-4 days on standard development hardware like a MacBook laptop, assuming nothing fails. Every modification means another full rebuild to validate changes, and iterating on patches under those conditions quickly turns into multi-week cycles.

To stay sane, we built our own infrastructure.

Our dedicated build machine compiles Chromium in about **an hour,** which turns multi-day build loops into something that fits inside a productive workday. This speed has made it possible to iterate quickly and keep up with Chromium’s release cadence.
## Our breakthrough was purposeful patching
When we say we “*patched*” Chromium, what we really mean is that we **intentionally broke it.** 

We altered behaviors that signal automation and rebuilt them to behave like normal user sessions. This looked like hundreds of patches in hundreds of different files, but we’ll examine three that our team finds particularly interesting.
### We removed the `navigator.webdriver` flag
By default, this property **exposes that automation is active**. The flag is set deep inside Chromium’s rendering engine, specifically in Blink, which is the part of Chromium responsible for implementing web platform APIs like `navigator`.

When automation frameworks like Puppeteer or Playwright launch Chrome with the `--remote-debugging-port` flag, Chromium sets internal states that toggle the `navigator.webdriver` property to `true`. 

We patched that behavior at the source to make `navigator.webdriver` **always return false**, no matter how the browser was launched.

![](https://cdn.sanity.io/images/v773ixxh/staging/d46b1aafc3572ce10049e9d0fab3c66c2fec74a6-3680x3028.png)

This sounds simple, but it has ripple effects. Internally, the `GetWebDriver() `state is propagated from Chromium’s content layer (C++) through Blink’s bindings generator into the JavaScript environment. If you patch it incorrectly, you can break feature detection logic or cause compatibility regressions in CDP.
### We replaced “HeadlessChrome” with “Chrome”
But, Chrome builds the user agent from multiple sources: a product token, platform info, and metadata. If you only switch the product token, pages still see “HeadlessChrome” in other places. Our patch updates the headless product name to `Chrome` and keeps the metadata and CDP reporting consistent with a normal Chrome build. Requests from workers, iframes, and service workers use the same values because the Network Service pulls from the same metadata.

![](https://cdn.sanity.io/images/v773ixxh/staging/6dcf06b9b82cf48aad6f7c924b040d1e5ea66254-3680x2576.png)

Now, the headless browser presents the same identity surfaces as Chrome beyond just the visible string.
### We added persistent, long-lived session support
Normal headless browsers are short-lived. They boot, execute, and die. That behavior makes sense for testing or quick jobs, but it breaks down when we need a browser that can stay open for hours or days.

We patched this by enabling keep-alive behavior on Linux to support long-running sessions.

![](https://cdn.sanity.io/images/v773ixxh/staging/d5e0c087b40db2c8159f77eb376d82cbbd34b54c-3680x2488.png)

By default, Linux Chromium instances terminate when all windows close. This makes headless sessions inherently unstable when background processes are torn down, network sockets close, and session storage is lost. 

Enabling `kBrowserAliveWithNoWindows = true` changes that behavior. The browser process remains active even when there are no visible windows, keeping its profile and CDP endpoints alive until explicitly terminated. This lets AI agents and automation systems maintain stable browser contexts with the same cookies, memory state, and connections across many requests and interactions.

Basically, this patch gives headless Chrome a heartbeat. It stays alive, keeps state, and behaves like a real browser, which is exactly what’s needed for long-running AI agents and automated workflows.

![](https://cdn.sanity.io/images/v773ixxh/staging/6fa5555b25f062b7ac1afcb02df6e837e3f6987f-1945x853.png)

Each of these patches sounds simple, but each one required an in-depth understanding of Chromium’s internal systems, from DevTools bindings to process sandboxing to inter-thread messaging. And every one of them had to be carefully maintained across new releases.

## Craft over convenience
Forking Chromium isn’t glamorous. It’s thousands of tiny experiments, failed builds, and late nights chasing invisible behavior. There was no template to build. We had to learn it, break it, and eventually make it do what we needed.

By patching Chromium itself, we’ve been able to customize the binary to meet our developers’ precise needs. We’re building for what comes next. We’re evolving the browser to fit a new era where automation is a legitimate user behavior. 

This is an era where browsers are for people **and** systems that act on their behalf. And we’re not finished yet.

<custom-cta text="Automate the web today" button_text="Get started" button_link="https://www.browserbase.com/"></custom-cta>

A deep dive into why Browserbase forked Chromium and how we engineered a stable, long-running browser optimized for AI agents. This post covers the core patches, architectural challenges, and what it takes to customize Chromium at the source level.

Why we forked Chromium

**TL;DR: We’re launching the best automation framework.**

So, you probably **should** read all the details. ;)

Stagehand v2 took off, with half a million weekly downloads, hundreds of production automations, and a growing ecosystem of [Browserbase](https://www.browserbase.com/) users. But the more people built with it, the clearer the limits became: it was fast, but not fast enough, and ergonomic, but not open **enough**.

**Today we’re launching the fix for that: Stagehand v3.** It’s the best automation framework, and we mean it when we actually call it the best this time. It’s the most extensible, reliable, and AI-ready version we’ve ever built, and it’s **44.11%** faster on average across iframes and shadow-root interactions.
## What’s new?
1. **Extensible** (You can use Stagehand with Puppeteer, Playwright, Bun, and more).
2. **Reliable** (Stagehand can talk to any website, including iframes/shadow DOMs).
3. **Fast** (We re-wrote it from scratch and v3 talks directly to the browser using Chrome Dev Tools Protocol (CDP), minimizing round trip time (RTT)).
4. **Built for Automation** (We’ve optimized Stagehand for automation, not for testing).
5. **Optimized for AI** (Our new context builder reduces token waste).
## Why we’re graduating from playwright
Playwright got us here. It gave Stagehand a strong foundation and a fast on-ramp, since developers could drop Stagehand into existing Playwright scripts and start shipping AI-driven automations in minutes. That compatibility was key to early trust and adoption.

As usage scaled, though, we began to see the seams between a testing-first framework and an automation-first runtime. Playwright’s actionability checks and auto-waiting are ideal for tests, but they add overhead in automation scenarios where throughput and control take priority.

We also needed **deeper CDP-level control,** particularly for iframes and multi-tab workflows. Building rich context for models means streaming accessibility trees, DOM snapshots, and network events directly from Chrome DevTools Protocol. Playwright’s abstractions made that harder than it needed to be.

Finally, long-lived automation sessions demanded a different operational profile: lighter memory use, faster frame-scoped routing, and fewer websocket round-trips.

Stagehand v3 builds on those lessons. **We’ve moved beneath the test layer to operate natively at the protocol level** and set a new foundation for automation tasks, while still keeping the ergonomics we all love.
## From framework to platform
At the architectural core, **v3 removes the Playwright dependency** and introduces a modular driver system. Stagehand now works seamlessly with Puppeteer or any driver built on the Chrome DevTools Protocol.

This shift unlocks faster iteration, full portability across environments (including Bun), and smoother CI/CD integration. More than a framework, Stagehand is now an **automation platform** built for hosted browsers, agents, and AI.
## Speed you can feel
Stagehand v3 is built for real, measurable speed across the kinds of environments where automation usually slows down. Our benchmarks highlight performance across deeply nested iframes and shadow DOMs, some of the hardest surfaces in modern web automation.

Across this suite, v3 completes actions **44%+ faster overall**, consistently outperforming v2 across every scenario. 

[![](https://cdn.sanity.io/images/v773ixxh/staging/a1fa9ec1266c3e8db9e64dea500994fdc992fede-1920x1080.png)](https://browserbase.notion.site/Stagehand-v3-benchmarking-2963c11b661480648b12fbd4885c3b10)

The result is clear: faster execution across every benchmark, tighter control loops, and automation that simply **feels** more responsive, especially on Browserbase, where network-layer optimizations amplify the difference.

[![](https://cdn.sanity.io/images/v773ixxh/staging/e606054a93d52e2cb9400ae7b4a830121b73b5f7-3840x2160.png)](https://browserbase.notion.site/Stagehand-v3-benchmarking-2963c11b661480648b12fbd4885c3b10)

[See the eval sources here.
](https://browserbase.notion.site/Stagehand-v3-benchmarking-2963c11b661480648b12fbd4885c3b10)
## Built for automation
Stagehand v3 keeps its focus on real automation, where it belongs. We promise ease to control browsers, after all. v3 is built for agents, scrapers, copilots, and browser-native workflows that are primed for execution, not just testing. 
## Optimized for AI
Instead of treating AI as an add-on, we re-architected Stagehand to be AI-native from the ground up. v3 now automatically caches discovered elements and actions that you can reuse without any additional LLM inference cost or time, and intelligently involves AI when workflows break.

Common user actions are repeatable and predictable, ensuring agents can operate reliably across changing page states. Its new context builder reduces token waste by feeding models only what’s essential, while a self-healing execution layer adapts in real time when a DOM or layout shifts. And with a new, model-agnostic Agent Mode, Stagehand lets you pair these capabilities with any LLM or CUA (computer use agent) without changing your workflow. 

The result is automation that feels purpose-built for AI: efficient, resilient, and ready for whatever model you plug in next.
## Why this matters
The browser has become the universal interface for automation and the front end of the modern agent stack.

Stagehand v3 makes that interface **programmable, stable, and fast**.

> “Our Stagehand v3 workflows are noticeably snappier when run side-by-side with v2. We now get detailed observability and token-level reporting per action, which speeds up debugging and helps us optimize caching to save on model costs.”
> 
> 
> — **[Steve Austin](https://www.linkedin.com/in/austinsteven/), Co-Founder & CTO @ Benny**
> 
## What’s next 🤟
By moving closer to the browser, shedding unnecessary dependencies, and optimizing for AI from the ground up, we’ve made Stagehand faster, more flexible, and ready for whatever you’re building next.

If you’re an existing Stagehand user, upgrading from v2 is simple. Check out the [migration guide to get started](https://docs.stagehand.dev/v3/migrations/v2). If you’re new here, the [docs](https://docs.stagehand.dev) walk through everything you need to install, connect, and run your first automation in minutes.

**v2 made browser automation accessible, and now v3 makes it unstoppable.** Try it today and see what your browser can really do. :)

Get started: `npx create-browser-app`

<custom-cta text="Try Stagehand v3" button_text="Start automating" button_link="https://docs.stagehand.dev/v3/first-steps/introduction"></custom-cta>

Stagehand v3. It’s the best automation framework, and we mean it when we actually call it the best this time. It’s the most extensible, reliable, and AI-ready version we’ve ever built

Launching Stagehand v3, the best automation framework

## Playwright got us here - where we’re going next
Stagehand began as an AI-centric layer built on Playwright, adding new capabilities like `act`, `extract`, and `observe` on top of its existing API. That choice lets developers plug Stagehand into existing scripts in minutes and ship real automations fast. As the community has grown and our ambitions are expanding, we have run into the natural limits of building on a test‑first framework. This post is a look back at why Playwright was the right starting point, and why we’re taking Stagehand deeper into the browser stack.
## Why we started on Playwright
In the early days, our goals were clear: remove friction, meet developers where they are, and earn trust. Returning a Stagehand‑enhanced `Page` / `Context` meant your Playwright code kept working, now with AI‑powered primitives on the same object. 

**Result: minimal migration, lots of adoption, and a fast feedback loop with real users.** The [docs](https://docs.stagehand.dev/first-steps/introduction) still say it best: *“Full Playwright compatibility… use any Playwright API alongside Stagehand.”* 

That compatibility made Stagehand a great **and** pragmatic choice for teams taking their first steps into AI‑assisted automation with us.
## What changed as we scaled
As Stagehand and our community have grown, we’ve noticed a few seams showing. Less about **quality** and more about **fit**.
### 1) Testing DNA vs. automation throughput
Playwright’s [actionability checks and auto‑waiting](https://playwright.dev/docs/actionability) are fantastic for end‑to‑end tests: click only when an element is visible, stable, enabled, and receiving events. For automation, where we often want to move quickly and accept more direct control, those checks can add latency and complexity we don’t always need.
### 2) We need CDP‑level control (especially for frames)
Stagehand builds rich, structured context for models by reading directly from the Chrome DevTools Protocol (CDP): accessibility trees, DOM snapshots, network events, and more. Doing that well requires stable identifiers and precise scoping. This is where we hit friction:

- **Frame identity & scoping.** Playwright [doesn’t expose a unique frame ID](https://github.com/microsoft/playwright/issues/30261), which makes lifecycle tracking and per‑frame CDP routing harder than it needs to be.
- **Practical interop gaps.** As Sean [wrote](https://www.browserbase.com/blog/taming-iframes-a-stagehand-update) in our [iframes update](https://www.browserbase.com/blog/taming-iframes-a-stagehand-update), Playwright and CDP don’t always play perfectly together when you need to target CDP to specific frames and stitch multi‑frame state back together. We worked around this with a unified tree, deep XPath locators, and smarter session mapping, but this was all work we had to do because of those gaps.
- **Per‑page CDP sessions.** Playwright exposes CDP via [`CDPSession`](https://playwright.dev/docs/api/class-cdpsession), typically scoped from a page/context. That’s useful, but once you’re doing heavy CDP‑first work, you want finer‑grained control and fewer round‑trips.

In short: when a product **is** automation (not testing), we eventually **want to operate at the protocol layer without extra hurdles.**
### 3) Operational headroom matters
Our users have reported memory growth in long‑running sessions and version‑specific regressions. Even when issues are addressed upstream, staying strictly on the Playwright rails can make it harder for us to choose different tradeoffs for long‑lived automation workloads.

![](https://cdn.sanity.io/images/v773ixxh/staging/c247f25d946eda2a893ad29a9f7ac6436de3d2f6-2858x1691.png)
## What we learned building on top of Playwright
- **It was the fastest on‑ramp.** Developers could drop Stagehand into existing code and get value right away.
- **The surface area is huge.** A testing‑first framework brings a long tail of APIs and behaviors we don’t lean on, and maintaining perfect fidelity to that surface area constrains how fast we can ship automation‑first features.
- **Frames are the real world.** Modern sites are a thicket of same‑origin and out‑of‑process iframes. Doing great work there means embracing CDP deeply and minimizing requests sent over the websocket (Our [iframes post](https://www.browserbase.com/blog/taming-iframes-a-stagehand-update) walks through the details).
## Principles guiding the next phase
We’re codifying a few principles that reflect what our users actually need:

1. **Automation‑first semantics.** Keep the ergonomics developers love, but put throughput and control ahead of test ergonomics (you can still opt‑in to waiting and safety rails when you need them!).
2. **CDP‑native performance.** Expose the right hooks so Stagehand can build context efficiently (fewer, smarter messages), especially across iframes, workers, and tabs. 
3. **A smaller core, fewer surprises.** Focus on the primitives that matter for automation without absorbing unrelated testing machinery.
4. **Compatibility where it counts.** Developers shouldn’t have to rewrite everything to benefit from these changes. The spirit of “drop‑in and go” stays.

Playwright has been a terrific foundation: a clean mental model, a mature ecosystem, and an incredible community. It has helped Stagehand hit the ground running and reach far more developers, far more quickly, than we could have alone. As we keep pushing what’s possible in browser automation, we’re taking the lessons (and the gratitude) with us.

Stagehand’s mission hasn’t changed: give developers and models a browser they can *trust*. The work ahead is about sharpening that promise: making the core smaller, the behavior more predictable, and the performance feel native to the metal. 

More soon. :)

<custom-cta text="Build automations with Stagehand" button_text="Get started" button_link="https://docs.stagehand.dev/first-steps/introduction"></custom-cta>

Stagehand began as an AI-powered layer on top of Playwright. As we’ve scaled, we’ve outgrown its test-first design. Here’s how we’re rethinking automation from the ground up.

The Browser Blog

Building the future of web automation

Building the future of web automation

Read Article

This week we fixed the worst part of Browserbase

Read Article

The best browser automation framework, in every language

Read Article

How serverless browsers unlock scalable web automation

Read Article

Browserbase enables agentic payments with Coinbase and x402

Read Article

What’s the big deal about computer use?

Read Article

Evaluating computer use models with Microsoft

Read Article

Why we forked Chromium

Read Article

Launching Stagehand v3, the best automation framework

Read Article

Why we’re graduating from Playwright

Read Article