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

Browserbase Blog: Automate the web

The Browser Blog

Paul Klein

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

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

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

## Building on a foundation of primitives

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

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

## The opportunity ahead

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

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

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

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

## Expanding our platform

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

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


 ## Series B & beyond

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

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

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

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

We can't wait to see what everyone builds.

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

Building the future of web automation

Harsehaj Dhami

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

```
curl -X POST https://api.browserbase.com/v1/fetch \
  --header 'x-bb-api-key: $BROWSERBASE_API_KEY' \
  -H "Content-Type: application/json" \
  -d '{ 
    "url": "https://httpbin.org/get"
  }'<custom-cta text="" button_text="" button_link=""></custom-cta>
```
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.**

Learn more: [https://docs.browserbase.com/features/fetch](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

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

Adam McQuilkin

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

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

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.

Browserbase & Fingerprint.js: Tackling fraud with agent identity

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

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

The irony is that we should have known better.

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

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

In reality, it constantly broke.

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

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

So we’ve rebuilt exactly that.

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

## Why DOM reconstruction fails in the real world

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

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

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

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

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

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

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

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

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

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

Our new system records what the browser actually renders.

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

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

Each frame is timestamped with sub-second precision.

We deliberately capture frames as PNG, not JPEG.

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

## Asynchronous encoding and constant-time recordings

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

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

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

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

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

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

## Binary surgery on fMP4 segments

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

So we patch the files!

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

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

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

## HLS as an delivery primitive

We deliver recordings using HLS.

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

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

## Multi-tab recordings without flattening reality

We record up to ten tabs simultaneously. 

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

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

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

## Secure playback, segment by segment

Session recordings are sensitive. 

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

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

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

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

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

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

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

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

## What this unlocks going forward

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

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

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

Session recordings is rolling out now for Browserbase customers.

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

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

The Browser Blog

Building the future of web automation

Building the future of web automation

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

How we built Browserbase Functions

Read Article

Browserbase & Fingerprint.js: Tackling fraud with agent identity

Read Article

This week we fixed the worst part of Browserbase

Read Article