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

Miguel Gonzalez

Harsehaj Dhami

**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.

Why we’re graduating from Playwright

Derek Meegan

As a Customer Engineer, I spend nearly all of my time resolving issues related to web automations. Truthfully, my job is primarily debugging other people’s code, and in that time, I have learned tons of expert-level ways to improve your life when it comes to building web automations. After speaking to hundreds of customers and sending thousands of customer support messages, here are the 7 best practices to build better web automations with Browserbase. 

**1. Browser Contexts: What is a browser context?**

A browser context is like an isolated, temporary browser profile with its own cookies, storage, and fingerprint. If you create a new page, you wipe that fingerprint. Browserbase creates a default browser context *for you.* Using this context is important because Browserbase preconfigures your fingerprint and stealth profile automatically, no setup required.

![](https://cdn.sanity.io/images/v773ixxh/staging/2b366c3b10d35afe01ab2dd15c62367362673bca-1200x342.png)

**2. Contexts API: What is the contexts API and how is it different than browser context?**

Great question! The contexts API is how Browserbase allows log-ins to specific accounts to be reused across multiple browser sessions without re-authenticating. This makes your automations more robust and fast, since the login step can be skipped and most antibot enforcements occur during login. Thanks to our partnership with [Web Bot Auth](https://www.browserbase.com/blog/cloudflare-browserbase-pioneering-identity) and [1Pass](https://www.browserbase.com/blog/1password-agentic-autofill), you can even manage and reuse credentials securely across teams and projects. No more hardcoded passwords or flaky login scripts.

![](https://cdn.sanity.io/images/v773ixxh/staging/74ad8e3208d104b6046e920c47171754530a9268-1200x625.png)

**3. Using CDP for PDFs**
* **What is CDP? What does it do?** 
The **Chrome DevTools Protocol (CDP)** is a set of JSON-based APIs that let you control, instrument, inspect, and debug Chromium-based browsers (like Chrome, Edge, Brave.
* **What does this have to do with PDFs?** Chrome uses a special web viewer for PDFs, which is different from a normal webpage. To process a PDF, you can enable downloads in the browser using CDP. **Alternatively** you can enable the PDF Viewer by setting enablePDFViewer to true in your browser settings. But I think CDP is better! 

![](https://cdn.sanity.io/images/v773ixxh/staging/1fc72449100705efc4fde73f8bf2fa96394018c4-900x838.png)

**4. Using CDP for Screenshots**

CDP is so great it also works for screenshots. If you want faster, higher-fidelity screenshots you can use CDP directly. 

![](https://cdn.sanity.io/images/v773ixxh/staging/f5d84f910185be008d4062440da735be13f680e0-900x518.png)

**5. Proxies: What is a proxy?**

A proxy server is **an intermediary that handles your internet requests, acting as a gateway between your device and the internet**. It receives your requests, forwards them to the destination server on your behalf, and then returns the data to you. Sometimes you need different proxies for different sites. Browserbase lets you define custom proxy routing rules, and you can even disable proxies for certain sites using our regex-based domain pattern argument.


![](https://cdn.sanity.io/images/v773ixxh/staging/e3ac303cedb8243c4325babe087c8af72d81abcc-900x702.png)


**6. Dialogues + Pop-Ups**

A dialogue window is a small pop-up that appears on top of a webpage when your browser needs user input or confirmation before continuing. These are typically difficult to interact with in web automation since they live outside of the normal web page.

Think dialogues are unreachable? Think again. Bypass dialogue pop-ups by adding an init script to your default context.

![](https://cdn.sanity.io/images/v773ixxh/staging/fc74561afbae854154ef74ffc0fc98db46cec4f8-900x369.png?w=450)

**7. Lean on the Community**

Lastly, if you run into issues, let us know! Web automation as a first-class solution is still an emerging space, but I can confirm that Browserbase’s support is excellent. Shoot a message to support@browserbase.com or join our Discord!

Web automation moves fast, and the tools keep getting smarter. The real edge comes from understanding how to combine them effectively: using features like Browserbase’s contexts, APIs, and CDP access to eliminate friction and focus on the logic that actually matters.

If there’s one thing I’ve learned from helping hundreds of teams, it’s that the difference between “it works” and “it works every time” is all in the details. Take the time to refine your approach, learn from the community, and keep experimenting. That’s where the real breakthroughs happen.

How to optimize your web automations using Browserbase and Stagehand. Article covers common best practices for improving automation scripts and shares unique features Browserbase offers.

Optimize your web automations using Browserbase

Sean McGuire 

The future of the web is agentic. Humans live in the physical world, but we increasingly find ourselves leaving our mark online (perhaps more than we'd like). We open our screens to do a little bit of everything, sometimes for fun, but often for tasks that are repetitive and boring. AI has potential to make browsing fun again, and become our trustworthy companion in navigating the web.

We're not there yet; the web is still a wild frontier for AI. Teaching models to reason, explore, and act within it is no small feat. That’s why we partnered with Google DeepMind, leveraging the Browserbase infrastructure to help train, evaluate, and deploy the newest generation of Gemini models, reaching new state-of-the-art levels in accuracy, speed, and cost.

## New Ceilings, New Opportunities

We have been working closely with Google DeepMind to help evaluate and measure the progress of their new `gemini-2.5-computer-use-preview-10-2025` model. Stagehand, our fully open source framework, provides a provider-agnostic interface for computer use models, making it easy to swap and compare models against one another. To help track progress and compare different models, we added support for multiple benchmarks like [OnlineMind2Web](https://huggingface.co/datasets/osunlp/Online-Mind2Web) and [WebVoyager](https://huggingface.co/papers/2401.13919), as well as our custom set of evals for both atomic actions and agents. 

Over the past couple of months, we accumulated over 200 experiment runs, combining for a total of ~4,000 browser hours (almost 6 months of runtime). The results speak for themselves:

## OnlineMind2Web @ 50 steps
[![](https://cdn.sanity.io/images/v773ixxh/staging/0247a8fe8ea0d1b8ce0019b5a0357f44dfd5c602-2438x1452.png)](https://www.stagehand.dev/agent-evals)
## Webvoyager @ 75 steps
[![](https://cdn.sanity.io/images/v773ixxh/staging/2ead519f1b2148b14c7234b28989585b1597c5d7-2444x1458.png)](https://www.stagehand.dev/agent-evals)

The new Gemini 2.5 Computer Use models outperform every other major provider in accuracy, speed, and cost. Every model was tested through their publicly accessible API, with the same constraints on steps, timeouts, and stealth+performance environment capabilities. The new computer-use-preview model from Google presents a paradigm shift; allowing builders to create more with less, faster than ever.

## Manipulating Time
By providing scalable infrastructure for running browsers in the cloud and observability to understand exactly what actions the models are taking, Browserbase helps cut the training and evaluation time from months to minutes. Instead of running the agents on a single browser and waiting for a task to complete before moving on to the next, it's possible to branch off and train and evaluate in parallel—all at the same time. 

Thanks to Browserbase's concurrent browser infrastructure, we were able to condense ~18 browser hours into 20 minutes of total runtime. 

![](https://cdn.sanity.io/images/v773ixxh/staging/2df39a75d2d03c4523120230dab8832d8c7b2fba-1945x1094.png)


With this scale, total time for a given run is limited by an agent's time taken to complete a single task. Faster iteration, observability into mishaps, and feedback on improvements all combine into a recipe for training capable browser agents that navigate the web better than we do (yes, many times we find ourselves trying to keep up on what the agent just did). 

## Challenges of Benchmarking Browser Agents
Tracking progress and testing web agents is a challenging process. Websites change, traffic gets blocked, and the goals for certain tasks become obsolete over time.

There are two main approaches to mitigating the above issues:

### 1. Cloning websites

This approach involves making a best-effort copy of an existing website, and having the browser agent navigate within the copied website instead of the original. 

### 2. Using real websites

This is the approach that evaluation datasets like WebVoyager have taken. This approach involves creating a set of prompts or tasks coupled with starting URLs, and then evaluating whether the agent completed said task.

Both of these approaches are imperfect, and come with their own sets of challenges. The problem with cloned websites is that they often do not emulate the real World Wide Web, or perhaps better described as the Wild Wild Web. A static website in a controlled environment doesn’t capture the unpredictable nature of navigating a live, hosted website. There are no surprise cookie popups, captchas, iframes with ads, or slowly loading content. A lot of what makes the web challenging for agents becomes controlled.

Using real websites is also a huge challenge because of how frequently they change. A task that worked yesterday may be impossible tomorrow. For example, here is a [task](https://github.com/MinorJerry/WebVoyager/blob/5a7896738c10bfb8b9edccce6bb0e0411f8ae569/data/WebVoyager_data.jsonl#L223) from the WebVoyager dataset:


```json
{
	"web_name": "Booking", 
	"id": "Booking--8", 
	"ques": "Get the hotel with highest review score and free cancelation in Chennai for 20/12/2023 - 21/12/2023.", 
	"web": "https://www.booking.com/"
}
```

Obviously, given today's date, the above task is impossible. But what should we do with this task? Should we include it in our evaluation? It doesn’t seem like a fair evaluation, and it certainly doesn’t provide any useful data on how the agent performed. But what about other people evaluating their web agents? Did they include this task? 

The easiest thing to do here is to remove or replace tasks like this, but over time, this ends up with people benchmarking against a slightly different subset of tasks. If everyone is using different tasks, then is the benchmark even a benchmark?

### The Path Forward

We believe the path forward lies in **transparency and collective calibration**.

Instead of quietly pruning benchmarks and omitting tasks, we’re publishing [**the full set of 3,772 human-verified evaluations**](https://www.browserbase.com/blog/evaluating-browser-agents#footnotes), including traces and scores for every run — successful or not. By making the raw data public, we invite others to spot ambiguous or outdated tasks, propose updates, and help shape a more stable foundation for measuring progress.

To make this process accessible, we’ve also open-sourced the [**Stagehand Evals CLI**](https://github.com/browserbase/stagehand/tree/main/evals), enabling anyone to reproduce our experiments, inspect failures, and run their own agent comparisons locally.

We’re also providing day-1 support for the new model in Stagehand (TypeScript and Python). Getting started is as simple as:

```TypeScript
# TypeScript
npx create-browser-app --template gemini-cua
```
```Python
# Python
uvx create-browser-app --template gemini-cua
```

You can also try it on Google’s official quickstart repo: https://github.com/google/computer-use-preview

If you’re not worried about benchmarks, and prefer to evaluate based on ✨ vibes ✨, we’re also launching the [Browser Agent Arena](https://arena.browserbase.com). You can define a task and see which computer use model performs the best. 

This partnership with Google DeepMind is just the beginning. Models are becoming more capable, soon operating a browser faster than a human can. 

Instead of rebuilding the internet for AI, soon AI will be browsing alongisde us. This is an exciting future, where every interface becomes programmable and every digital task can be automated

The future is agentic, and it starts now.

We can't wait to see what you 🅱️uild!

### Footnotes
- [OpenAI Mind2Web](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/OPENAI-agent%2FonlineMind2Web_browserbase_20250926053440?c=GOOGLE_OLD-agent/onlineMind2Web_browserbase_20250926044532&g=[%22metadata%22,%22difficulty%22])
- [Google Mind2Web](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/GOOGLE_NEW-agent%2FonlineMind2Web_browserbase_20250926040431?c=agent/onlineMind2Web_browserbase_20250926040323&g=[%22metadata%22,%22difficulty%22])
- [Anthropic Mind2Web (sonnet 4)](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/ANTHROPIC-agent%2FonlineMind2Web_browserbase_20250926062208?c=OPENAI-agent/onlineMind2Web_browserbase_20250926053440&g=[%22metadata%22,%22difficulty%22])
- [Anthropic Mind2Web (sonnet 4.5)](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/ANTHROPIC-SONNET-4.5-agent%2Fwebvoyager_browserbase_20250929223935?c=agent/onlineMind2Web_browserbase_20250929191208&g=[%22metadata%22,%22website%22])
- [OpenAI WebVoyager](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/OPENAI-agent%2Fwebvoyager_browserbase_20250928044215?c=ANTHROPIC-agent/webvoyager_browserbase_20250928044119)
- [Google WebVoyager](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/GOOGLE-agent%2Fwebvoyager_browserbase_20250928191012?c=agent/webvoyager_browserbase_20250928183557&g=%5B%22metadata%22,%22website%22%5D)
- [Anthropic WebVoyager (sonnet 4)](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/ANTHROPIC-agent%2Fwebvoyager_browserbase_20250928044119?c=agent/webvoyager_browserbase_20250928043940)
- [Anthropic WebVoyager (sonnet 4.5)](https://www.braintrust.dev/app/Browserbase/p/stagehand-dev/experiments/ANTHROPIC-SONNET-4.5-agent%2Fwebvoyager_browserbase_20250929223935?c=agent/onlineMind2Web_browserbase_20250929191208&g=[%22metadata%22,%22website%22])

We have been working closely with Google DeepMind to help evaluate and measure the progress of their new computer-use-preview model. Stagehand, our fully open source framework, provides a provider-agnostic interface for computer use models, making it easy to swap and compare models against one another. To help track progress and compare different models, we added support for multiple benchmarks like OnlineMind2Web and WebVoyager, as well as our custom set of evals for both atomic actions and agents. 

Training & Evaluating Browser Agents - Our Journey with Google Deepmind

Kyle Jeong

Sigfrido Narváez

While APIs deliver clean, structured data on a silver platter, the most valuable insights for AI applications often hide in the messy, unstructured corners of the web. AI's potential is immense, and many organizations face a significant challenge: their existing data infrastructure isn't ready for the scale needed by AI. The web is a vast ocean of data, and \~80% of it is unstructured. 

But what if you could reliably automate web interactions, extract complex data, and seamlessly integrate it into a database that offers a variety of query and search methods? This is where the powerful combination of Stagehand (by Browserbase) and MongoDB Atlas redefines what's possible for building AI applications.


![Stagehand-MongoDB-Diagram](https://cdn.sanity.io/images/v773ixxh/staging/7f57877417ca2f3a3cc3d559d067f9941bcac8cd-3450x1276.jpg)


Fig. 1- Stagehand and MongoDB Atlas: Seamlessly automating web data collection and AI-ready integration.

### **Stagehand: An SDK for developers to write automations with natural language**

The browser is a powerful tool for collecting data, but it's hard to control and scale. Traditional browser automation tools like Playwright, Puppeteer, and Selenium often force developers to write fragile code that breaks with even slight UI changes on a website. This makes maintaining scripts on live websites a significant pain point. Stagehand, however, is designed specifically for the AI era.

**Stagehand allows you to automate browsers using a combination of natural language and code**. It's built to be more reliable and adaptable than legacy frameworks, enhancing Playwright's determinism with large language models (LLMs) to account for page changes and volatility. This means you can write code once, and it adapts to that website if it changes.

Key capabilities of Stagehand include:

* **Reading and Interacting with Page Content:** Stagehand can read page content by parsing the DOM using accessibility trees, interact with, and continue to work even when the page changes.  
* **Natural Language Operations:** You can use natural language to extract data or instruct the browser to take actions. For instance, `page.extract("the price of the first cookie")` or `page.act("add the first cookie to cart")`.  
* **Agentic Workflows:** Stagehand allows you to use a simple agent to automate complex workflows with commands like stagehand.`agent.execute("complete checkout")` or stagehand.`agent.execute("Extract the top contributor's username")`.  
* **Full Control:** By extending the `page` and `context` objects from Playwright, Stagehand gives developers full control over the browser session, allowing for deterministic and repeatable automation while being resilient to unpredictable DOM changes.  
* **Performance-Oriented:**  Traditionally, developers would inspect the DOM manually, right-click elements, test CSS or XPath selectors in the console, and tweak them repeatedly to get automation working using the browser’s DevTools, such as the example below to select a button nested in div’s.   
  `await page.click('div.container > div:nth-child(3) button.primary');`  
  With Stagehand, those selectors are automatically inferred and stabilized, so you can focus on logic instead of fragile DOM paths.

For scaled, production deployments, Stagehand works seamlessly with [Browserbase](https://browserbase.com), allowing you to launch hundreds of browsers at once through an API, with  advanced features like session replay, prompt observability, and captcha solving.

### **MongoDB Atlas: The AI-ready data foundation**

Once Stagehand has done its work, gathering dynamic web content and insights, you need a robust, flexible, and scalable database to store, process, and make sense of this data for your AI applications. This is where MongoDB Atlas shines as the ideal data foundation.

MongoDB Atlas is built to handle today's need for flexible, real-time data processing, unlike traditional databases that are rigid and not designed for an AI-first world.

Here's how MongoDB Atlas becomes the memory and content hub for Stagehand's extracted data:

* **Flexible document model:** Stagehand can extract highly diverse information from websites—from product details and customer reviews to financial reports and real estate listings. MongoDB's flexible document model mirrors the way developers structure data in their code, making it a natural fit for complex, semi-structured, and constantly evolving web data. It eliminates the need for cumbersome schema “day 1” definitions and “day 2” migrations, which are a constant bottleneck in relational databases.

* **Native vector search:** A significant blind spot in traditional data analysis is the vast amount of semi-structured data. MongoDB Atlas addresses this by enabling modern vector search workflows. With Stagehand, you can define the structure in every extract call, catering to a variety of concepts—like product reviews, customer support transcripts, or even images from visually rich documents. Once scraped, they can be vectorized via embedding models (such as Voyage AI's [`voyage-3-large`](https://blog.voyageai.com/2025/01/07/voyage-3-large/)) and ingested directly into MongoDB Atlas. Storing these vector embeddings *next to the original text chunks* along with semi-structured data allows for native semantic search queries directly inside the database, reducing system complexity, development and testing time, and enabling low-latency results.

* **Support for agentic AI architectures:** AI agents often require dynamic evaluation criteria and the ability to enrich feature sets based on diverse data. MongoDB Atlas is uniquely suited to store dynamic criteria as flexible JSON documents and serves as the ideal foundation for agentic architectures, allowing captured web data to be used to generate new features for machine learning models without requiring schema redesigns. Checkout another blog post defining [7 Practical Design Patterns for Agentic Systems](https://www.mongodb.com/resources/basics/artificial-intelligence/agentic-systems).

* **Massive scalability:** Whether Stagehand is scraping millions of product listings or billions of clinical data points, MongoDB Atlas's distributed architecture and flexible schema simplify scaling, handling unpredictable workloads and massive data volumes effortlessly. Companies like [Ubuy](https://www.mongodb.com/company/blog/innovation/ubuy-scales-ecommerce-globally-unlocks-ai-with-mongodb) manage over 300 million products and 150 million annual searches, while [SHARE NOW](https://www.mongodb.com/solutions/customer-case-studies/share-now) handles **2 TB of IoT data per day**, all powered by MongoDB Atlas. Additionally, Browserbase enabled [Structify](https://www.browserbase.com/website/blog/case-study-structify) to eliminate gigabytes of RAM usage, bringing memory consumption on their production web servers down to virtually zero, and can support several thousand concurrent browser sessions, allowing them to scrape tens of thousands of websites in a single campaign with ease.

### **The powerful synergy: Stagehand \+ MongoDB Atlas in action**


![](https://cdn.sanity.io/images/v773ixxh/staging/4a372db6d9815fe687957ace63c421b0ac444cfd-1600x1138.png)

Fig. 2 \- Data flow: From web automation via Stagehand to scalable AI processing in MongoDB Atlas.

Imagine the possibilities when Stagehand reliably harvests information from the web, and MongoDB Atlas makes that data immediately actionable for AI:

* **Customer engagement & product discovery:** Stagehand can extract vast amounts of customer reviews and product information from various e-commerce platforms. MongoDB Atlas stores this data as both operational data and vector embeddings, enabling AI-driven recommendations and intent-driven product discovery, as seen with Ubuy, reducing search times from seconds to milliseconds, but still providing traditional query and insights over data as required by human consumers, enterprise systems and external partners and consumers

* **Real-time market and financial intelligence:** Stagehand can be programmed to extract live financial news, market trends, or competitive pricing data. This real-time stream can be fed into MongoDB Atlas Stream Processing for immediate analysis, enabling dynamic pricing models or allowing financial analysts to sift through dense reports with AI-powered multimodal search for specific trends.

* **Enhanced content curation and recommendation:** For media companies, Stagehand can gather articles, reports, and visual content from diverse sources. MongoDB Atlas, with its vector search and multimodal capabilities, allows for a hybrid search experience, blending keyword precision with AI-driven discovery, delivering hyper-relevant recommendations instantly, much like the [Financial Times](https://www.mongodb.com/solutions/customer-case-studies/ft)' solution.

* **Next-gen inventory classification:** By using Stagehand to collect qualitative metrics from product reviews or social media posts (e.g., customer expectations, re-purchase probability), this unstructured data can be vectorized and integrated into MongoDB Atlas. AI agents can then use this enriched dataset to dynamically classify inventory, transforming reactive inventory management into predictive and customer-centric decision-making.


By combining Stagehand's robust web data acquisition, MongoDB Atlas's flexible and AI-ready data foundation (including vector search capabilities), and MongoDB's ability to expose this data and its management tools to diverse AI applications and platforms, organizations can create a truly seamless and powerful data pipeline for their AI initiatives. This setup empowers developers and AI agents to access, understand, and leverage web data at an unprecedented scale and efficiency.

Ready to build smarter, adapt faster, and scale more confidently? Explore [Stagehand](https://www.stagehand.dev/) and [Browserbase](https://www.browserbase.com/) for your browser automation needs and connect it with a free MongoDB Atlas cluster to power your next AI application – get started with the [MongoDB \+ Stagehand integration on GitHub](https://github.com/browserbase/integrations/blob/main/examples/integrations/mongodb).

Discover the power of browser automation with Stagehand and MongoDB Atlas. Seamlessly extract complex web data, store it in an AI-ready database, and enable intelligent insights at scale for your next-generation AI applications.

Scalable Automation Starts Here: Meet Stagehand and MongoDB Atlas

Browserbase began with a simple yet bold vision: the world needed a new kind of browser specifically designed for automated, AI-driven interactions. In his [founding memo](https://memos.hawkhill.ventures/p/an-internet-browser-for-ai), CEO Paul Klein IV questioned why we were still building web infrastructure for humans when almost half of internet traffic is generated by bots. Combined with the explosion of Large Language Models (LLMs) and autonomous agents, it was clear that the browser needed a fundamental rethinking.

This insight sparked the creation of what would become our core offering: a platform that makes accessing cloud-based browser infrastructure as simple as an API call.

Much like self-driving cars were built to navigate roads originally designed for humans, Browserbase serves as the adapter that enables automated agents to seamlessly navigate the internet. We provide dedicated browsing infrastructure for your agents and automations, an approach that fundamentally differs from consumer-oriented browsers. Our browsers do not live on your device and do not collect your data. Browserbase runs in secure, isolated execution environments where customer data is never shared, sold, or used as training material for third-party AI models.

Browserbase enables developers to effortlessly launch tens, hundreds, or even thousands of browsers simultaneously. Traditionally, managing such infrastructure has been notoriously complex, fragile, and expensive. Without these obstacles, developers can concentrate on core business logic instead of browser configuration and maintenance. 

Spinning up a browser is as easy as:
```javascript
const bb = new Browserbase({ 
	apiKey: process.env.BROWSERBASE_API_KEY 
});

const session = await bb.sessions.create({ 
	projectId: process.env.BROWSERBASE_PROJECT_ID 
});
```

We, however, recognized that providing robust, trustworthy infrastructure was not enough. Developers also needed intuitive ways for agents to interact seamlessly with the web. Existing frameworks were brittle, hard to use, and often required deep expertise to maintain. These technical hurdles served as fundamental barriers to the broader adoption of web automation. Enter [Stagehand](https://www.stagehand.dev/).

Stagehand bridges the gap between precise, step-by-step web automations and fully autonomous browsing agents. On one end of the spectrum, carefully scripted automations offer granular control, high-speed execution, and avoid costly inference steps. On the other end, fully autonomous agents are flexible, resilient to website changes, and continuously improve as the underlying models advance.

![Browser Automation Continuum](https://cdn.sanity.io/images/v773ixxh/staging/6d60d43f19410a79356d21a7078b3449f9166abf-2402x800.png)

Stagehand balances these approaches by allowing users to define individual web interactions in natural language. Users specify actions like "click the login button" or "type my email address," and Stagehand translates these into actionable browser steps. By decomposing complex automations into natural language steps, Stagehand ensures that each AI-enabled action remains focused on a single, unambiguous objective, improving model reliability and accuracy.

Stagehand also minimizes inference costs through its action caching mechanism. As it executes your commands, Stagehand identifies page elements and caches them for future runs, making automation faster and cheaper over time. When websites change, the framework gracefully falls back to AI and rebuilds its cache without disrupting your automation.

Beyond navigation, Stagehand provides a simple interface to extract structured data from any webpage. You define the desired schema, and it intelligently pulls the information you need, whether it's product details, pricing tables, or complex nested data. 

The result is a complete automation system that transforms web interaction and data extraction into plain English instructions that are self-documenting, instantly understandable by any team member, and resilient to the constant evolution of the web. You write what you want to happen, Stagehand figures out how to do it, and then remembers the solution for next time. Here's what this looks like in practice:

```tsx
// Step 1: Navigate to URL
await page.goto('https://www.nasdaq.com/');

// Step 2: Perform action
await page.act('click the earnings link');

// Step 3: Extract data
const extractedData = await page.extract({
  instruction:
    'extract all companies announcing earnings this week with their symbol, company name, market cap, fiscal quarter ending, consensus EPS forecast, and timing (pre-market or after-hours)',
  schema: z.object({
    companies: z
      .array(
        z.object({
          symbol: z.string().optional(),
          companyName: z.string().optional(),
          marketCap: z.string().optional(),
          fiscalQuarterEnding: z.string().optional(),
          consensusEPSForecast: z.string().optional(),
          timing: z.string().optional(),
        }),
      )
      .optional(),
  }),
});
```

The combination of Browserbase and Stagehand dramatically reduces the friction for developers creating automations or providing web access to their agents. Yet despite these advances, a significant technical barrier remained. The legacy applications and workflows that desperately need automation are often managed by professionals focused on their domain expertise: doctors managing patient systems, accountants navigating financial platforms, and operations teams coordinating across multiple platforms.

This gap became crystal clear when we started receiving calls from non-technical builders trying to implement Browserbase and Stagehand automations but struggling to translate their workflows into code. These conversations sparked an insight: what if you could directly harness the full power of browser automation without writing a single line of code?

Enter [Director](https://www.director.ai/)**.** Director takes the powerful foundation of Browserbase and Stagehand and makes it accessible to everyone. Users describe their high-level tasks, such as "download all invoices from last month" or "update inventory across these three platforms," and Director autonomously generates and executes the necessary Stagehand code. Throughout execution, Director leverages Browserbase to perform the task in real-time, self-correct when encountering obstacles, and adapt its approach until the task is complete. It unlocks web automation for the millions of people who know exactly what they need to automate; and they shouldn’t have to learn to program to make it happen.

![How Director Works](https://cdn.sanity.io/images/v773ixxh/staging/1e08a4d9853e877bfe2dece3e00370b13e617e0d-3633x2307.png)

This completes the vision: Browserbase provides the infrastructure, Stagehand offers the intelligent automation layer, and Director makes it all accessible to anyone who can describe their problem. The technical complexity remains under the hood, but the user experience becomes as simple as having a conversation. The result, however, is not just another developer tool or automation framework. It's a push towards a fundamental shift in how humans interact with the digital systems that increasingly dominate our working lives.

Every day, millions of professionals waste countless hours on operational overhead. When we free professionals from clicking through the same workflows day after day, we create space for creativity, strategic thinking, and the uniquely human work that actually matters. The boring work dies so that the interesting work can flourish.

The internet was built for human consumption, but it’s increasingly navigated by agents on our behalf. Browserbase ensures those agents have the tailored, trusted infrastructure they need. Stagehand gives them the tools to navigate complexity. Director extends that power to everyone, regardless of technical expertise. Together, they form a complete ecosystem for web automation that scales from simple tasks to complex workflows, from individuals to enterprise systems.

We are building a future where Browserbase will be remembered for unlocking capabilities that AI alone could not reach. A future where the friction between human intent and digital execution disappears entirely. Where describing what you want is enough to make it happen, and the only limit to automation is your ability to imagine what's possible.

If you’re interested in building the future of web automation with us, [we’re hiring](https://www.browserbase.com/careers).

The browser was built for humans, but half the internet is bots. Browserbase reimagines the browser for AI, providing cloud infrastructure that powers seamless automation at scale. Paired with Stagehand’s natural language automation and Director’s no-code interface, it transforms web interaction into plain English instructions. This isn’t just another dev tool; it’s a new foundation for how humans and AI work online.

What does Browserbase actually do?

I am excited to announce our newest product in the Browserbase family of products. You might know us for Browserbase, our headless browser infrastructure, or Stagehand, our browser automation framework. But today we're introducing Director, which lets anyone automate the web using a natural language prompt. You can now generate repeatable web automation code in one single step.

## A New Direction for Browserbase

Director is a huge step for Browserbase as we move from being just an infrastructure platform to enabling anybody to automate the web. This is challenging for us because we sell to developers and we are developers ourselves. So building a product that's built for everybody—even people not familiar with programming—required us to rethink everything from the ground up.

Now, Browserbase the infrastructure platform and Stagehand the framework are still a top priority for our company. And they're the building blocks that Director uses to help people automate the web.

## How Director Works

You see, Director makes it so you don't have to start writing code to use Browserbase. You can start with the task that you already know—the boring work that you want to automate. And then, using AI by chatting with the application, it outputs a Stagehand script that controls the browser.

Where's that browser running? Browserbase—the best infrastructure platform for running browsers at scale in the cloud.

## Why We Built Director

We built Director because we continue to meet people who had heard about Browserbase and were somewhat technical and familiar with AI, but didn't have the right tools or were using maybe the wrong tools designed for other types of infrastructure to try and build out integrations and try and build automations.

But now with Director, it's never been easier to get started.
## Looking Ahead

We have great plans for this product. And today's announcement is only the very beginning of what we plan to do with it, so stay tuned. 

Director is going to be the best way to get started. And even if it isn't the final version of your feature that automates the web, it's a great way to begin.

Everyone is a developer in the age of AI. And that means everyone can use Director.

I can't wait to see what you build.

I am excited to announce our newest product in the Browserbase family of products. You might know us for Browserbase, our headless browser infrastructure, or Stagehand, our browser automation framework. But today we're introducing Director, which lets anyone automate the web using a natural language prompt. 

Introducing Director: Web Automation for Everyone

Anirudh Kamath

![](https://cdn.sanity.io/images/v773ixxh/staging/5e6c45d71545c4ccbbf13fa003d2bbec8c27cf06-2000x1248.png)

# **A Modern Platform for Intelligent Automation**

Imagine you want to automatically test your app's checkout flow every hour, gather competitive pricing from a dozen websites, or guide new users through your product. Historically, the technology to do this has been brittle, slow, and a frustrating "black box" when things go wrong, making it difficult to trust for important business tasks.

At Browserbase, we’re hell-bent on shining a light on this black box. We power browser solutions for AI leaders like Vercel, Perplexity, and Clay, and our recent Series B round at a $300 million valuation has allowed us to perfect this next-generation platform for web automation. Our open source framework, Stagehand, is the most downloaded framework for automating browsers with AI.

We’re attacking this problem with a complete, modern platform where three powerful components work together seamlessly:

1. **Browserbase** (”the where”) — Think of this as the industrial-scale cloud foundation. We host and manage massive fleets of secure, ready-to-use browsers, so your team doesn't have to worry about servers, scaling, or maintenance.
2. **Stagehand (**”the what”), our open-source toolkit that defines *what* you want to do. Using simple, intelligent commands like `act` (to perform an action) and `extract` (to get data), your team can easily define any workflow.
3. **[NEW] Stagehand API** (”the how”) is the intelligent engine that controls *how* it all gets done. This API is the core of our platform, taking your Stagehand prompts, translating them into precise browser commands, and optimizing their execution on the Browserbase infrastructure for maximum speed and reliability.

It’s this deep integration of the Stagehand framework (the what), the intelligent Stagehand API (the how), and the Browserbase infrastructure (the where) that creates an impactful unified solution.

## Business Impact

This new platform does more than just automate tasks; it changes how you can rely on and learn from your automation efforts. The business impact is clear and immediate.

**You get actionable insights, not opaque logs.** Instead of confusing CDP traces, the Stagehand API creates a clear, human-readable log of every action. You can see exactly what instruction was sent to the LLM, what was returned, and how many cache hits you got, making it incredibly easy to diagnose issues. Your team can now pinpoint and fix problems in minutes, not hours, leading to less downtime and a better user experience.

![CleanShot 2025-06-12 at 15.21.09@2x.png](attachment:e5b5f96c-4edc-47c8-a36f-16ea1eb96a27:8d40ed74-4c0c-4ab4-aa04-427432f20fce.png)

**Your automations learn and heal.** The Stagehand API is designed for efficiency and resilience. For workflows that you run repeatedly, we can securely **cache** actions to make them faster and cheaper over time. If it encounters a small error, like an element not loading instantly, it can often **self-heal** by intelligently retrying the action without any human intervention, making your automations incredibly robust.

**You get built-in intelligence with zero effort.** The world of AI is complex, but your team doesn't need to be AI experts to get expert results. The Stagehand API acts as a navigator, **automatically routing** your request to the best AI model for the job—whether for understanding natural language or analyzing a webpage's layout.

**Better cross-platform support.** The Stagehand API being a fully hosted solution enables better cross-platform support for things like multi-language support, better MCPs, and whatever else you may use AI browsers for!

---

## Engineering Deep Dive


### The Old Way: A "Black Box" Problem

Observability is one of the clearest wins we’ve enabled with the Stagehand API. Previously, in a typical setup, an engineer writes a Stagehand script with a high-level command like `page.act("click the quickstart button")`. That command is translated into a series of very low-level, technical instructions using the [Chrome DevTools Protocol](https://chromedevtools.github.io/devtools-protocol/) that are then sent one-by-one over a websocket to the browser using [Playwright](https://playwright.dev/).

![](https://cdn.sanity.io/images/v773ixxh/staging/e4ae022c7a66dde6e26296a88cc6a41da7959a0a-5462x2190.png)

The critical issue here is a communication breakdown. The browser only receives the low-level CDP commands and has no knowledge of the original, high-level goal. The "why" behind the action is completely lost during the translation process.

As a result, when you try to review or debug a failed automation, the session replay is just a stream of these opaque, technical traces. It tells you what happened at a micro-level, but it’s impossible for a person to look at and quickly understand the business step that failed.

![](https://cdn.sanity.io/images/v773ixxh/staging/286f72963a97316396b4261b8938c2148e1a1d3f-2000x1249.png)

This problem is a direct result of a flawed architecture where all the complex work happens on the user's side. This design is not only inefficient and slow due to every instruction traveling across the internet, but it's also the source of the debugging black box.

### The New Way: Stagehand API on Browserbase

Instead of sending low-level instructions, client-side Stagehand can now send a single, high-level Stagehand command — like "click the quickstart button" — directly to our Stagehand API. 

The Stagehand API receives this request, translates your goal into the necessary low-level CDP actions, and directs a Browserbase browser to execute them.

![](https://cdn.sanity.io/images/v773ixxh/staging/c35ab25765dddf88b881a0836dfd8b390b9f2626-5424x3290.png)

The difference is that all the complex translation work now happens on managed infra, allowing us to actually view meaningful LLM traces. 

![](https://cdn.sanity.io/images/v773ixxh/staging/3171febe11836a18b6af37e7e849554ff0bdb394-2000x1243.png)

***We are now able to get crucial information on what the user is specifically asking for, and we can intelligently handle the request to generate an optimal response!*** 


## Conclusion: A New, Clearer, Headache-Free Path for Browser Automation

By combining our intelligent Stagehand framework with a powerful, purpose-built API, we provide a complete solution that transforms automation from a fragile script into a core, strategic, and reliable part of your business operations. This new approach delivers the simplicity, clarity, and resilience needed to automate with confidence.

Get started now: `npx create-browser-app`

Browserbase introduces the Stagehand API, a modern platform that combines cloud infrastructure, an open-source toolkit, and an intelligent engine to revolutionize browser automation. The platform transforms traditionally brittle and opaque automation processes into reliable business operations by offering improved observability, self-healing capabilities, and built-in AI intelligence.

Introducing the Stagehand API

Iframes (or as I like to call them: cry-frames) are unavoidable in the world of web automation. Iframes are basically just mini-websites embedded in other websites; anytime you've seen "embedded" content like a tweet or YouTube video, that's an iframe. They are simultaneously a super convenient tool for web developers, and a source of existential despair for automation engineers. 

<iframe src="https://link.excalidraw.com/readonly/Rh8AsVAEJUjmVjcPngNk" width="100%" height="100%" style="border: none; min-height: 500px"></iframe>

Writing an automation script for a site loaded with iframes feels like cooking one meal across multiple kitchens simultaneously. Each kitchen appears identical, but surprise! They all have completely different ingredients. Sometimes, there are even secret kitchens hiding inside other kitchens. Handling iframes, even in established browser automation frameworks like Playwright, Puppeteer, and Selenium, is a common point of confusion for people developing web automations. This post is about how Stagehand changed that. 

### A quick aside on Playwright and CDP

Playwright is a browser automation framework developed by Microsoft that lets developers script and control real browsers like Chrome, Firefox, and Safari. It is most popular for end-to-end testing, but its also commonly used for tasks like web scraping, performance monitoring, and automating routine web workflows. Under the hood, Playwright uses the Chrome DevTools Protocol (CDP) [[2]](https://www.notion.so/Iframes-blog-post-2083c11b66148001995acb820c56bbfa?pvs=21)  to talk directly to Chromium-based browsers, but it abstracts away that complexity with a clean, high-level API. For example, instead of manually sending CDP commands, you can just use `page.click('#submit')` or `page.locator('input[name="email"]').fill('user@example.com')`. 

## How Stagehand makes complex web pages LLM-parseable

First, Stagehand uses the `Accessibility.getFullAXTree` CDP command, which returns a structured set of Accessibility Nodes (`AXNode`). These nodes come with rich semantic details about every interactive or structural element on the page, including their roles (like buttons, links, or input fields), names, labels, and states. Here’s an example of an `AXNode`:

```json
{
  "nodeId": "30",
  "role": { "value": "button" },
  "name": { "value": "Apply for this Job" },
  "properties": [
      {"name": "focusable", "value": {"value": true}}
  ],
  "backendDOMNodeId": 30
}
```

Second, Stagehand uses `DOM.getDocument`, to get the full hierarchical structure of the DOM starting from the root node. A DOM node looks something like this:

```json
{
  "nodeId": 42,
  "parentId": 41,
  "backendNodeId": 3,
  "nodeType": 1,
  "nodeName": "BUTTON",
  "localName": "button",
  "nodeValue": "",
  "childNodeCount": 2,
  "children": [...],
  "attributes": [
    "class",
    "_button_8wvgw_29 _quaternary_8wvgw_91    _back_14ib5_49 ashby-job-board-back-to-all-jobs-button"
  ]
}
```

Stagehand then combines these data sources to create a hierarchical string representation of the page. This representation makes the page understandable and actionable for the LLM. Here’s a small snippet illustrating this structure:

```
Accessibility Tree: 
[1] RootWebArea: Careers at Y Combinator | Y Combinator
  [7] scrollable
    [311] div
      [314] banner
        [315] navigation
          [316] div
            [318] link: Y Combinator
              [3] image: Y Combinator
            [319] div
              [321] link: About
              [339] link: Companies
              [351] link: Startup Jobs
              [371] link: Find a Co-Founder
              [377] link: Library
              [383] link: SAFE
              [389] link: Resources
          [419] link: Apply
...
```

Stagehand also uses this information to construct an ID → XPath map. When the LLM selects an element by its ID from this structured representation, Stagehand quickly retrieves the corresponding XPath and executes the desired action.

Yet, [Playwright and CDP don’t always play nicely together](https://github.com/microsoft/playwright/issues/30261#:~:text=Interoperating%20with%20CDP%20is%20not%20a%20goal%20for%20Playwright), particularly around iframes:

- **Managing contexts [[1]](https://www.notion.so/Iframes-blog-post-2083c11b66148001995acb820c56bbfa?pvs=21):** Want to send a CDP command to a specific iframe? Now you have to handle the CDP session context yourself—goodbye Playwright’s magical auto-context switching.
- **Frame IDs:** Playwright doesn’t expose stable IDs for frames. This omission complicates creating composite IDs.
- **Node IDs aren’t unique across iframes:** The backendNodeId provided by CDP, which Stagehand relies upon internally, is not globally unique across iframes. The same ID might point to two entirely different elements in different iframes, causing major ambiguities.

So how can we enable users to `extract`, `observe`, and `act` upon elements in deeply nested iframes?

## Why iframes are so painful

Users just want to be able to write Stagehand code like this:

```tsx
await page.act({
  action: "click the submit button",
  iframes: true,
});
```

Since Stagehand operates primarily on the HTML body tag, it’s relatively easy to resolve a natural language command to a Playwright-compatible DOM selector.

However, with iframes, you don’t know exactly where your element lives, and we don’t want Stagehand users to tear their hair out trying to get the right DOM selectors. A major part of the value of Stagehand is to free users from the tedium of manually finding elements, frames and selectors.

Assuming you know what selectors to use, here is what clicking inside of a nested iframe might look like with playwright:

```tsx
  const inner: FrameLocator = page
    .frameLocator('iframe.lvl1')  // level 1
    .frameLocator('iframe.lvl2')  // level 2
    .frameLocator('iframe.lvl3'); // level 3 – form lives here

  await inner.locator('button[type="submit"]').click();
```

### The Solution: One Tree to Rule them all

Previously, Stagehand only operated on the root DOM. Now, Stagehand systematically traverses through every frame, both same-process and out-of-process iframes (OOPIF). This traversal is done through a depth-first search:

1. We start at the main document and recursively explore each child frame.
2. For each frame, we capture its accessibility tree and calculate an absolute XPath pointing to its iframe element within the parent frame.
3. We construct a snapshot containing each frame’s simplified tree (hierarchical string representation), XPath mappings, and URL mappings.
4. Each snapshot is tagged with a unique EncodedId—combining a frame ordinal and node ID—to guarantee global uniqueness.
5. Finally, these snapshots are stitched together into a single, combined accessibility tree. The resulting unified representation ensures all elements, regardless of nesting depth, are accurately identifiable and interactable by Stagehand.

### **Globally Unique IDs**

To preserve uniqueness of nodes across iframes, we assign each one a simple composite ID: a frame ordinal combined with its backend node ID. This gives us a stable way to distinguish otherwise identical node IDs that come from different frames.

### **Deep XPath Locator**

To reliably find elements within nested iframes, we added a “deep” XPath locator. It works by breaking the XPath into chunks, and every time it hits an `<iframe>` step (like `/.../iframe[2]/../...`), it uses Playwright’s frameLocator() to descend into that frame. It then continues building the path inside that new context. For an XPath like `/html/body/iframe[2]/iframe[1]/div[3]`, the deep locator would handle each iframe hop internally and return a working Playwright Locator for the final element.
	
###  **CDP Session Management**

We updated how CDP sessions are managed by tying each session directly to its corresponding Page or Frame. Internally, we use a WeakMap to store sessions per frame, so we can easily look them up when needed without keeping extra references around. This makes it easier to send CDP commands to the right frame, especially when dealing with nested or out-of-process iframes.

### End-User Impact

- `extract` now sees everything.
- `observe` produces xpaths for elements across all frames.
- `act` can traverse and act upon elements across all frames.

Most of all, you don’t need to think about any of it—unless you want to.


### **What’s Next?**

The next step is to skip empty iframes entirely. If an frame doesn’t have meaningful content, there’s no reason to waste time indexing it.

But for now, we’re just excited that you no longer have to worry about what kitchen your ingredients are in. Stagehand just **lets you cook**.

**If you’ve been waiting for iframe support—this is it.** 

### Footnotes

1. Managing "contexts" is essentially managing the environment or scope in which browser commands run. In CDP, a context usually refers to an individual browsing context such as a specific webpage or iframe, each requiring its own unique CDP session to control it independently. When switching between Playwright frames, Playwright abstracts this complexity by automatically switching contexts behind the scenes. However, Playwright does not directly provide the ability to send CDP commands that are scoped to a frame. Which means you lose Playwright's automated context handling, forcing you to manually track each individual session context for commands to reach the correct iframe.
2. The Chrome DevTools Protocol (CDP) is Chrome’s remote-debugging API.  It exposes the same low-level hooks that power the DevTools UI, but over a public, JSON-RPC API. This allows external programs to inspect, control, and automate Chrome browsers directly. Playwright itself uses CDP internally when interacting with Chromium-based browsers.

Parsing iframes in browser automations just got WAY easier. Discover how Stagehand’s latest update enables seamless AI-enabled actions and extractions across deeply nested iframes—no manual selector wrangling required. Available June 17.

The Browser Blog

Launching Stagehand v3, the best automation framework

Read Article

Why we’re graduating from Playwright

Read Article

Optimize your web automations using Browserbase

Read Article

Training & Evaluating Browser Agents - Our Journey with Google Deepmind

Read Article

Scalable Automation Starts Here: Meet Stagehand and MongoDB Atlas

Read Article

What does Browserbase actually do?

Read Article

Introducing Director: Web Automation for Everyone

Read Article

Introducing the Stagehand API

Read Article

Taming iframes: A Stagehand Update

Read Article