browser-use is one of the most talked-about browser-agent libraries of the past two years: you state a task in one sentence, and it opens a browser, reads pages, clicks buttons and fills forms until it hands back a result. It sounds like the end point of automation. In practice it behaves more like a smart intern billed per step: capable, and fully able to step into every pothole on the way.
Official repository information
The project lives on GitHub under the browser-use organization, in a repository also named browser-use, MIT-licensed and written in Python, with well over a hundred thousand stars. Underneath, it drives a real browser through Playwright, while an agent loop understands the page and decides the next action. It works with models from OpenAI, Anthropic, Google and others, and with local models too. The team also sells a hosted cloud browser service, which is a separate thing; self-hosting the library itself costs nothing.
How it works is how it bills
Each step runs like this: the current page structure is turned into text for the model, the model decides where to click or what to type, the action executes, and the loop looks at the new page. A seemingly simple job, comparing prices across a few sites and filling in a form, easily burns twenty or thirty steps, meaning twenty or thirty model calls. On a flagship model, one task can cost an order of magnitude more than you guessed; on a cheap model, worse judgement means more steps, and the bill grows anyway. The honest way to save money is to measure the per-task cost on a real job before scaling.
Deployment cost: easy to install, harder to keep alive
Local setup is not demanding: a Python environment plus Playwright and a browser build will run it, with the first install mostly about downloads and dependencies. Keeping it alive is the work: headless browsers on a server need handling for fonts, pop-ups, timeouts and memory, and one site redesign can break a task that worked yesterday, so someone has to keep watching and fixing. As a one-off script none of this matters; as a production system, staff it like a service.
Four real pitfalls
First, login walls and captchas. Sites requiring sign-in, SMS codes or human verification regularly stall the agent; reusing your real browser's logged-in state gets around some of it, but that exposes your account to an automated program, at your own risk. Second, prompt injection from webpages. Page text becomes the model's context, and a hostile page can nudge it toward wrong clicks or leaking what you gave it, so payment and account tasks need isolation. Third, unstable success rates. The same task passing today and failing tomorrow is normal, which rules out unattended runs for orders or registrations that cannot be redone. Fourth, speed. Every step waits on the model, so minutes per task are common, and batch runs grow time and API bills together.
It fits work where the flow keeps changing and cannot be frozen into a script: competitor checks, form shuffling, turning page content into structured data, with a human reviewing results. For fixed flows, a hand-written Playwright script or traditional RPA is cheaper and steadier.
