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

Adam McQuilkin

Viv Nepenthe

When Browserbase was founded, we were solving a very specific problem. Browsers are hard to run in production. They’re stateful, long-lived, sensitive to environment differences, and notoriously painful to operate at scale. Hosting Chromium reliably is real infrastructure work, and most teams don’t want to do it themselves.

So we built a platform for hosted browser sessions. You create a session, connect over CDP, run [Stagehand](https://docs.stagehand.dev/v3/first-steps/introduction) or Playwright, and Browserbase handles the rest.

That worked, but over time, we noticed a pattern kept repeating across almost every serious customer.

They still had to run the code somewhere.

Browserbase hosted the browser, but the logic that controlled it lived in a separate service. Teams built worker fleets, cron systems, queue consumers, or workflow engines just to execute Playwright scripts. That runner infrastructure was often harder to maintain than the browser itself.

Worse, it introduced latency and fragility in a very tangible way. The browser might be running in `us-west-2` while your runner is sitting in `us-east-1`, or worse, in a different cloud entirely. Every CDP command and every Playwright/Stagehand action now has to cross that physical distance. In real automations, that boundary gets crossed hundreds of times per run, and the round trip time compounds into seconds of dead time and more surface area for flaky failures.

Browserbase Functions came out of that realization. If we already run the browser and understand its lifecycle deeply, then hosting the code that drives it isn’t a separate concern. It’s the same problem.
### Why we didn’t build *“just another serverless platform”*

We didn’t set out to build a generic functions-as-a-service product. Let’s be honest, there are plenty of those already, and most of them are optimized for short-lived HTTP handlers or stateless compute.

Browser automation is different.

Browser code is stateful during execution, it has tight feedback loops, it often runs longer than a typical request timeout, and it needs direct access to a live browser session. Designing Functions around those constraints shaped almost every engineering decision.

The goal was to make scaling browser automation feel like a single system instead of multiple loosely coupled ones.
### The core abstraction: functions, deployments, invocations

Early on, we ran into a seemingly simple question. *What happens when you update a function?*

If users invoke a function by name and you overwrite the code every time they deploy, then every deploy becomes a production deploy. That’s fine for a toy script, but it breaks down fast once anything depends on it. Real automations are flaky by nature, and *“safe”* tends to mean being able to change code, test it, roll it forward, and step back without accidentally changing what production is doing.

Forcing users to version names manually is just as painful. If you have to rename a function to deploy a new version, then you also have to update every caller, every job, every workflow, and every integration that points at it. The function name stops being an interface and starts being a deployment mechanism.

The solution was to separate identity from executable code.

A function is a stable logical resource. A deployment is an immutable version of that function’s code. An invocation is a single execution tied to a specific deployment.

When you create a new deployment, nothing about production traffic changes. You can invoke the new deployment directly to test it. Only when you explicitly promote it does the function’s production endpoint begin routing to that version. This gives users safe iteration without forcing them to rewire their systems every time they change code.

[Video](https://youtu.be/oNmv5TIugjU)


### Defining functions as infrastructure in code

Once versioning was solved, the next question was how developers should define functions in the first place. 

Most [serverless](https://www.browserbase.com/blog/what-are-serverless-browsers) platforms rely on configuration files, directory conventions, or framework-specific entrypoints. We intentionally avoided that. Browser automation code tends to intertwine logic and runtime configuration. Splitting those concerns across files almost **always** creates drift.

Instead, Functions uses an infrastructure-as-code model where the definition lives alongside the handler itself.

```
import { defineFn } from "@browserbasehq/sdk-functions";
import { chromium } from "playwright-core";

// This is your first Browserbase function!
// You can run it locally with: bb dev index.ts
// Once ready, publish it with: bb publish index.ts
type HNSubmission = {
  title: string | null;
  url: string | null;
  rank: number;
};

defineFn("my-function", async (context) => {
  const { session } = context;

  console.log("Connecting to browser session:", session.id);

  // Connect to the browser instance
  const browser = await chromium.connectOverCDP(session.connectUrl);
  const browserContext = browser.contexts()[0]!;
  const page = browserContext.pages()[0]!;
  // Navigate to Hacker News
  console.log("Navigating to Hacker News...");
  await page.goto("https://news.ycombinator.com");

  // Wait for the content to load
  await page.waitForSelector(".athing", { timeout: 30000 });

  // Extract the first three submission titles
  const titles = await page.evaluate(() => {
    const results: HNSubmission[] = [];
    document.querySelectorAll(".athing").forEach((submission, idx) => {
      if (idx >= 3) return; // only return 3

      const titleElement = submission.querySelector(".titleline > a");

      if (titleElement) {
        results.push({
          title: titleElement.textContent ?? null,
          url: titleElement.getAttribute("href"),
          rank: idx + 1,
        });
      }
    });

    return results;
  });
  console.log(`Successfully extracted ${titles.length} titles`);

  // Return the results
  return {
    message: "Successfully fetched top Hacker News stories",
    timestamp: new Date().toISOString(),
    results: titles,
  };
});

```

This approach has a few important consequences. Your code is the source of truth. You can import helpers, share logic, and structure your project like a normal application. There’s no separate manifest to keep in sync.

Under the hood, this requires a deterministic way to discover which functions exist. 

Functions solves this by requiring an explicit entrypoint. During development and deployment, that entrypoint file is executed. Every call to `defineFn` registers itself in an internal function registry. That registry is then used to generate a manifest describing which functions exist, their configuration, and how they should be invoked.

If your code runs, your functions are discovered. There’s no static analysis step, no AST parsing, and no parallel configuration system. The execution model itself is the source of truth.

### Local development with real browser sessions

One of the biggest sources of pain in browser automation is environment drift. Code works locally, then behaves differently in production. We wanted to avoid that entirely.

When you run Functions locally, we don’t spin up a mock environment. The local dev server still creates real Browserbase sessions using your project credentials. Your code connects to an actual browser running in the same infrastructure it will use after deployment.

```
bb functions dev
```
Invocations hit a local HTTP endpoint, but everything behind that endpoint behaves the same way it does in production, with the same browser, session configuration, and CDP connection model.

That choice dramatically shortens the feedback loop. When something breaks, it breaks where you can see it. When it works locally, it’s much more likely to work when deployed.

### Deploying without breaking production

Publishing a Functions project bundles the code, builds it, and creates new deployments for every function defined in the entrypoint.

The important part is what **doesn’t** happen. Promotion is an explicit step, so production traffic doesn't automatically switch to the new code.

This mirrors how mature deployment systems work. You build first, test, promote intentionally, and then if something goes wrong, rolling back is just a matter of promoting a previous deployment.

The system is designed to make accidental breakage difficult.
### What happens when you invoke a function

Invoking a function is asynchronous by design. Browser automations don’t fit neatly into request response lifecycles, and gaslighting ourselves into thinking otherwise leads to brittle systems.

When you invoke a function, Browserbase creates an invocation record and schedules it for execution. A runner provisions an isolated execution environment that already contains the deployed code bundle. A browser session is created and injected into the runtime.

The runtime selects the correct handler by function name and executes it with a context object that includes session metadata and the CDP connect URL. When the handler completes, the result is persisted and the invocation is marked as completed, errored, or timed out. Because every invocation is tied to a real browser session, debugging flows through the same tooling you already use with Browserbase. You can inspect the session, review logs, and correlate failures without guessing where the code ran.




<iframe
  src="https://blog-animations-functions.vercel.app/"
  title="Functions animation"
  width="100%"
  style="height: 70vh; min-height: 900px; max-height: 1100px;"
  allowfullscreen
  loading="lazy">
</iframe>





### Intentionally chosen constraints

Functions are stateless between invocations, execution time is bounded, and dependencies must be publicly resolvable, but trust me, these constraints are not accidents.

They make the system predictable, reduce operational complexity, and they encourage functions to be designed as units of work rather than long-lived services.

For workloads that require persistent state or complex orchestration, Functions fits cleanly alongside existing workflow engines rather than trying to replace them.

### Why this matters

We’re collapsing an entire class of infrastructure into the platform that already understands browser automation best.

By hosting both the browser and the code that drives it, we reduce latency, simplify deployment, and make production automation easier to reason about. Teams can focus on what their automation does instead of worrying about how it stays alive.

This is the foundation for where Browserbase is going. It has never been easier to run code powering browser agents.

[Can't wait to see what you build](https://docs.browserbase.com/fundamentals/deploying-browser-session).

```
npx @browserbasehq/sdk-functions init
```

If we already run the browser and understand its lifecycle deeply, then hosting the code that drives it isn’t a separate concern. It’s the same problem.

How we built Browserbase Functions

Harsehaj Dhami

Kyle Jeong

**TL;DR**: Browserbase and Prime Intellect have partnered to launch [**BrowserEnv**](https://browserenv.com), a reinforcement learning environment for training and evaluating browser agents on real web tasks.

---

Everyone wants AI models that can actually use the browser to get work done, but most models weren’t trained to interact with real websites. They were trained on static datasets instead of environments where they can practice navigating pages, clicking elements, and completing multi-step workflows. This is why many browser agents look impressive in demos but struggle in real-world use.

The missing piece is a **reliable and scalable training environment.**

Training browser agents requires significant infrastructure when running browsers at scale, interacting with live websites without getting blocked, resetting sessions between tasks, and verifying results. This is the infrastructure frontier labs are already building.

For example, [Microsoft trained and evaluated](https://www.browserbase.com/blog/training-computer-use-models-in-the-real-world-with-microsoft) their computer-use model Fara-7B using Browserbase, which required reliable access to real websites and scalable browser environments for evaluation and reinforcement learning workflows.

> **We have partnered with Prime Intellect to make this infrastructure accessible to everyone with [BrowserEnv](https://browserenv.com).**

BrowserEnv is a reinforcement learning environment designed specifically for training browser agents. It runs on Browserbase, which provides scalable browser infrastructure and access to real websites. Prime Intellect provides the training platform.

Together, they make it possible to train and evaluate computer-use models on real browser tasks without building the infrastructure yourself. All you need is a dataset of tasks.

Researchers and developers can train open models like Qwen or other computer-use models using reinforcement learning, while BrowserEnv handles browser orchestration, task execution, and verification.

## Training Qwen 3 VL on WebVoyager with BrowserEnv

To validate our stack end to end, we fine-tuned [Qwen/Qwen3-VL-8B-Instruct](https://huggingface.co/Qwen/Qwen3-VL-8B-Instruct) on real WebVoyager tasks using BrowserEnv and Prime Intellect. We plugged the ‎`prime/webvoyager-no-anti-bot` environment into Prime’s RL pipeline, so the model could practice real navigation flows across sites like Amazon, Allrecipes, GitHub, Booking, and more without getting stuck on anti bot walls. 

BrowserEnv handled browser orchestration on Browserbase, Prime handled rollouts and optimization, and WebVoyager provided a standardized benchmark of 600 filtered tasks.

We started from the public [WebVoyager environment](https://app.primeintellect.ai/dashboard/environments/browserbase/webvoyager-no-anti-bot) in the Prime hub, switched it to CUA mode, and pointed it at Qwen3-VL-8B-Instruct. The training run used a relatively small but realistic configuration: 200 steps, batch size 32, 8 rollouts per example, learning rate 1e-4, and an oversampling factor of 2, with modest parallelism.

```
model = "Qwen/Qwen3-VL-8B-Instruct"
max_steps = 200

batch_size = 32
rollouts_per_example = 8
learning_rate = 0.0001
oversampling_factor = 2
max_async_level = 2

[sampling]
max_tokens = 512

[[env]]
id = "prime/webvoyager-no-anti-bot"
args = { mode = "cua", viewport_width = 800, viewport_height = 600, keep_recent_screenshots = 2 }
```

In this setup, each training step created or reused a Browserbase session, loaded a WebVoyager task, and let Qwen3-VL act through coordinate based CUA primitives while a verifier judged task completion and produced reward signals. Over the course of the run, the model improved on multi step tasks such as searching, filtering, and extracting information from live pages, rather than just static HTML.

The output of this training run is a [LoRA](https://arxiv.org/abs/2106.09685) adapter that can be easily deployed to run on the [Prime Intellect platform](https://app.primeintellect.ai/dashboard/deployments). 


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


This training workflow is reproducible by anyone with access to a Browserbase and Prime Intellect account. You can even start from the same ingredients we used: BrowserEnv on Browserbase, the WebVoyager no anti bot environment in Prime, and an open vision language model like Qwen3-VL. 

Frontier labs are already training browser agents this way, and now anyone with access to the internet can do the same.

BrowserEnv is generally available today, learn more at [browserenv.com](https://browserenv.com) and start training your own browser agents.

<custom-cta text="Train your own custom model" button_text="Learn more" button_link="https://browserenv.com"></custom-cta>

We're excited to announce our partnership with Prime Intellect to allow anyone to train browser agents.

General-purpose models aren't optimized for your bespoke workflows, BrowserEnv lets you train one that is.

Checkout browserenv.com and train your own custom model.

Introducing BrowserEnv: Train browser agents on real websites

Thomas Katwan

TL;DR: We’re launching Browserbase Search, a simple API that lets agents search the web and get back relevant URLs to start navigating. It’s powered by Exa and natively integrated into the Browserbase platform.


-----

Your agents need to search the web, just like humans.

That sounds simple, but it turns out to be one of the first problems every agent runs into. When an agent doesn’t know the exact URL it needs, it has to figure out where to start. That usually means running a search. 


![](https://cdn.sanity.io/images/v773ixxh/staging/6626d1264f81f414dc7f8ce55100c845a9ab8ec4-820x922.png)

We’ve seen this pattern over and over again across Browserbase workloads. In fact, during our last billing cycle, we saw 4.5 million requests to google.com run through our [proxies](https://docs.browserbase.com/features/proxies#proxies). Search is one of the most common first steps agents take before navigating to the page where real work happens.

Since we already provide the agent infrastructure to interact with the web, we thought it made sense to bring search into the platform as well. 

So we built Browserbase Search, a Search API optimized for agents, accessible via our REST API, TypeScript and Python SDK with AI-native formats such as JSON, Markdown or HTML.

## Powered by Exa
To power the search layer, we have partnered with [Exa](https://exa.ai/), which has built one of the best search APIs designed specifically for AI agents

Exa’s models are optimized for navigational queries, which typically run when agents are looking for a specific page or resource on the web. That makes it a natural fit for the types of workflows our customers and developers are already building on Browserbase. 

By combining Exa’s search with our browser infrastructure, agents can now search for where they need to start and immediately navigate to it in just a few lines of code.

## The API
The Search API is intentionally simple. You send a query and get back the relevant results.

```
import { Browserbase } from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const searchResponse = await bb.search.web({
  query: "a web browser for ai agents",
  numResults: 10,
});

```
Response
```
{
  "requestId": "string",
  "query": "a web browser for ai agents",
  "results": [
    {
      "id": "string",
      "url": "string",
      "title": "string",
      "image": "Image URL if available",
      "favicon": "Image URL if available",
    }
  ]
}

```
That's it.

Every result returns a page `url` and when available, a `title` and `description`. Results are ranked by relevance, and optimized for navigational queries.
An agent might search for relevant pages, fetch their contents, and then decide whether it needs to launch a browser to interact with a page.

Search → (Fetch) → browse. 

Search helps the agent discover where to go, [Fetch](https://www.browserbase.com/blog/fetch-api) retrieves the page content, and browsers handle deeper interaction. Together, these primitives make it easier to build agents that can understand and navigate the web all in one platform. 

## Get started

Search is available on all plans with 1,000 free searches per month, included. [Read more in the docs](https://docs.browserbase.com/features/search). Happy searching! 





We’re launching Browserbase Search, a simple API that lets agents search the web and get back relevant URLs to start navigating. It’s powered by Exa and built directly into the Browserbase platform.

Introducing Browserbase Search

## Introducing Fetch: the simplest way to read the web

TL;DR: We launched a Fetch API for Browserbase. Give us a URL and we return the page content with no browser session required. It’s fast, cheap, (~$1 / 1k pages), and perfect for agents that just need to read the web.


-----


Browserbase was built to help AI agents automate the web. It lets developers run browsers in the cloud to click buttons, fill forms, navigate applications, and automate complex workflows. But over time we noticed something interesting: many developers were spinning up full browser sessions just to read the contents of a page.

They weren’t interacting with the site and they didn’t need to click anything or run automation. They just wanted to see what was on the page.

Sure, launching a browser for this works, but it’s not the right primitive. Spinning up a full browser session to retrieve a page is a bit like killing a mosquito with a rocket launcher. It solves the problem, but it introduces unnecessary latency, cost, and complexity.

So we built the primitive that was missing: **Fetch**.

## Reading the web is often the first step

Agents frequently need to gather information from the web before they take action. They read documentation, inspect GitHub repositories, analyze product pages, and gather context before deciding what to do next.

If you’ve used tools like Claude Code, you’ve already seen this pattern. Before executing complex actions, the model often fetches the contents of a page to understand what’s there. It’s the fastest way to make sense of the internet.

Until now, doing this with Browserbase required launching a browser session. That meant additional infrastructure overhead even in cases where the task was simply retrieving the page content.

The Fetch API solves this by letting you retrieve web content (both html and image) directly from Browserbase infrastructure without creating a browser session.
## Fetch a page with one request

The Browserbase Fetch API is intentionally simple. You provide a URL, and the API returns the page content.

```typescript
import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY! });

const response = await bb.fetchAPI.create({
  url: "https://httpbin.org/get",
});

console.log(response.statusCode);
console.log(response.content);


```

The response:
```
{
   "status_code":200,
   "headers":{
      "Age":"6449",
      "Allow":"GET, HEAD",
      "Content-Encoding":"gzip",
      "Content-Type":"text/html",
      "Server":"cloudflare",
      "Vary":"Accept-Encoding"
   },
   "content":"<!doctype html>...",
   "content_type":"text/html",
   "encoding":"utf-8",
   "id":"f47ac10b-58cc-4372-a567-0e02b2c3d479"
}
```

That’s the entire API. :)

## Fetching pages reliably is harder than it sounds

At first glance, fetching a page might seem trivial. After all, tools like `curl` have existed for decades. But modern websites introduce complications that make reliable page retrieval more difficult than it appears. Redirects, inconsistent encodings, unusual headers, all make it harder to consistently retrieve the real content of a page.

Our goal with the Browserbase Fetch API is simply, **always return the page content**.

The API supports a few optional parameters such as output formatting and timeouts, but the main priority is making sure developers can depend on it to retrieve the page they requested. We’ve prioritized reliability over a catalogue of shiny features.
## Fetch before you browse

Fetch becomes particularly powerful when used alongside browser automation.

Many agent workflows follow a pattern like this: `search → fetch → decide → browse` .

An agent first searches for relevant pages. It then fetches their contents to determine whether the page is useful. Only when deeper interaction is necessary does it launch a browser. 

This approach significantly reduces both latency and cost. Most pages don’t really require full browser automation. They simply need to be read.

## Making Browserbase workflows cheaper

Running browsers is expensive infrastructure. Fetching pages is much lighter.

Because of that, we’ve just made Browserbase 10x cheaper, pricing the Fetch API at $1 per 1,000 pages. This allows agents to inspect far more of the web before deciding where to spend browser resources.

In practice, this makes many Browserbase workflows dramatically cheaper while also improving performance. Win-win!

## The web is still the biggest API

The open web contains more data, workflows, and knowledge than any single API ever will. Documentation, research, software, and marketplaces all live there. Agents should be able to use that information easily.

Fetching a page is often the first step in doing so, and now the Browserbase Fetch API makes that step simple.

**The Browserbase Fetch API is available today. Give it a URL, and we’ll return the page.**

Get started with the docs [here](https://docs.browserbase.com/features/fetch).

We launched a Fetch API for Browserbase. Give us a URL and we return the page content with no browser session required. It’s fast, cheap (~$1 / 1k pages), and perfect for agents that just need to read the web.

Introducing Fetch: the simplest way to read the web

Sameel Arif

Web automation is repetitive.
Most web automation runs the same actions thousands of times, and pays full price every time.
We recently shipped caching in Stagehand. Here's how it works under the hood, why we built it, and where it breaks.

Browser agents are powerful, but they are often paying LLM costs over and over again for actions that are effectively identical. Every innovation in agent performance has leaned towards making agents more “human”: better context management, memory, tools, and more. But in many web automation workloads, the winning move is the opposite: avoid reasoning entirely.

Stagehand’s Caching does this by caching the resolved selector for an action (not the whole agent), then validating the page still matches with high confidence before executing. In repetitive workloads, this can translate into performance improvements **as high as ~80%**, measured as % speedup across two sequential runs: the first run inserts into the cache, and the second run reads from cache and executes without an LLM call.
> Key idea: the LLM is used to make an action once. After that, the system tries to reference past work and just execute.

## What makes web automation repetitive
In practice, most high-volume web automation doesn’t look like a robot exploring the open internet.

It’s actually quite boring. Most production workloads repeat the same few flows: the same form filled thousands of times, the same buttons clicked across a fixed funnel, and the same fields extracted from the same page templates.

That repetition becomes expensive when each run starts from “first principles” and asks an LLM to interpret the UI again, and again, and again. You pay for it in latency (the round-trip to the model), cost (tokens), and non-determinism (the model doesn’t always make identical decisions even when parameters don’t change).

Caching is an attempt to collapse that repeated work into a reusable artifact.
## What “Caching” means (precisely)
Stagehand performs an atomic action (extracting a field, clicking a button, filling an input). If that run succeeds, we store a cache entry on Browserbase servers that includes the selector (and supporting metadata) needed to perform the same action again.

On a future request, Stagehand tries to match the request and current page to an existing cache entry. If it matches, the SDK executes using the cached selector without calling an LLM. If it does not match, it is a cache miss, and Stagehand executes normally and then writes a new cache entry.
> **What we cache:** selectors, prompts, action configuration.
**What we do not cache:** Passwords, API keys, or any other sensitive information.

A cache hit happens when a future request to the Stagehand API can reproduce the **same cache key** for the action. At a high level, that means two things are stable: the request inputs (action configuration and parameters) are equivalent, and the page snapshot is equivalent enough that it produces the same snapshot fingerprint.

This framing matters because a lot of the work is done for us by the DOM snapshot. Changes in the page text, images on the page, structure of the elements, state, etc. all contribute to a unique representation of the DOM - which then changes the hash we use as a key for the cache.

## The fast path: what happens when you make an action
When Stagehand receives a request to make an action, it first checks a server-side log of *previous actions for the same Project ID*.

Under the hood, we hash the full set of inputs into a fixed-length sha256 digest. This keeps lookups fast and consistent even though the underlying inputs are structured and verbose.

What that means in practice is: we take the structured cache-key components (method, normalized URL, DOM hash, project scope, plus a few method-specific fields), serialize them into a canonical string, then sha256 that string.

![](https://cdn.sanity.io/images/v773ixxh/staging/fe0e3e421a2e9f215b33128a76f06c3ab4a4b7d9-1196x1292.png)

We only include fields that change the semantics of the action. Optional nested objects (like schema or model config) get normalized and hashed (for example, `schema_sha256`) so the final key stays compact.

**Example: two duplicate action requests (same cache key):**


![](https://cdn.sanity.io/images/v773ixxh/staging/5b947f476472e865e42a9a38bf3aaa151797457c-1264x332.png)

On a cache hit, the goal is simple: avoid the LLM and execute deterministically.

Concretely, the request is normalized (URL + action config + variables), hashed, and used to query for candidate entries scoped to the Project ID. For each candidate, Stagehand passively compares the current page snapshot fingerprint against what the entry was recorded against. If that comparison clears a safety threshold, Stagehand reuses the stored selector and executes the action directly via the SDK.

The core challenge in validation isn't detecting change, it's deciding what change matters. A page can shift in dozens of ways between runs. The question is whether the selector you cached still points at the right thing, with high enough confidence to skip the model entirely.

This is where the speedups come from. You still have browser execution time, but you skip model time and model cost.

If this passive check detects drift, we do not try to “force” the cache entry to apply.

Instead:

1. The request becomes a cache miss.
2. Stagehand executes the action normally.
3. Stagehand inserts a new cache entry based on the new state of the page.

This bias towards safety is important. At the beginning, it’s important to optimize for accuracy over hit rates. A wrong cached click is worse than a slow click.
## Variables: the unlock for high reuse
One of the most common repetitive workflows is filling out structured forms. Job applications are a perfect example: the shape of the form is the same, and the interaction sequence is the same, but the values change per person. With variables, the same selector can be cached across multiple runs that differ only in the value being typed.

**Example:**
```
// Cannot be re used for different values
await stagehand.act({
  action: `type ${profile.email} into the email input`,
});

// Cache HIT
await stagehand.act({
  action: "type %email% into the email input",
  variables: {
    email: profile.email,
  },
});
```
The important constraint is that the page must still validate as “the same enough” page for the selector to be safe.
## Where caching doesn’t work (and why)
Caching is not magic. Some pages simply don’t repeat in a way that’s safe or useful.

In practice, caching breaks down on pages that do not repeat cleanly. Sites that render dramatically differently on every load tend to miss. URLs that are randomized or overly parameterized can defeat normalization and miss. And some pages change in ways that are meaningful even when the DOM does not change in an obvious way, which is one of the harder classes of problems for any passive equivalence check.
## Constraints
Today, cache entries are project-scoped (by Project ID), stored server-side on Browserbase, and valid for 48 hours. These constraints keep the system simple and safe while we learn where reuse is highest.
## Measuring performance (and what “~80%” means)
The cleanest way we’ve found to talk about performance publicly is to run the same action twice, sequentially. The first run inserts into the cache. The second run reads from cache and executes without an LLM call. We report the improvement as % speedup from run 1 to run 2.

This number varies heavily by workload. Repetitive, template-heavy flows can see extremely high hit rates and large speedups. Workloads that constantly visit new sites or run never-before-seen actions will not benefit as much.

![](https://cdn.sanity.io/images/v773ixxh/staging/57032003b9be1f5c78fd17420a616db004ffb7ef-3670x1880.png)

## What's next
In plain terms: over time, we want to make cache entries reusable across a wider set of equivalent requests, without compromising safety.

Get started with `npx create-browser-app` or [read more in our documentation](https://docs.stagehand.dev/v3/best-practices/caching).

We recently shipped Caching in Stagehand. Here's how it works under the hood, why we built it, and where it breaks.

We built caching into Stagehand. Here's how it works

Erika Bricky

## How Amplitude Transformed Sales Demos with AI-Powered Browser Automation

**Customer Since:** April 2025

### The Challenge: Generic Demos Weren't Closing Enterprise Deals

Amplitude is more than just a product analytics platform, it is an AI analytics platform. Beyond event tracking, they offer session replays, in-app guides and surveys, and web experiments. Using data and tools across the entire platform, their Global Agent provides access to real-time analysis and recommendations with a simple prompt so teams can focus on acting rather than digging through dashboards. It is a complete platform serving everyone from C-suite executives to junior engineers. But their sales team had a problem.

Sales engineers were running 5-10 demos per week with spoofed analytics data created from Google Sheets mappings. The process was simple enough: fill out a spreadsheet, upload it to an internal system, and generate a project. But the demos only showed analytics, not session replays, guides, or experiments. And crucially, they weren't customized to resonate with each customer's specific use cases.

"Our sales engineers were stuck with just analytics," says Boogie Cigdemoglu, who is the lead engineer on Demo Operations at Amplitude. "They had to explain the rest of the platform and the AI products by talking about it. You only get a small sense of what's possible when you can't actually show it."
For generic prospects, this approach worked. For strategic enterprise accounts? Not so much.

"We're playing in the bigger league of enterprise strategic customers now," Boogie explains. "For strategic customers, you really need to resonate with their unique use cases. By showing them what their business will look like when they start using Amplitude."

### The Solution: Custom Websites + AI-Powered User Simulations

When Boogie joined Amplitude's demo operations team in January 2025, his manager Kelson Warner recommended he try Browserbase and their open source framework Stagehand. The value proposition was immediate: focus on impact instead of infrastructure. 

"Not worrying about all that infra work and focusing directly on the impacts I can bring to our sales teams was a huge unblock," Boogie says.

Here's how the new workflow works:

**1. Build custom demo websites** using AI coding tools (Claude Code, Cursor, Bolt, Lovable) that resemble the prospect's actual product

**2. Define customer journeys** relevant to the prospect's business, like a car buyer customizing a vehicle and requesting a quote, or a loyalty program visitor who abandons a form mid-scroll

**3. Use Browserbase + Stagehand SDK** to simulate realistic user behavior at scale

**4. Inject custom logic** between AI-generated actions to produce event data, session replays, guides data, and surveys

**5. Generate full platform AI-native demos** across Amplitude's entire platform, not just analytics

![](https://cdn.sanity.io/images/v773ixxh/staging/f3d8817103b140774d0e4f0211914a7df2ff7fe8-2814x2142.png)


"I'm using Stagehand to simulate realistic user journeys," Boogie explains. "We have a ton of user journeys. I first do an AI run with Stagehand SDK, get the log of what the bot run was on the website, then have another AI logic that fills extra things in between these actions so you generate event data, guides and surveys data, session replay data, and experiment data that empowers the Global Agent living in Amplitude."

The result? Sales engineers can now request custom demos through Slack, and Boogie's system generates environments that show exactly what Amplitude would look like integrated into that specific customer's product.


### The Results: From Push to Pull

**40+ custom demo environments built for enterprise prospects using AI-powered browser automation.**


**5,600+ simulated user journeys generated full-platform demo data from session replays to AI-powered insights.**

**$10M+ in influenced pipeline across strategic accounts.**

The qualitative impact has been unmistakable.

Boogie tells us that, "The sales engineers have been asking, ‘we need more. Can you give us more?' This is changing the way we do our demos to customers. The customers want to get their hands on the product as soon as possible."

What started as Boogie pushing new capabilities to the sales team has turned into constant pull from eager sales engineers. One particularly talented sales engineer recently requested 5,000 bot runs to simulate highly specific funnels for a strategic demo, custom scenarios impossible to generate with the old Google Sheets approach.

"It was a push initially and now it's just a pull," Boogie says. "Everyone's just asking for more. I'm not actually coming up with new ideas anymore. I'm flooded with requests and I'm getting to choose."

The demand has grown so quickly that Boogie started on Browserbase's free plan in April 2025, upgraded to a small plan, and is now scaling to a larger plan to meet sales team needs. He's building a self-serve orchestrator so sales teams can generate custom demos autonomously.

### Why Browserbase: Product Meets Culture
### 
When asked about the best part of working with Browserbase, Boogie doesn't talk about features first.

"Sarah is a mind-blowingly helpful person, extremely kind," he says of his Browserbase account executive. "The way Sarah has built a relationship between me and Amplitude causes me to think of more use cases for Browserbase beyond the scope of what I do."

In tandem with the strong relationships the teams have built comes lightning fast execution.

"Every time I sent a bug ticket to our Browserbase-Amplitude Slack channel, the problem was solved in less than five hours. I cannot believe it. It's mind blowing how quick the turnaround is."

For Boogie, the combination of responsive engineering, helpful customer support, and a product that just works has created something rare: genuine trust.

"It's not about the product, it's about the people," Boogie says. "I don't actually care about the product that much. The product is going to change. A year from now, Browserbase will look very different. But if that wholesomeness and attention to detail, this obsession with the customer remains, it'll be a product that I want to use."

He puts it even more directly: "I'm not upgrading for the product. I'm upgrading for the culture."

### Looking Forward
As Amplitude continues winning strategic enterprise accounts, Boogie's demo automation system powered by Browserbase will scale alongside them. The next evolution involves making the system fully self-serve, allowing sales engineers to generate custom demos on demand without bottlenecking through Boogie's team.

"I've been able to map the direct impact of our work with Browserbase to opportunities on Salesforce," Boogie says. "I hope this will keep growing as we measure the impact on the sales cycle."

For companies looking to elevate their sales demos beyond static data and generic scenarios, the Amplitude story offers a blueprint: combine AI-powered browser automation with custom environments to show prospects exactly what your product looks like in their world.

Ready to transform your sales demos? Get started with [Browserbase](https://www.browserbase.com/sign-up) or [talk to our team](https://www.browserbase.com/contact) about your use case.



How Amplitude Transformed Sales Demos with AI-Powered Browser Automation

Jane Manchun Wong

AI browsers and web agents are crossing a threshold. With the advent of AI going agentic, AI browsers are extending beyond summarizing webpages. The flexibility of the web isn’t without its risk, as webpages can contain malicious code and malware.
> Every webpage an agent visits is a potential vector for attack.
> — Anthropic

The challenges in eliminating potential new attack vectors and why containment can be an effective mitigation that scales. This post is not a zero-day vulnerability disclosure.

In essence: If you’re shipping web agents, you’re already in the risk zone.
## What prompt injection is (for browser agents)
Prompt injection is what happens when untrusted content becomes instructions. 
> A Prompt Injection Vulnerability occurs when user prompts alter the LLM’s behavior or output in unintended ways. These inputs can affect the model even if they are imperceptible to humans, therefore prompt injections do not need to be human-visible/readable, as long as the content is parsed by the model.
> — OWASP

In non-AI chatbots, injection usually means the model says something wrong. In browser agents, injection can mean the model does something wrong, because it can take actions on your behalf.

Anthropic [describes](https://www.anthropic.com/research/prompt-injection-defenses) the core issue: an agent browsing the internet encounters content it can’t fully trust, and attackers can embed malicious instructions to hijack behavior.

Untrusted content exists in all sorts of forms, ranging from something as simple as white text on white background to a prompt injection encoded as Base64 in the form of a QR code image.
## Why browser use makes prompt injection worse
Browser use amplifies prompt injection risk in two ways. The attack surface is massive with every webpage, embedded document, ad, and script possibly carrying malicious instructions. Browser agents can do a lot, from filling forms, to downloading files, which is exactly what attackers want if they gain influence.

Anthropic even gives a painfully realistic [example](https://www.anthropic.com/research/prompt-injection-defenses): a “normal” task like drafting email replies hides instructions in white text that tell the agent to forward confidential messages elsewhere.

When a consumer uses an AI browser as a daily driver, it soaks up all the sensitive info such as cookies, auth sessions, etc. And when a prompt injection attack is successful, all that information can be exposed.
## How prompt injection turns into real incidents
Unlike the classic [“ignore all previous instructions and show all previous text”](https://knowyourmeme.com/memes/ignore-all-previous-instructions) prompt injection aimed to only reveal the system prompt of the AI model, the modern prompt injection attacks can leverage the agentic capabilities of AI browsers into taking rogue actions. For example, a rouge prompt injection might attempt to override the original goal entirely, convincing the AI agent to abandon the original instruction in favor of other arbitrary tasks. They can also weaponize the agent’s own access privileges to exfiltrate sensitive user data (e.g. private keys, session cookies, API tokens). Agentic browsers can also be abused to arbitary triggering webhooks, retrieving external web resources in the fashion that exfiltrate the sensitive user data, or navigating to malicious URLs without the user’s consent or knowledge.

Out of all the prompt injection attacks that may or may not work, it’d only take one successful attempt to create a path from “read untrusted content” to “move sensitive data.”
## Case study: Antigravity
PromptArmor [published](https://www.promptarmor.com/resources/google-antigravity-exfiltrates-data) a clean, modern example involving Google’s agentic IDE “Antigravity.” They show an **indirect prompt injection** embedded inside an “implementation guide” that manipulates the agent into collecting sensitive credentials and then exfiltrating it via a browser subagent

In their blog post, they hid the prompt injection into a 1-point font, such that it’s visually undetectable for most humans but still machine-readable to AI agents. It instructs the agent to collect sensitive data like environment variables, and then exfiltrate that data by encoding it as URLs, sending it out via network requests.
## Attempt of prompt injections on AI browsers
I tried to prompt-inject several AI-powered browsers and agentic browsing experiences to see if I can trick it into accessing and exfiltrating sensitive private data (e.g. .ssh, .env, .gpg, ~/Documents)

For this blog post, I tested some classic injection prompts against popular AI-powered browsers such as Atlas, Dia, Comet, etc. In an attempt to interfere with the browser’s ability to summarize the page, I sneaked it in somewhere on my LinkedIn profile, first attempt in plaintext, second attempt in Base64-encoded text.

[Video](https://youtu.be/ypX469AaXbA)

It turns out, as of the time of writing, AI-powered browser vendors have since caught on security concerns like prompt injections and have basically ignored that text, identifying it as a manipulation attempt.

Still, like any security problems, this will always be a cat vs mouse game. Threat actors will come up with newer, more creative prompt injections, and browser vendors will then patch it. As Anthropic [mentioned](https://https://www.anthropic.com/research/prompt-injection-defenses), despite [new protections against prompt injections](https://www.anthropic.com/news/next-generation-constitutional-classifiers), no browser agent is immune from potential attacks. The success rate is low, but still non-zero and carries meaningful risk.
## Our approach: containment
We could, however, isolate the web session through containment.

At Browserbase, the [zero-trust security posture](https://docs.browserbase.com/guides/security) assumes the risk of the webpage being compromised, and contains the potential damage. Each browser session runs in a **dedicated VM** through hardware virtualization isolation. Network isolation via isolated subnets + strict firewalls to prevent lateral movement. Browser runtime is only used once per session and the VM is killed and recreated after each session. No GPU access to avoid shared GPU memory attack risks

In the unfortunate event where a zero-day vulnerability is executed in Browserbase, instead of having a compromised agentic web browser and exposing sensitive data (e.g. `.env`) to threat actors, the potential damage is contained within a virtual machine spawned specifically for the browsing session only, which usually doesn’t have org-wide access to sensitive information.
## Safe automation with Stagehand
One of the failure modes of agent stacks is that the model behavior is not well-defined, letting them freestyle across the internet and improvise its workflow as it goes, leading to nondeterministic behavior.

Browserbase positions Stagehand as “safe, deterministic automation,” and we believe it matters as a guardrail for AI web browsing. The workflows are atomic and auditable, rather than one giant opaque agent blob difficult for reviews. We do use LLM as a fallback option only in case a specific step of the workflow runs into edge cases, for example, an attempt of prompt injection attack. Our prompt templating lets hoists sensitive data as parameters, to be injected at runtime, minimizing exposure.
## You can’t patch the web
At the end of the day, it is the World Wide Web.

Prompt injection is a natural consequence of mixing instruction-following models with untrusted content and then giving them tools.

You could reduce risk with better models, better detection, and better red teaming. But the mitigation that scales is containment: isolating the browser, constraining what it can touch, and keeping failures survivable.

Our bet behind Browserbase and Stagehand is through secure browser infrastructure and deterministic automation, keeping the scope of potential damage small when (not if) the web tries to talk your agent into going rogue.

Start building!
```
npx create-browser-app

AI browser agents dramatically expand the attack surface of the web, making prompt injection a real security risk. This post explores how prompt injection turns into real incidents and why containment, isolation, and deterministic automation are the only scalable defenses.

Your AI browser is one malicious <div> away from going rogue

Paul Klein

The best agents run on Vercel.
Now they get the best browsers too.

Today, we’re launching [Browserbase](https://browserbase.com) on the [Vercel Marketplace](https://vercel.com/marketplace/browserbase). With a single API key, Vercel customers can give their AI agents access to real, production-grade browsers without even running browsers themselves.

Modern agents can now do a lot more than just calling APIs. They browse the web, logging into dashboards, scraping dynamic pages, filling out forms, and interacting with sites built for humans. And while it’s easy to spin up a headless browser locally, doing it [reliably in production](https://www.browserbase.com/blog/what-are-serverless-browsers) is a very different problem.

The problems scream at you when the headless setups break, bot detection gets in the way, and when observability is limited. Not to mention [serverless](https://www.browserbase.com/blog/what-are-serverless-browsers) platforms aren’t optimized for running long-lived, stateful browser processes.
That’s where Browserbase steps in.
## Browserbase on the Vercel Marketplace
With Browserbase now available on the Vercel Marketplace, agents running on [Vercel Sandbox](https://vercel.com/docs/vercel-sandbox) can connect directly to remote browsers over CDP instead of launching a local browser inside their runtime. Your agent logic stays on Vercel’s agent infrastructure, while the browser itself runs on infrastructure built for browser automation.

In practice, this separation is what makes web agents viable in production. We get real browsers that behave like real users, independent browser scaling that doesn’t face serverless constraints, and complete session-level visibility into what your agents are doing on the web. Everything is wired together through Vercel Sandbox and the [AI Gateway](https://vercel.com/ai-gateway), and provisioned with a single API key.
## Browsing the web without getting blocked
Of course, **running** browsers is only half the battle. The other half is staying online.

That’s why we’re also announcing a [Web Bot Auth partnership](https://www.browserbase.com/blog/browserbase-stytch-web-bot-auth) with Vercel. Browserbase now runs as a trusted agent, allowing participating websites to recognize legitimate, AI-driven browsing. Instead of constantly tripping bot detection or solving CAPTCHAs, agents can browse the web in a way that’s observable and allowed.

The result is more resilient automation and fewer workarounds, so agents can focus on actually doing useful work on real websites.
## A dedicated browser layer for agents on Vercel
Together, this partnership extends Vercel’s agent cloud with a dedicated browser layer. Agents run where they should, and browsers run where they’re observable and reliable. Authentication, provisioning, and billing live right in the Vercel Marketplace, and everything works together out of the box.

Browserbase is available today for Vercel customers building agents that need to interact with the real web. If your agents need to browse, click, log in, or automate real sites, this is the missing piece that makes them production-ready by default.

Get started today at https://vercel.com/marketplace/browserbase


Today, we’re launching Browserbase on the Vercel Marketplace. With a single API key, Vercel customers can give their AI agents access to real, production-grade browsers without even running browsers themselves.

Browserbase is launching on the Vercel Marketplace

Browserbase makes it easy to run real browsers in production. But until now, using Browserbase still meant running your automation code **somewhere else.**

That usually meant maintaining a second system just to keep [Stagehand](https://docs.stagehand.dev/v3/first-steps/introduction) or Playwright scripts alive. 

We’ve launched Browserbase Functions to remove this layer completely.

Functions let you deploy agents and automations directly to Browserbase and run it next to the browser session it controls. You define, deploy, and invoke a function, and Browserbase handles execution, browser lifecycle, and results as one system.

For teams, that means fewer moving parts and less infrastructure to operate. For automations, it means lower latency and fewer failure points.

Functions are built for browser workloads, not generic request handlers. They support real [Stagehand](https://docs.stagehand.dev/v3/first-steps/introduction) or Playwright code, long-running executions, and asynchronous invocation. Each function runs with a dedicated Browserbase session and returns structured results when it completes.

Deployments are versioned by default. New code doesn’t affect production until you explicitly promote it, so you can test changes safely without rewriting endpoints or workflows.

Local development works the same way. When you run Functions locally, your code connects to real Browserbase browser sessions using your credentials. There’s no mock environment to drift from production behaviour.

Functions are available today for TypeScript!

If you’re already using Browserbase, you can move existing automations into Functions and stop managing separate runner infrastructure. If you’re new, Functions give you a single place to run both the browser and the code that drives it.

You can get started by initializing a Functions project:

```bash
npx @browserbasehq/sdk-functions init
```

[Here's the docs](https://docs.browserbase.com/features/functions). 

If you want a deeper look at how Functions works and the engineering decisions behind it, [we’ve published a full technical deep dive as well](https://www.browserbase.com/blog/building-browserbase-functions).

Browserbase Functions are the next step toward making browser automation faster and easier to run in production.

Functions let you deploy agents and automations directly to Browserbase and run it next to the browser session it controls. You define, deploy, and invoke a function, and Browserbase handles execution, browser lifecycle, and results as one system.

Introducing Browserbase Functions

Peyton Casper

Today, Browserbase is excited to announce our collaboration with [Fingerprint](https://fingerprint.com/) on the launch of **Authorized AI Agent Detection**, a new ecosystem designed to establish trust and identity for AI agents operating on the web. As AI-driven automation becomes a core part of how businesses operate online, distinguishing legitimate, permissioned agents from malicious bots is no longer optional. This partnership is an extension of our work with Cloudflare, Stytch and other Bot Protection platforms to make agent identity a foundational part of the web.

Browserbase enables developers and enterprises to run AI agents in real, production-grade browsers for use cases like logistics tracking, data access, and workflow automation. Through Fingerprint’s signed agent ecosystem, Browserbase’s web agents can now be cryptographically identified as authorized, allowing businesses to confidently allow trusted automation while continuing to block scrapers, fraud, and abuse. This means fewer broken workflows, stronger security controls, and a clearer signal of intent behind automated traffic.
### Fingerprint: Identity and verification for the agentic web

Fingerprint is a leading device intelligence platform that helps businesses understand who or what is interacting with their digital properties. By analyzing hundreds of browser, device, and network signals, Fingerprint enables precise identification of trusted visitors while stopping fraud, account takeover, and malicious automation. In the agentic web, Fingerprint provides the verification layer, authenticating authorized AI agents so companies can move beyond blanket bot blocking and toward identity-based access control.

### Building shared infrastructure for the agentic economy

Together with Fingerprint and other ecosystem partners, Browserbase is helping build shared infrastructure for the emerging agentic economy where AI agents can safely interact with websites, APIs, and applications on behalf of users. We believe the future of the web depends on trust, transparency, and verification, and this collaboration brings us closer to a world where enterprises can fully embrace AI agents without compromising security or revenue.

Today, Browserbase is excited to announce our collaboration with [Fingerprint](https://fingerprint.com/) on the launch of **Authorized AI Agent Detection**, a new ecosystem designed to establish trust and identity for AI agents operating on the web.

The Browser Blog

How we built Browserbase Functions

How we built Browserbase Functions

Read Article

Introducing BrowserEnv: Train browser agents on real websites

Read Article

Introducing Browserbase Search

Read Article

Introducing Fetch: the simplest way to read the web

Read Article

We built caching into Stagehand. Here's how it works

Read Article

How Amplitude Transformed Sales Demos with AI-Powered Browser Automation

Read Article

Your AI browser is one malicious <div> away from going rogue

Read Article

Browserbase is launching on the Vercel Marketplace

Read Article

Introducing Browserbase Functions

Read Article

Browserbase & Fingerprint.js: Tackling fraud with agent identity

Read Article