Libretto vs Browser Use: deterministic scripts vs a runtime agent.
Browser Use is a strong fit when you want an agent to figure out a browser task at runtime. Libretto is for the moment after that: when the workflow is known, needs to run reliably, and should become fast, inspectable code your team owns.
- Use Browser Use for open-ended exploration, one-off tasks, rapidly changing pages, and prototypes where maintaining a script would be premature.
- Use Libretto when a workflow is repeated enough that speed, determinism, debuggability, and per-run cost matter.
- In Libretto's own internal benchmark on the same multi-step workflow, a Libretto-generated script completed in ~16.3 seconds versus ~79.5 seconds for the runtime-agent approach.
Browser Use runs an agent at execution time
Browser Use is a popular open-source library for giving an LLM-driven agent control of a browser. On each run, the agent observes the page, reasons about the current state, decides the next action, and continues until the task is complete or stuck.
That runtime-agent model is useful precisely because it is flexible. If the page is unfamiliar, the task is exploratory, or the target keeps changing, you may not want to encode a maintained script yet. You can point the agent at the task and let it adapt.
Libretto records once, then compiles to code
Libretto takes a different path. A coding agent uses the CLI with a live browser to inspect pages, record a workflow, capture useful network calls, and turn the result into a deterministic script. The script can combine Playwright interactions with direct in-session API calls when the browser reveals a cleaner underlying request.
The important shift is ownership. The output is plain code: readable, inspectable, debuggable, versionable, and deployable. Instead of asking a model to rediscover the workflow every time, you run the script you have already inspected.
Comparison table
| Dimension | Browser Use | Libretto |
|---|---|---|
| Execution model | An LLM-driven agent observes the page, reasons, and decides actions at runtime. | A workflow is recorded once, then compiled into a deterministic Playwright-plus-API script. |
| Reliability across runs | — Flexible, but the agent can choose different actions when page state or model output shifts. | ✓ The generated script follows the same inspected code path unless you change the script. |
| Speed | — ~79.5s in Libretto's internal benchmark of the same multi-step workflow. | ✓ ~16.3s in the same Libretto internal benchmark, about 5x faster. |
| Debuggability | — You inspect agent traces and model decisions after the run. | ✓ You debug plain code, recorded actions, network calls, and normal Playwright failures. |
| Token cost per run | — Runtime reasoning consumes tokens on every execution. | ✓ The generated workflow runs as code, so LLM reasoning is not required on every execution. |
| Output you can inspect and own | — The durable artifact is usually the prompt, task definition, and trace. | ✓ The durable artifact is a readable script teams can inspect, debug, version, and deploy. |
| Unknown or changing pages | ✓ Strong fit: the runtime agent can adapt while exploring a page it has not seen before. | — Better after the workflow is known and stable enough to encode as a maintained script. |
| Deployment | Deploy an agent runtime, model access, browser infrastructure, and task prompts. | Deploy the generated automation code as part of your normal codebase or Libretto workflow runtime. |
When to use Browser Use instead
Browser Use is the more natural choice when the browser task is not yet well understood. If you are exploring a new site, asking an agent to gather information once, or working with pages that change faster than you can justify maintaining automation code, runtime reasoning is a feature, not a bug.
It is also a good prototyping tool. You can learn whether a workflow is possible before investing in selectors, API-call extraction, error handling, and deployment. For many internal or one-off tasks, that trade-off is entirely reasonable.
When Libretto is the better choice
Libretto is better once the workflow is known and repeated. At that point, you usually want the browser automation to behave like production code: predictable across runs, cheap to execute, easy to debug, and reviewable in pull requests.
This matters most on fragile real-world sites. Libretto has been battle-tested on complex healthcare and legacy portals where small UI changes, hidden network calls, and brittle state can make pure runtime interaction slow and hard to reason about. Recording the workflow and compiling it into code gives teams something concrete to maintain.
Short FAQ
+Can I migrate a Browser Use task to Libretto?
Yes, when the task has become a known repeatable workflow. Use Browser Use-style exploration to understand the path, then record and compile the workflow in Libretto so future runs execute as deterministic code.
+Is Libretto open source?
Yes. Libretto is an open-source CLI. You can start from the docs or the project website at libretto.sh.
+Does Libretto use an LLM at runtime?
Not by default for the workflow execution path described here. Libretto uses a coding agent while building and maintaining the workflow, then runs the generated script directly instead of asking an LLM to re-reason through every run.
+Is Browser Use the wrong tool for production?
Not categorically. It can be the right tool when flexibility matters more than repeatability, especially for open-ended tasks. Libretto is a better fit when a known workflow needs to run many times with predictable behavior, lower per-run cost, and inspectable code.
+What kinds of sites is Libretto designed for?
Libretto has been battle-tested on complex healthcare and legacy portals: messy, fragile, real-world sites where teams need durable automation rather than one-off exploration.
Try turning one known workflow into a script.
Start with a workflow you already understand, record it with Libretto, then inspect the generated code before you run it again.