Releasebot
Create account

Browserbase Release Notes

Follow

Last updated: Apr 7, 2026

Get this feed: RSS Email API

Browserbase Products

All Browserbase Release Notes (83)

  • Apr 7, 2026
    • Date parsed from source:
      Apr 7, 2026
    • First seen by Releasebot:
      Apr 7, 2026
    Browserbase logo

    Browserbase

    APIs see 15% of the web. Unlock the other 85% with the Browserbase Platform

    Browserbase introduces a unified browser agent platform that brings Search, Fetch, browsers, identity, models, and Functions together under one API key, with updated pricing to match the bundled stack and help teams build production-ready agents more easily.

    By Paul Klein

    Company

    5 min read

    The biggest thing holding agents back isn’t model capabilities, but access to the systems we use every single day.

    We want agents to do work on our behalf. But most of that work (logins, forms, dashboards, documents) aren’t exposed via APIs. They’re accessible via the web, and through interfaces designed for humans.

    The web is fragmented, and agents are missing the tools needed to access it. But the tools are fragmented too.

    Creating best in class browser agents means stitching together search, fetch, browsers, sandboxes, and models across multiple vendors. You need 6 API keys just to build the “Hello World”.

    That’s why at Browserbase, we’re unifying the browser agent stack.

    • Use a real browser to do real work online with our secure browser infrastructure
    • Authenticate on behalf of humans with a real identity for your agent
    • Search for where to go
    • Fetch content instantly when a browser isn’t needed
    • Deploy and run agents in a sandbox with Functions
    • Use any model in Stagehand with one API via the Model Gateway

    All with one Browserbase API key.

    Teams at Shopify, Ramp, and Lovable are already building browser agents on Browserbase. You can too.

    The moment every browser agent hits the wall

    There’s a point in almost every browser agent project where things stop feeling easy.

    Up until then, everything looks pretty promising. The model understands the task, the reasoning is sound, and the outputs make sense. Surely, it’s ready for the world … surely not. The moment the agent needs to actually to log into a system, submit a form, retrieve a document, or navigate a workflow, it runs into friction.

    Tons of things go wrong. Maybe pages don’t render as expected or content is hidden behind JavaScript. Or, the API you assumed would exist doesn’t. All that seems straightforward becomes painfully brittle.

    This is because your agent doesn’t actually have access to the web. An API only gets you 15% of the way there.

    The tools exist, but there are too many pieces

    To solve this, developers will naturally assemble a stack:

    • Search to figure out where to go.
    • Fetch to see what’s on the page.
    • Browsers to click buttons and submit forms.
    • Functions to run code in a sandbox.
    • Models for reasoning.
    • Observability to debug failures.

    Don’t get me wrong, each piece absolutely works individually. The real issue is that none of them are designed to work together as a system.

    Every step of your browser agent’s workflow crosses a boundary between vendors, runtimes, logs, and failure modes. So when something breaks (and it always does), you’re really debugging the seams between the tools, rather than the agent logic itself a lot of the time.

    We just want an agent to do the thing. Browser agents need to see and access the other 85% of the web for that to happen.

    So we built the whole platform, with unified observability and logging, to make it seamless for anyone to build production-ready browser agents.

    From component to the platform

    Browserbase started by solving one of the hardest problems in infrastructure: running browsers reliably in the cloud. If an agent needs to behave like a human, it needs a real browser that delivers.

    But after working with thousands of developers, continued to see teams solve the browser layer with Browserbase, only to run into friction with other parts of the stack. And your agent is only as reliable as it’s weakest link.

    Instead of building better individual tools, we built a platform where every part of the browser agent stack runs on the same underlying infrastructure.

    Search, fetch, browsers, identity, sandboxes, and models are no longer separate integrations. Instead, they’re primitives in one system.

    How browser agents work when the system is unified

    Reliable browser agents still follow the same journey, but now work within a unified platform that keeps the context together for best-in-class reliability.

    Navigating the web with Search

    Before they browse, agents need to figure out where to go.

    Rather than hardcoding URLs or relying on guesswork, agents can use Search to find the right destination dynamically.

    Retrieving web context with Fetch

    Once the agent has a destination, it doesn’t always need a browser. Often, the fastest step is simply retrieving the page content to understand what’s there.

    This is where Fetch comes in.

    Fetch gives agents a lightweight way to inspect pages before deciding whether deeper interaction is required.

    Interacting with the web with a browser

    When the workflow requires interaction (like logins, dynamic content, multi-step flows), the agent escalates to a real browser.

    This is where Browserbase’s core infrastructure takes over, providing production-grade browsers with full observability and session recordings so you can see exactly what happened when something fails.

    Identity makes the web usable

    One of the most overlooked challenges in building browser agents is identity.

    Despite most things working correctly, most agents fail here because every browser session looks like a new, unknown user. Without continuity, websites treat them that way, so sessions break and workflows fail.

    We’ve solved this problem thanks to Agent Identity.

    In partnerships with Cloudflare, Fingerprint, and 1Password, we’ve enabled agents to operate with a consistent, verifiable presence across sessions. We’ve combined cryptographic identity (Web Bot Auth), stable browser signals, and safe access to real user credentials.

    Once your agent can reliably access the web, the next challenge is deciding what to do next consistently, and at scale.

    Making models easy to change with Model Gateway

    Agents still rely on models to reason, but managing multiple providers adds unnecessary overhead. Different models are better at different things. Some are faster, some are cheaper, some are more reliable. In practice, you end up wanting to switch between them constantly.

    The Browserbase Model Gateway provides a unified interface to access and switch between models (from Anthropic, OpenAI and Gemini) with a single API key using Stagehand:

    This removes friction from experimentation and allows your stack to evolve as models improve.

    From prototype to production with Functions

    The final challenge is getting agents to run reliably outside your laptop.

    An agent that works locally often fails when it needs to run continuously, handle retries, or manage state. Browserbase Functions solves this by letting you run agents directly within Browserbase. Your agents are close to the browser infrastructure, with better performance and debugging.

    What changes when it’s one system

    Browsers, search, fetch, identity, models, and execution all exist today, but separately.

    Bringing them together changes this experience when you’re no longer stitching vendors together or debugging across multiple systems. You’re working within one platform that understands your browser agent’s job.

    You can piece together a million tools, but at the end of the day again, I just want my browser agent to do the thing. By unifying the stack, we can move further up it. One platform, one API key, and one person. It’ll get the job done now.

    Build agents that can access 100% of the web

    Teams at Lovable, Ramp, and Clay are already building agents with Browserbase.

    Now you can do the same, without stitching the stack together yourself. Ambitious ideas need more than APIs. Give them access to the rest of the web. ;)

    Get your API key to the web

    Our pricing has also been updated to reflect the platform: bundled, flexible, and aligned with how agents are actually built and scaled. See all of the updates here.

    Original source Report a problem
  • Apr 6, 2026
    • Date parsed from source:
      Apr 6, 2026
    • First seen by Releasebot:
      Apr 7, 2026
    Browserbase logo

    Browserbase

    Showing up on the web with agent identity

    Browserbase introduces agent identity for the web, with Verified as the first step. Built with Web Bot Auth and partners like Cloudflare, Fingerprint, and 1Password, it aims to give browser agents a stable, recognizable presence across sessions.

    TL;DR

    Agents need to be recognized on the web. We’re introducing agent identity, powered by Web Bot Auth and partners like Cloudflare, Fingerprint, and 1Password, with Verified as the first step.

    Over the past nine months, we’ve been building toward something that doesn’t look new at first glance. The underlying capabilities are familiar, but their meaning has changed. What we previously framed as stealth is more accurately described as identity.

    Agents without identity

    If you’ve worked with browser agents, you’ve likely run into the same limitation. Things work in controlled environments, but break down on the real web. Sessions fail, access becomes inconsistent, and entire flows stop working once bot protection systems get involved. Your agent isn’t necessarily doing anything wrong … it just doesn’t look like anything at all. 😬

    From the perspective of most websites, your agent is a new user every time. The browser environment changes, device characteristics shift, the network origin rotates, and there is no continuity across sessions. Without consistency, there is no identity. And without identity, everything is treated as unknown.

    Historically, this problem was approached through stealth. The goal was to make each session look realistic enough to pass. This meant generating believable fingerprints, handling CAPTCHAs, and aligning signals so the browser didn’t immediately stand out. At a deeper level, it meant replicating environmental signals through a controlled browser environment so the system behaved like a human-operated one.

    But framing this as stealth implies something adversarial, as if the goal is to sneak through systems undetected. It feels shady. In practice, most browsers agents (or agents) aren’t trying to do that. Developers are building legitimate workflows across testing, data extraction, content aggregation, and increasingly, agents that need to interact with real interfaces. These systems aren’t malicious, but the web has no way to distinguish them from ones that are.

    So, for the sake of safety, everything gets treated the same.

    Identity, not evasion

    What we’ve built is better understood as identity. Instead of optimizing for passing individual checks, the system focuses on consistency over time. The browser environment remains coherent across sessions, and the agent behaves like the same user returning rather than a new one appearing each time. The goal is not to look human once, but to be recognizable across interactions.

    We’ve been developing this approach in collaboration with partners across the anti-bot and identity ecosystem, including Cloudflare, Fingerprint, and 1Password.

    Through our partnership with Cloudflare, we’ve helped pioneer Web Bot Auth, a new identity layer that allows agents to present a cryptographically signed proof of who they are. Instead of relying on weak signals like IPs or user agents, an agent can now arrive at a site with something closer to a passport that can be verified by the site and its anti-bot providers.

    With Fingerprint, we’re extending this into authorized agent detection, where agents can be recognized and verified across hundreds of browser, device, and network signals. This allows platforms to move beyond blanket blocking and toward identity-based access control, where trusted browser agents can be distinguished from abuse.

    And with 1Password, we’re connecting identity to real user credentials by allowing agents to securely access the same systems humans do, and using the same vaults people already trust.

    Together, these partnerships form the foundation of agent identity as a shared system.

    As part of this shift, we’re introducing Verified as an early step toward making agent identity usable in practice. It allows agents to run with a stable, reproducible presence and ties that identity into Web Bot Auth that can actually interpret and validate it.

    The web is moving from a human-only environment to one where agents are also participants. Without identity, agents remain transient and untrusted. But with it, a different model becomes possible where legitimate browser agents can operate within the same systems rather than against them.

    Get verified browsers from our team → Contact us

    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.

    Create account
  • Apr 6, 2026
    • Date parsed from source:
      Apr 6, 2026
    • First seen by Releasebot:
      Apr 6, 2026
    Browserbase logo

    Browserbase

    Introducing Model Gateway: use Stagehand without managing model keys

    Browserbase adds Model Gateway for Stagehand, giving developers one API key and one bill to access OpenAI, Anthropic, and Gemini models without managing providers. It simplifies model switching, retries, rate limits, and caching for browser workflows.

    By Miguel Gonzalez
    By Harsehaj Dhami
    Stagehand
    3 min read

    TL;DR

    TL;DR: Model Gateway reduces the friction of using LLMs in Stagehand. One API key, one bill, and access to top models without managing providers. You can switch models easily, avoid rate limits, and build without extra setup.

    ———————————————————————————————————

    When I talk to developers evaluating Stagehand, the first point of friction usually isn’t usually browser automation itself. Instead, it’s choosing the right model, and being able to change your mind later.

    Different models are better at different things. Some are faster, some are cheaper, some are more reliable. In practice, you end up wanting to switch between them constantly.

    But switching models usually means new API keys, accounts, rate limits, and prompting strategies/configuration. That’s a lot of work, so many developers just don’t switch. They pick one model early and work around its limitations.

    We built the Browserbase Model Gateway to fix that.

    Treat models like a runtime decision

    Model Gateway lets you use Stagehand without wiring up model providers yourself. Instead of integrating directly with OpenAI, Anthropic, or Gemini, you just use your Browserbase API key, and we handle the rest.

    What this actually means

    Before Model Gateway, a typical Stagehand setup looked something like this:

    # before
