The above image captures the way that I often felt as I spent some time pushing the limits of the state of the art in Agentic Browser Automation. Our first post chronicled some of our adventures with BrowserUse, which is perhaps the preeminent browser automation framework (at least by the infallible metric of Github stars). Being in the space, we wanted to understand the landscape better and so looked into both StageHand from Browserbase (not to be confused with BrowserUse) and HyperAgent from Hyperbrowser.
Specifically, we are interested in stealthy, reliable browser automation and wanted to measure each technology on: accuracy (how well were instructions adhered to and with what fidelity were tasks carried out), speed (end to end duration including planning and execution), and developer ergnomics (how painful was it to get to work).
Our main goal was to measure the ability for web automation post signin as signin is done by our framework. Our canonical test for this is reordering chicken nuggets from McDonald’s (after using our own framework to signin) and other such tests of instruction following in real world scenarios. Thus, we need to be undetected and accurate in actions, yet ideally fast in both execution and implementation.
I’ll do a quick recap of BrowserUse, then dive into Stagehand and finally HyperAgent.
BrowseUse
Accuracy: 3/5 (5 is best)
Speed: 2/5 (5 is best)
Developer Ergonomics: 4/5 (5 is best)
BrowserUse was quite easy to get setup and made one critical decision which made local integration much, much easier than the others: they allowed the developer to pass their own BrowserContext.
Unfortunately, both the reliability as well as the speed were poor with BrowserUse in our experience. We used o4-mini for the model (some of this was done prior to GPT-5’s release). Most of the time the end-to-end latency was around 2-3 minutes. See the blog for more details on the failure modes.
Technically, one interesting note is that the overlays are drawn into the live page while navigating and they maintain a index-selector map that can get out of sync leading to null actions. These potentially impact reliability.
StageHand
Accuracy: 1/5 (for our purposes)
Speed: 3/5
Developer Ergonomics: 3/5
Stagehand does a phenomenal job at describing the spectrum from raw automation to pure, unguided agentic meanderings and how a middle abstraction is the right solution. They do offer a competitor interface to BrowserUse (ie more autonomous) called execute which we decided to use to have a fair comparison.
Initially the integration seemed to be smooth, and the initial test was post signin were we able to perform actions on DoorDash’s website. Unfortunately, we hit a major roadblock regarding the stealth capabilities. As the screenshot above shows, the browser that StageHand launches is detected by Cloudfare.
This issue is easily reproduceable and can be tried at the following documentation pull request. It is a shame that we ran into this issue, because they do support (in a slightly opaque way) the ability to specify your own browser profile (user data dir, which allows for session persistence). However, without specifying your own browser context, you are left to the mercy of the playwright stealth capabilities that they use. Additionally, the developer giving the context would preclude needing to do the interception of the user data dir that they do in options. Technically, they are the only one of the three to choose to use the computer use preview models (notably their focus is on the more granular actions than the generic execute, but the stealth problems would happen irrespective).
HyperAgent
Mission successful!
Accuracy: 4/5
Speed: 4/5
Developer Ergonomics: 1/5
Perhaps spoiling the surprise, we managed to successfully reorder chicken nuggets from our (now-favorite) McDonald’s. However the path to get there was not easy…
HyperAgent (for now) is typescript only; however, they do not accept a user data directory nor a browser profile. As such, I ended up forking HyperAgent to allow a user data dir. However, to make use of this, I needed to also create a CLI wrapper to allow for HyperAgent to properly be run (as their CLI was not sufficiently configurable at the time of testing).
A long time ago, when we were evaluating different options for how we would build our core offering, we investigated HyperAgent and at the time they were using rebrowser-playwright. After we mentioned to them that patchright was better they started sponsoring them and recently switched to them! This was quite fortunate as they were not detected when navigating the Doordash website. If you’d like to try ordering DoorDash yourself, you can follow the steps here.
HyperAgent was also surprisingly fast too with a 100s end-to-end latency. Part of this is attributable to their default model being GPT-4o (which is not a reasoning model) and part of this is likely due to their way of annotating the screenshots taken with the interactable DOM elements. Regardless a ~3x speedup from BrowserUse was welcome!
Takeaways:
There wasn’t any one clear winner out of the three. As with all tasks, depending on what matters to you, the right answer will change. However, if you’re building such a framework, allow others to pass in their own browser context! More generally, choices when the the interfaces are the same (such as in launching a browser versus accepting a browser context) should be left to the devs. This was one of the best decisions of BrowserUse.
Each framework has its own take on what context from the web page should be sent to the LLM and how actions are surfaced to them. These certainly can make a big difference. The underlying model likely matters for both accuracy and latency, but there is a surprising variety of models supported by each of the three frameworks investigated.