Browserbase Release Notes
Last updated: Feb 20, 2026
Browserbase Products
All Browserbase Release Notes (54)
- 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 18, 2026
Stagehand Action Caching
Stagehand now caches results for repeated actions, eliminating redundant LLM calls. Cached results are served instantly for familiar pages, with DOM hashing keeping accuracy. Expect up to 2x faster execution and ~30% cost reduction on repeat workflows, enabled by default for all users.
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.
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 All of your release notes in one feed
Join Releasebot and get updates from Browserbase and hundreds of other software products.
- 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 - Feb 9, 2026
- Date parsed from source:Feb 9, 2026
- First seen by Releasebot:Feb 10, 2026
Browserbase Functions
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.
What this means:
- Lower latency, up to 70% faster
- Fewer moving parts and less infrastructure to manage
- Async and long-running executions with results tied directly to real browser sessions.
- Local development mirrors production using real Browserbase sessions.
Available now in TypeScript (documentation)
Original source Report a problem - Feb 9, 2026
- Date parsed from source:Feb 9, 2026
- First seen by Releasebot:Feb 10, 2026
How we built Browserbase functions
Browserbase introduces Functions, a new model that hosts both the browser and your automation code with separate deployments and explicit promotion. It uses an infrastructure‑as‑code entrypoint, real local sessions for parity, and asynchronous invocations to cut latency and simplify safe iteration.
When Browserbase was founded
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 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-2while your runner is sitting inus-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.
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 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.
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.
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.
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 running code powering browser agents.
Can't wait to see what you build.
Original source Report a problem - Feb 9, 2026
- Date parsed from source:Feb 9, 2026
- First seen by Releasebot:Feb 10, 2026
Introducing Browserbase Functions
Browserbase unveils Functions to deploy agents and automations directly alongside browser sessions, simplifying infra and boosting reliability. Functions run long‑running Stagehand or Playwright code with versioned deployments and safe promotion. Available today for TypeScript.
Browserbase Functions
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 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 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:
npx @browserbasehq/sdk-functions initIf 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.
Browserbase Functions are the next step toward making browser automation faster and easier to run in production.
Original source Report a problem - Feb 4, 2026
- Date parsed from source:Feb 4, 2026
- First seen by Releasebot:Feb 5, 2026
stagehand/server v3.6.0
Stagehand-server release brings Windows workflow fixes, bedrock/provider support, and broad docs updates. It adds new actions and enums, improved screenshot masking, and enhanced agent hybrid compatibility for smoother automation.
What's Changed
- Fix SEA release workflow for Windows by @miguelg719 in #1603
- Enable bedrock provider on server by @miguelg719 in #1604
- [docs]: add docs for page.snapshot() by @seanmcguire12 in #1589
- [docs]: add docs for page.waitForSelector() by @seanmcguire12 in #1605
- [docs]: add docs for local browser port option by @seanmcguire12 in #1606
- Add SupportedUnderstudyActions to observe system prompt by @miguelg719 in #1609
- Using 'mode' enum instead of old 'cua' boolean by @monadoid in #1611
- Update stale observe evals by @miguelg719 in #1615
- [fix]: mask param in page.screenshot() only applied to first node by @seanmcguire12 in #1612
- [chore]: strengthen regex validation on act, observe for elementId by @miguelg719 in #1614
- add auto-bedrock support based on bedrock/provider.model-name by @pirate in #1617
- [chore]: pull stringified JS into TS file by @seanmcguire12 in #1622
- SupportedUnderstudyAction Enum validation for 'method' on act/observe by @miguelg719 in #1613
- Fix issues in stainless.yml by @pirate in #1638
- add warning when models are used with hybrid mode that will not perf… by @tkattkat in #1633
- [fix]: screenshot mask not working on <dialog> elements by @seanmcguire12 in #1624
- Add right/middle click support on act and observe by @miguelg719 in #1631
- Add executionModel serialization to api client by @miguelg719 in #1636
- Fix deprecation warning for old model format (#1625) by @miguelg719 in #1637
- Add replay to docs by @monadoid in #1643
- Removed MCP from readme for now by @monadoid in #1639
- fix(cdp): avoid unhandled detach by returning original sendCDP promise by @monadoid in #1644
- [fix]: ctx addInitScript on popup pages by @seanmcguire12 in #1642
- [chore]: rm docs changeset by @seanmcguire12 in #1648
- Fix [Agent] : message processing bug by @tkattkat in #1647
- Add support for gemini 3 on cua/hybrid agent by @miguelg719 in #1652
- [docs]: fix userDataDir example for Browserbase sessions by @shrey150 in #1654
- fix(ci): handle new tags in server release workflow (#1660) by @miguelg719 in #1661
- Add user-agent by @miguelg719 in #1646
- Full Changelog: stagehand-server/v3.5.1...stagehand-server/v3.6.0
- Feb 2, 2026
- Date parsed from source:Feb 2, 2026
- First seen by Releasebot:Feb 4, 2026
Browserbase & Fingerprint.js: Tackling fraud with agent identity
Browserbase and Fingerprint unveil Authorized AI Agent Detection to authenticate AI agents in real browsers. By cryptographically identifying authorized agents, it enables trusted automation while blocking fraud and abuse. This collaboration expands a secure, agentic web ecosystem.
Today, Browserbase is excited to announce our collaboration with Fingerprint 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.
Original source Report a problem - Jan 26, 2026
- Date parsed from source:Jan 26, 2026
- First seen by Releasebot:Jan 30, 2026
stagehand/server v3.5.1
Stagehand ships a fresh release with stricter linting rules, improved agent usage metrics, and a deprecated syntax fix. It adds vertex support on the stagehand server, an example for logging agent output, and welcomes new contributors.
What's Changed
- [chore]: add stricter linting rules by @seanmcguire12 in #1597
- improve agent usage metrics by @tkattkat in #1596
- Fix deprecated cua: true syntax in v3 migration guide by @aq17 in #1601
- Logging agent output to file example by @monadoid in #1599
- Add support for vertex on stagehand server by @miguelg719 in #1602
New Contributors
- @aq17 made their first contribution in #1601
Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.5.1
What's Changed
- [chore]: add stricter linting rules by @seanmcguire12 in #1597
- improve agent usage metrics by @tkattkat in #1596
- Fix deprecated cua: true syntax in v3 migration guide by @aq17 in #1601
- Logging agent output to file example by @monadoid in #1599
- Add support for vertex on stagehand server by @miguelg719 in #1602
New Contributors
- @aq17 made their first contribution in #1601
Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.5.1
Original source Report a problem