const stagehand = new Stagehand({ env: "BROWSERBASE", apiKey: process.env.BROWSERBASE_API_KEY, model: { modelName: "openai/gpt-5", apiKey: process.env.OPENAI_API_KEY, },

    You had to manage your Browserbase account and your model provider account. Billing, access, and rate-limit behaviour is split. Another provider means another account, key, and code.

    With Model Gateway, this setup gets simpler:

    # after
const stagehand = new Stagehand({ apiKey: process.env.BROWSERBASE_API_KEY, model: "openai/gpt-5", // or “anthropic/claude-sonnet-4-6” / “google/gemini-3-flash-preview" });

    When you send a request through Stagehand actions and choose a supported model, Browserbase routes that request to the upstream provider for you. We handle the provider call, cover the upstream cost, and bill you downstream for tokens at market price with no markup.

    The value is a lot more than just “one less env var.” A whole category of setup and operational work also disappears. ;)

    Rather than the model being an infrastructure decision, model gateway makes models a more fluid runtime decision.

    Switching models should be normal

    Most teams don’t switch models as often as they should, because it’s operationally annoying. With Model Gateway, switching is just configuration. You can switch models without reworking your setup:

    const stagehand = Stagehand({ model: "openai/gpt-4.1" }
// switching to anthropic
const stagehand = Stagehand({ model: "anthropic/claude-sonnet-4-6" }

    You can experiment more freely (try a cheaper model, swap for higher quality, or add a fallback path) without thinking about credentials or access.

    And when things go wrong upstream (like hitting 429s or transient failures) you don’t need to build custom retry logic for every provider. Requests go through Browserbase, and we handle retries, backoff, and rate limits on your behalf.

    Use better models without paying for repeated work

    Today, Stagehand supports managed action caching. In other words, we can reuse previously executed steps instead of re-running the same work.

    This is often more useful in practice than prompt-level caching, especially for browser workflows.

    With Model Gateway and by routing model usage through Browserbase, you’re running on the managed path, which is where caching applies. You don’t have to coordinate caching across providers or build your own layer for it.

    You can use better models and still benefit from caching and reuse. Instead of optimizing purely for cost or speed upfront, you can pick the best model for the job and let caching reduce redundant work over time.

    And when workflows fail or need to retry, Stagehand can pick back up without re-running everything from scratch, so you’re not paying for the same work twice.

    One key → one bill

    LLM inference, browser infrastructure, and caching all run through your Browserbase API key. And best of all, you’re not paying extra for this abstraction.

    We charge market price for tokens, which is the same as going direct. It also removes the common tier gating pain point with provider APIs.

    If you’ve used these APIs before, you’ve probably run into this when new models get released, but you can’t actually use them yet because your account hasn’t hit a certain spend threshold. When OpenAI released early previews of computer use models, access was limited to higher usage tiers. Even if you wanted to try them, you had to “earn” access first.

    With Model Gateway, you don’t have to think about any of that. You don’t have to hit spend thresholds to unlock models, manage account tiers, or build around provider-specific rate limits

    We’ll handle it for you. :)

    Get started: npx create-browser-app

    Get started:

    npx create-browser-app

    Use the best models for the job, and switch whenever you want.

    Model Gateway currently supports OpenAI, Anthropic, and Gemini.

    If you’re looking to use additional models or need support for a custom setup, reach out! We’re happy to work with teams on more advanced or high-scale use cases.

    Original source Report a problem
  • Apr 5, 2026
    • Date parsed from source:
      Apr 5, 2026
    • First seen by Releasebot:
      Apr 6, 2026
    Browserbase logo

    Browserbase

    Use Stagehand with any model

    Browserbase introduces Model Gateway for Stagehand, letting users pick a model with one Browserbase API key while Browserbase handles routing, retries, billing at market price, and automatic rate limit handling, with support for OpenAI, Anthropic, and Gemini.

    Managing model providers adds friction to every Stagehand setup: separate API keys, accounts, rate limits, and tier gating. Model Gateway removes that layer.

    Pass your Browserbase API key and pick a model. We handle routing, retries, and billing at market price with no markup.

    const stagehand = new Stagehand({ apiKey: process.env.BROWSERBASE_API_KEY, model: "openai/gpt-5", // or “anthropic/claude-sonnet-4-6” / “google/gemini-3-flash-preview” });

    Switching models is a one-line change. No new accounts, no reworked setup. Rate limit handling, retries, and action caching all run through Browserbase automatically.

    Supported: OpenAI, Anthropic, Gemini. Need something else? Reach out.

    Original source Report a problem
  • Apr 1, 2026
    • Date parsed from source:
      Apr 1, 2026
    • First seen by Releasebot:
      Apr 1, 2026
    Browserbase logo

    Stagehand by Browserbase

    Release @browserbasehq/[email protected] (#1946)

    Stagehand ships browse-cli 0.5.0, defaulting browse env local to an isolated browser and adding --auto-connect for attaching to an existing debuggable Chrome. It also updates the changelog and prepares the package for publish from main.

    Prepare the next browse-cli release by versioning the package on main.

    What this PR does:

    • bumps packages/cli/package.json to 0.5.0
    • updates the browse-cli changelog
    • consumes the pending browse-cli changesets

    After this PR merges, the Release workflow on main will publish
    @browserbasehq/[email protected] from that exact commit using pnpm pack + npm publish --provenance.

    Summary by cubic

    Publish @browserbasehq/[email protected], defaulting browse env local
    to an isolated browser and adding --auto-connect to opt into attaching
    to an existing debuggable Chrome; explicit CDP attach via browse env local <port|url> remains unchanged.

    Migration

    If you previously relied on auto-attach, run: browse env local --auto-connect.

    Written for commit 795c005.

    Summary will update on new commits. Review in
    cubic

    Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

    Original source Report a problem
  • Mar 31, 2026
    • Date parsed from source:
      Mar 31, 2026
    • First seen by Releasebot:
      Apr 1, 2026
    Browserbase logo

    Stagehand by Browserbase

    stagehand/server-v3 v3.6.3

    Stagehand releases a broad update across core, server, and browse-cli with LLM middleware and headers support, new v4 route stubs and internal schemas, a Pydantic schema parsing fix, and browse-cli upgrades for session metadata, connect support, and markdown output.

    What's Changed

    • Include LLM headers in ModelConfig by @miguelg719 in #1874
    • Fix schema parsing bug for Pydantic .model_json_schema() by @miguelg719 in #1873
    • feat(cli): add browse-cli metadata to Browserbase sessions by @shrey150 in #1890
    • STG-1669: fix(cli): clear cached state when browser connection dies by @shrey150 in #1887
    • STG-1672: Add --connect flag to browse CLI for existing Browserbase sessions by @shrey150 in #1889
    • chore: Decouple browse-cli release cycle from stagehand core by @shrey150 in #1885
    • [STG-1702] fix: pass GITHUB_TOKEN to changeset version step in release-cli workflow by @shrey150 in #1893
    • Fix OpenAI cua agent by @tkattkat in #1899
    • [v4]: add method arg to /click route stub by @seanmcguire12 in #1884
    • STG-1614: add v4 llm stubs and internal schemas by @monadoid in #1881
    • [v4]: update /scroll route stub by @seanmcguire12 in #1875
    • [v4]: add /elementInfo route stub by @seanmcguire12 in #1877
    • [v4]: more page route stubs for locator functions by @seanmcguire12 in #1882
    • STG-1668: browse env local auto-discovers existing Chrome via CDP by @shrey150 in #1886
    • [fix]: handle mapping timeout -> timeoutMs by @seanmcguire12 in #1901
    • STG-1671: chore: add prettier pre-commit hook via husky + lint-staged by @shrey150 in #1888
    • Recover server-v4 drizzle stack onto main by @monadoid in #1917
    • chore: switch browse-cli to merge-first release flow by @shrey150 in #1921
    • Release @browserbasehq/[email protected] by @github-actions[bot] in #1925
    • [fix]: harden act variables prompt by @seanmcguire12 in #1922
    • [fix]: attach to manually-created new tabs by @seanmcguire12 in #1924
    • [STG-1733] fix: use valid metadata key for browse-cli sessions by @derekmeegan in #1911
    • Release @browserbasehq/[email protected] by @github-actions[bot] in #1932
    • [STG-1739] fix: browse-cli releases publish under alpha instead of latest by @shrey150 in #1934
    • Add support for LLM middleware by @tkattkat in #1872
    • [Claimed #1844] Refactor model ID checks for GPT 5.x model family by @github-actions[bot] in #1852
    • Add browse get markdown command by @derekmeegan in #1907
    • fix: pass through server-v3 operation errors by @monadoid in #1937
    • fix: compute server release versions from tags by @monadoid in #1938
    • fix: trigger server release workflows on workflow changes by @monadoid in #1939
    • fix: resolve server release versions from remote tags by @monadoid in #1940
    • fix shell parsing in server release workflows by @monadoid in #1941

    Full Changelog: stagehand-server-v3/v3.6.2...stagehand-server-v3/v3.6.3

    Original source Report a problem
  • Mar 31, 2026
    • Date parsed from source:
      Mar 31, 2026
    • First seen by Releasebot:
      Apr 1, 2026
    Browserbase logo

    Stagehand by Browserbase

    Release @browserbasehq/[email protected] (#1942)

    Stagehand releases browse-cli 0.4.2 with a new markdown conversion command, letting users turn page HTML into Markdown with optional selector support while preserving links, tables, and code blocks.

    Prepare the next browse-cli release by versioning the package on main.

    What this PR does:

    bumps packages/cli/package.json to 0.4.2

    updates the browse-cli changelog

    consumes the pending browse-cli changesets

    After this PR merges, the Release workflow on main will publish
    @browserbasehq/[email protected] from that exact commit using pnpm pack + npm publish --provenance.

    Summary by cubic

    Publish @browserbasehq/browse-cli 0.4.2 by bumping the version and
    updating the changelog. This release adds a command to convert page HTML
    to Markdown.

    New Features

    Add browse get markdown [selector] to convert page HTML to Markdown.

    Defaults to body; supports an optional selector; preserves links,
    tables, and code blocks via node-html-markdown.

    Written for commit eb2b85f.

    Summary will update on new commits. Review in
    cubic

    Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

    Original source Report a problem
  • Mar 25, 2026
    • Date parsed from source:
      Mar 25, 2026
    • First seen by Releasebot:
      Apr 6, 2026
    Browserbase logo

    Browserbase

    Introducing BrowserEnv: Train browser agents on real websites

    Browserbase launches BrowserEnv with Prime Intellect, a general availability reinforcement learning environment for training and evaluating browser agents on real web tasks using scalable browser infrastructure and task verification.

    By Harsehaj Dhami
    By Kyle Jeong

    Engineering

    2 min read

    TL;DR

    Browserbase and Prime Intellect have partnered to launch BrowserEnv, a reinforcement learning environment for training and evaluating browser agents on real web tasks.

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

    The missing piece is a reliable and scalable training environment.

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

    For example, Microsoft trained and evaluated their computer-use model Fara-7B using Browserbase, which required reliable access to real websites and scalable browser environments for evaluation and reinforcement learning workflows.

    "We have partnered with Prime Intellect to make this infrastructure accessible to everyone with BrowserEnv."

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

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

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

    Training Qwen 3 VL on WebVoyager with BrowserEnv

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

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

    We started from the public WebVoyager environment in the Prime hub, switched it to CUA mode, and pointed it at Qwen3-VL-8B-Instruct. The training run used a relatively small but realistic configuration: 200 steps, batch size 32, 8 rollouts per example, learning rate 1e-4, and an oversampling factor of 2, with modest parallelism.

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

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

[sampling]
max_tokens = 512

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

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

    The output of this training run is a LoRA adapter that can be easily deployed to run on the Prime Intellect platform.

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

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

    BrowserEnv is generally available today, learn more at browserenv.com and start training your own browser agents.

    Original source Report a problem
  • Mar 24, 2026
    • Date parsed from source:
      Mar 24, 2026
    • First seen by Releasebot:
      Mar 25, 2026
    Browserbase logo

    Stagehand by Browserbase

    stagehand/server-v3 v3.6.2

    Stagehand releases updates to docs, streaming, and tool handling, including broader toolTimeout support, explicit SSE event names for local v3 streaming, selector schema cleanup, and v4 route and type refinements.

    What's Changed

    • [docs]: add docs for page.setExtraHTTPHeaders() by @seanmcguire12 in #1842
    • Revert unintentional test commit by @miguelg719 in #1850
    • [feat]: apply toolTimeout arg to more tools by @seanmcguire12 in #1843
    • Revert broken finished SSE yield config by @monadoid in #1856
    • remove unnecssary value param from fillform tool in dom mode by @tkattkat in #1811
    • group v4 routes with fastify plugins by @monadoid in #1851
    • [fix]: add useSearch & toolTimeout to stainless types by @seanmcguire12 in #1854
    • [v4]: unify selector type by @seanmcguire12 in #1860
    • [v4]: add index to selector schemas by @seanmcguire12 in #1861
    • [v4]: rm redundant routes by @seanmcguire12 in #1862
    • [v4]: update stubs to return selector obj by @seanmcguire12 in #1865
    • variables for observe by @filip-michalsky in #1808
    • docs: update docs theme to fix our previous sunset theme by @Kylejeong2 in #1879
    • Add explicit SSE event names for local v3 streaming by @monadoid in #1858

    Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.6.2

    What's Changed

    • [docs]: add docs for page.setExtraHTTPHeaders() by @seanmcguire12 in #1842
    • Revert unintentional test commit by @miguelg719 in #1850
    • [feat]: apply toolTimeout arg to more tools by @seanmcguire12 in #1843
    • Revert broken finished SSE yield config by @monadoid in #1856
    • remove unnecssary value param from fillform tool in dom mode by @tkattkat in #1811
    • group v4 routes with fastify plugins by @monadoid in #1851
    • [fix]: add useSearch & toolTimeout to stainless types by @seanmcguire12 in #1854
    • [v4]: unify selector type by @seanmcguire12 in #1860
    • [v4]: add index to selector schemas by @seanmcguire12 in #1861
    • [v4]: rm redundant routes by @seanmcguire12 in #1862
    • [v4]: update stubs to return selector obj by @seanmcguire12 in #1865
    • variables for observe by @filip-michalsky in #1808
    • docs: update docs theme to fix our previous sunset theme by @Kylejeong2 in #1879
    • Add explicit SSE event names for local v3 streaming by @monadoid in #1858

    Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.6.2

    What's Changed

    • [docs]: add docs for page.setExtraHTTPHeaders() by @seanmcguire12 in #1842
    • Revert unintentional test commit by @miguelg719 in #1850
    • [feat]: apply toolTimeout arg to more tools by @seanmcguire12 in #1843
    • Revert broken finished SSE yield config by @monadoid in #1856
    • remove unnecssary value param from fillform tool in dom mode by @tkattkat in #1811
    • group v4 routes with fastify plugins by @monadoid in #1851
    • [fix]: add useSearch & toolTimeout to stainless types by @seanmcguire12 in #1854
    • [v4]: unify selector type by @seanmcguire12 in #1860
    • [v4]: add index to selector schemas by @seanmcguire12 in #1861
    • [v4]: rm redundant routes by @seanmcguire12 in #1862
    • [v4]: update stubs to return selector obj by @seanmcguire12 in #1865
    • variables for observe by @filip-michalsky in #1808
    • docs: update docs theme to fix our previous sunset theme by @Kylejeong2 in #1879
    • Add explicit SSE event names for local v3 streaming by @monadoid in #1858

    Full Changelog: https://github.com/browserbase/stagehand/compare/@browserbasehq/[email protected]/v3.6.2

    Original source Report a problem
  • Mar 18, 2026
    • Date parsed from source:
      Mar 18, 2026
    • First seen by Releasebot:
      Mar 19, 2026
    Browserbase logo

    Stagehand by Browserbase

    @browserbasehq/[email protected]

    Stagehand releases a set of minor and patch updates, adding cdpHeaders for localBrowserLaunchOptions, expanding provider header support, updating the agents search tool, and shipping fixes like initial about:blank tab creation and improved captcha handling for browser sessions.

    Minor Changes

    • #1779 2f43ffa Thanks @shrey150! - feat: add cdpHeaders option to localBrowserLaunchOptions for passing custom HTTP headers when connecting to an existing browser via CDP URL
    • #1834 63ee247 Thanks @tkattkat! - Update stagehand agents search tool
    • #1774 521a10e Thanks @seanmcguire12! - add new page.setExtraHTTPHeaders() method

    Patch Changes

    • #1759 505e8c6 Thanks @shrey150! - Add bedrock to the provider enum in model configuration schemas and regenerate OpenAPI spec.
    • #1814 7dc35f5 Thanks @tkattkat! - Change usage of openai provider in agent to default to store:false
    • #1846 335cf47 Thanks @aq17! - Fix streaming finished event being silently dropped. The final SSE event containing the result payload (success status, message, actions, usage, and messages) was previously discarded instead of being yielded to the caller.
    • #1764 6ba0a1d Thanks @shrey150! - Expose headers in GoogleVertexProviderSettings so model configs can pass custom provider headers (for example X-Goog-Priority) without TypeScript errors.
    • #1847 4ff3bb8 Thanks @miguelg719! - Enable FlowLogger on BROWSERBASE_FLOW_LOGS=1
    • #1752 c27054b Thanks @derekmeegan! - fix: pause Browserbase agents while captcha solving is active and improve CUA recovery after the solve completes
    • #1800 2abf5b9 Thanks @shrey150! - Make projectId optional for Browserbase sessions — only BROWSERBASE_API_KEY is required
    • #1766 7817fcc Thanks @tkattkat! - Add configurable timeout to tools in agent
    • #1749 7390508 Thanks @pirate! - When connecting to a browser session that has zero open tabs, Stagehand now automatically creates an initial about:blank tab so the connection can continue.
    • #1761 611f43a Thanks @seanmcguire12! - fix issue where handlePossibleNavigation was producing unnecessary error logs on clicks that trigger page close
    • #1817 2402a3c Thanks @tkattkat! - Add support for passing custom headers in clientOptions
    Original source Report a problem

Related vendors