Browserbase Release Notes
Last updated: Mar 11, 2026
Browserbase Products
All Browserbase Release Notes (60)
- Mar 11, 2026
- Date parsed from source:Mar 11, 2026
- First seen by Releasebot:Mar 11, 2026
The Browserbase Fetch API is available today
Browserbase unveils Fetch API to fetch page content by URL without a browser session, fast and cheap.
Introducing, the 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.
Get started today
https://docs.browserbase.com/features/fetch
Original source Report a problemconst res = await bb . fetchAPI . create ( url : "https://browserbase.com/" , ) ; - Mar 11, 2026
- Date parsed from source:Mar 11, 2026
- First seen by Releasebot:Mar 11, 2026
Introducing Fetch: the simplest way to read the web
Browserbase unveils Fetch API to retrieve page content without a browser session. It’s fast, cheap at $1 per 1k pages, and ideal for agents who only read web pages. Fetch works standalone or with browse, reducing latency and cost while expanding the web reading primitive.
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" }'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:
Original source Report a problem
https://docs.browserbase.com/features/fetch All of your release notes in one feed
Join Releasebot and get updates from Browserbase and hundreds of other software products.
- Mar 10, 2026
- Date parsed from source:Mar 10, 2026
- First seen by Releasebot:Mar 10, 2026
stagehand/server-v3 v3.6.1
Browserbase releases a comprehensive changelog with fixes, docs updates and new features across stagehand-server versions. Highlights include page.setExtraHTTPHeaders, cdpHeaders options, caching docs refresh, CI improvements, and a split of server-v3 and server-v4 dirs.
What's Changed
- [fix]: rm legacy handlePossibleNavigation() by @seanmcguire12 in #1761
- [docs]: add docs for context.setExtraHTTPHeaders() by @seanmcguire12 in #1762
- [STG-1458] server cache docs by @sameelarif in #1753
- chore: remove retired Claude 3.5 and 3.7 Sonnet models by @shrey150 in #1775
- fix: expose Vertex headers in public model config types by @shrey150 in #1764
- [STG-1482] Update caching docs: split into Browserbase Cache and Local Cache sections by @derekmeegan in #1770
- Solve init script race with Debugger.resume at frame init script injection time by @pirate in #1719
- [feat]: add page.setExtraHTTPHeaders() by @seanmcguire12 in #1774
- [feat]: add cdpHeaders option for custom CDP connection headers by @shrey150 in #1779
- fix: evals CLI link and preserve config by @miguelg719 in #1755
- [fix]: skip CI jobs requiring secrets on fork PRs by @shrey150 in #1780
- Allow outside contributors to run CI with secrets when approved by @pirate in #1782
- Revert "Allow outside contributors to run CI with secrets when approved" by @pirate in #1786
- Revert "[fix]: skip CI jobs requiring secrets on fork PRs" by @pirate in #1787
- [feat]: add configurable timeout to agent tools by @tkattkat in #1766
- Add missing cdpHeaders field to v3 server openapi spec by @pirate in #1797
- [STG-1536] Split packages/stagehand/server into separate server-v3 and server-v4 dirs by @pirate in #1796
- [feat]: add browse CLI package by @shrey150 in #1793
- fix(CI): fix changeset reference to stale server package name blocking CI by @pirate in #1801
- Full Changelog: stagehand-server/v3.6.1...stagehand-server-v3/v3.6.1
What's Changed
- [fix]: rm legacy handlePossibleNavigation() by @seanmcguire12 in #1761
- [docs]: add docs for context.setExtraHTTPHeaders() by @seanmcguire12 in #1762
- [STG-1458] server cache docs by @sameelarif in #1753
- chore: remove retired Claude 3.5 and 3.7 Sonnet models by @shrey150 in #1775
- fix: expose Vertex headers in public model config types by @shrey150 in #1764
- [STG-1482] Update caching docs: split into Browserbase Cache and Local Cache sections by @derekmeegan in #1770
- Solve init script race with Debugger.resume at frame init script injection time by @pirate in #1719
- [feat]: add page.setExtraHTTPHeaders() by @seanmcguire12 in #1774
- [feat]: add cdpHeaders option for custom CDP connection headers by @shrey150 in #1779
- fix: evals CLI link and preserve config by @miguelg719 in #1755
- [fix]: skip CI jobs requiring secrets on fork PRs by @shrey150 in #1780
- Allow outside contributors to run CI with secrets when approved by @pirate in #1782
- Revert "Allow outside contributors to run CI with secrets when approved" by @pirate in #1786
- Revert "[fix]: skip CI jobs requiring secrets on fork PRs" by @pirate in #1787
- [feat]: add configurable timeout to agent tools by @tkattkat in #1766
- Add missing cdpHeaders field to v3 server openapi spec by @pirate in #1797
- [STG-1536] Split packages/stagehand/server into separate server-v3 and server-v4 dirs by @pirate in #1796
- [feat]: add browse CLI package by @shrey150 in #1793
- fix(CI): fix changeset reference to stale server package name blocking CI by @pirate in #1801
- Full Changelog: stagehand-server/v3.6.1...stagehand-server-v3/v3.6.1
- Feb 26, 2026
- Date parsed from source:Feb 26, 2026
- First seen by Releasebot:Feb 26, 2026
stagehand/server v3.6.1
Stagehand delivers a docs and stability refresh with cookie and keepAlive updates, plus a session fix when no pages are open. Also adds Sonatype portal config and Zod/OpenAPI enum tweaks. Full changelog linked for details.
What's Changed
- [docs]: add docs for cookie handling by @seanmcguire12 in #1748
- [docs]: add keepAlive docs by @seanmcguire12 in #1747
- [STG-1450] Fix Session init failing when no pages are open, falls back to opening about:blank by @pirate in #1749
- STG-1307: set Sonatype portal for Java/Kotlin by @monadoid in #1757
- [fix]: Add bedrock to provider enum in Zod schemas and OpenAPI spec by @shrey150 in #1759
Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.6.1
What's Changed
- [docs]: add docs for cookie handling by @seanmcguire12 in #1748
- [docs]: add keepAlive docs by @seanmcguire12 in #1747
- [STG-1450] Fix Session init failing when no pages are open, falls back to opening about:blank by @pirate in #1749
- STG-1307: set Sonatype portal for Java/Kotlin by @monadoid in #1757
- [fix]: Add bedrock to provider enum in Zod schemas and OpenAPI spec by @shrey150 in #1759
Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.6.1
- Feb 25, 2026
- Date parsed from source:Feb 25, 2026
- First seen by Releasebot:Feb 25, 2026
@browserbasehq/[email protected]
Stagehand releases new cookie management APIs and header control plus a keepAlive option and mode updates for broader browser automation control. The patch wave covers numerous fixes, performance tweaks, and compatibility tweaks across act observe and CUA mode.
Minor Changes
- #1681 e3db9aa Thanks @tkattkat! - Add cookie management APIs: context.addCookies(), context.clearCookies(), & context.cookies()
- #1672 b65756e Thanks @seanmcguire12! - add boolean keepAlive parameter to allow for configuring whether the browser should be closed when stagehand.close() is called.
- #1708 176d420 Thanks @seanmcguire12! - add context.setExtraHTTPHeaders()
- #1611 8a3c066 Thanks @monadoid! - Using mode enum instead of old cua boolean in openapi spec
- #1632 afbd08b Thanks @pirate! - Remove automatic .env loading via dotenv.
If your app relies on .env files, install dotenv and load it explicitly in your code:
import dotenv from "dotenv"; dotenv.config({ path: ".env" });Patch Changes
- #1683 7584f3e Thanks @seanmcguire12! - fix: include shadow DOM in .count() & .nth() & support xpath predicates
- #1644 1e1c9c1 Thanks @monadoid! - Fix unhandled CDP detaches by returning the original sendCDP promise
- #1729 6bef890 Thanks @shrey150! - fix: support Claude 4.6 (Opus and Sonnet) in CUA mode by using the correct computer_20251124 tool version and computer-use-2025-11-24 beta header
- #1647 ffd4b33 Thanks @tkattkat! - Fix [Agent] - Address bug causing issues with continuing a conversation from past messages in dom mode
- #1614 677bff5 Thanks @miguelg719! - Enforce - regex validation on act/observe for elementId
- #1580 65ff464 Thanks @tkattkat! - Add unified variables support across act and agent with a single VariableValue type
- #1666 101bcf2 Thanks @Kylejeong2! - add support for codex models
- #1728 0a94301 Thanks @seanmcguire12! - handle potential race condition on .close() when using the Stagehand API
- #1664 b27c04d Thanks @seanmcguire12! - fixes issue with context.addInitScript() where scripts were not being applied to out of process iframes (OOPIFs), and popup pages with same process iframes (SPIFs)
- #1624 0e8d569 Thanks @seanmcguire12! - fix issue where screenshot masks were not being applied to dialog elements
- #1596 ff0f979 Thanks @tkattkat! - Update usage/metrics handling in agent
- #1631 2d89d2b Thanks @miguelg719! - Add right and middle click support to act and observe
- #1697 aac9a19 Thanks @shrey150! - fix: support elements in XPath frame boundary detection so act() works on legacy pages
- #1692 06de50f Thanks @shrey150! - fix: skip piercer injection for chrome-extension:// and other non-HTML targets
- #1613 aa4d981 Thanks @miguelg719! - SupportedUnderstudyAction Enum validation for 'method' on act/observe inference
- #1652 18b1e3b Thanks @miguelg719! - Add support for gemini 3 flash and pro in hybrid/cua agent
- #1706 957d82b Thanks @chrisreadsf! - Add GLM to prompt-based JSON fallback for models without native structured output support
- #1633 22e371a Thanks @tkattkat! - Add warning when incorrect models are used with agents hybrid mode
- #1673 d29b91f Thanks @miguelg719! - Add multi-region support for Stagehand API with region-specific endpoints
- #1695 7b4f817 Thanks @tkattkat! - Fix: zod bug when pinning zod to v3 and using structured output in agent
- #1609 3f9ca4d Thanks @miguelg719! - Add SupportedUnderstudyActions to observe system prompt
- #1581 49ead1e Thanks @sameelarif! - Server-side caching is now available.
When running env: "BROWSERBASE", Stagehand automatically caches act(), extract(), and observe() results server-side — repeated calls with the same inputs return instantly without consuming LLM tokens.
Caching is enabled by default and can be disabled via serverCache: false on the Stagehand instance or per individual call. Check out the browserbase blog for more details.- #1642 3673369 Thanks @seanmcguire12! - fix issue where scripts added via context.addInitScripts() were not being injected into new pages that were opened via popups (eg, clicking a link that opens a new page) and/or calling context.newPage(url)
- #1735 c465e87 Thanks @monadoid! - Supports request header authentication with connectToMCPServer
- #1705 ae533e4 Thanks @seanmcguire12! - include error cause in UnderstudyCommandException
- #1636 ea33052 Thanks @miguelg719! - Include executionModel on the AgentConfigSchema
- #1679 5764ede Thanks @shrey150! - fix issue where locator.count() was not working with xpaths that have attribute predicates
- #1646 f09b184 Thanks @miguelg719! - Add user-agent to CDP connections
- #1637 a7d29de Thanks @miguelg719! - Improve error and warning message for legacy model format
- #1685 d334399 Thanks @tkattkat! - Bump ai sdk & google provider version
- #1662 44416da Thanks @seanmcguire12! - fix issue where locator.fill() was not working on elements that require direct value setting
- #1612 bdd8b4e Thanks @seanmcguire12! - fix issue where screenshot mask was only being applied to the first element that the locator resolved to. masks now apply to all matching elements.
- Feb 24, 2026
- Date parsed from source:Feb 24, 2026
- First seen by Releasebot:Mar 11, 2026
We built caching into Stagehand. Here's how it works
Browserbase introduces Stagehand Caching to cut LLM costs by reusing cached action selectors for repetitive web automation. It validates page state before reuse, enabling speedups up to ~80% in ideal workloads while preserving safety. Cache is project-scoped, 48 hours, with careful drift handling. Get started with npx create-browser-app.
Web automation is repetitive
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.
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):
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:
- The request becomes a cache miss.
- Stagehand executes the action normally.
- 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.
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 .
Original source Report a problem - Feb 19, 2026
- Date parsed from source:Feb 19, 2026
- First seen by Releasebot:Feb 20, 2026
@browserbasehq/[email protected]
Patch Changes
- #1710 df76207 Thanks @seanmcguire12! - handle target closed errors on rapidly opening/closing popups
- Feb 17, 2026
- Date parsed from source:Feb 17, 2026
- First seen by Releasebot:Feb 17, 2026
- Modified by Releasebot:Feb 25, 2026
Stagehand Caching
Stagehand introduces automatic result caching to skip repeated LLM calls, delivering faster execution and cost savings. DOM hashing keeps accuracy as cache scales, with conservative defaults and project‑scoped caching active for all users.
Stagehand now caches the results of repeated actions
Stagehand now caches the results of repeated actions, eliminating redundant LLM calls automatically, no code changes required.
When Stagehand encounters a page structure it's seen before, it serves the cached result instantly, no LLM call needed. DOM hashing validates each match, so accuracy stays high even as cache usage scales.
Result
The result: up to 2x faster execution and ~30% cost reduction on repeat workflows. Your agents get more efficient the more they run.
Caching is conservative by default and scoped to your project. It kicks in automatically for all Stagehand users on Browserbase.
Read the docs.
Original source Report a problem - Feb 12, 2026
- Date parsed from source:Feb 12, 2026
- First seen by Releasebot:Feb 17, 2026
Browserbase on the Vercel Marketplace
Browserbase launches a one-click Vercel Agent Marketplace integration delivering production-grade browsers via remote CDP. Sandbox agents connect to remote browsers with unified billing and simple config, plus Web Bot Auth with cryptographic signing for secure Vercel deployments.
Browserbase is now a one-click integration on the Vercel Agent Marketplace. Your agents get production-grade browsers without running browsers themselves.
Agents deployed on Vercel Sandbox can connect to remote browsers over CDP, keeping your agent logic on Vercel while the browser runs on infrastructure built for automation. One API key, unified billing, no proxies or complex configuration. The integration also works alongside Vercel's AI Gateway and Sandbox out of the box.
We're also launching Web Bot Auth support with Vercel. Browserbase agents now send cryptographically signed requests that Vercel verifies, so your agents can reliably browse Vercel-hosted deployments without getting blocked by security layers.
Read more ->
Original source Report a problem - Feb 12, 2026
- Date parsed from source:Feb 12, 2026
- First seen by Releasebot:Feb 12, 2026
Browserbase is launching on the Vercel Marketplace
Browserbase launches on the Vercel Marketplace, letting AI agents browse real web pages via a remote browser with one API key. It keeps agent logic on Vercel while the browser runs on dedicated infra for production reliability and observability. Web Bot Auth enables trusted, non-blocking automation.
The best agents run on Vercel. Now they get the best browsers too.
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.
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 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 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 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, 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 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.
Original source Report a problem
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