Guide

OpenClaw + Browser Use: Give the Agent a Goal, Not a Click Script

Q: What does Browser Use add that a browser driver does not?

Browser Use plans the steps itself. You describe a goal instead of scripting clicks, which fits agent tasks where the page structure is unknown in advance.

Q: Where do the browser sessions run?

On the external Browser Use deployment. The instance installs only a scoped HTTP client, so browser workers and sessions stay off the bot.

Q: Does Browser Use need its own model key?

Yes. Browser Use runs its own planning loop with its own model configuration, separate from the model your agent uses. Keep that key scoped to the Browser Use deployment.

Browser Use turns a described objective into browser actions. Connected to OpenClaw or Hermes it becomes the tool you reach for when the page layout is unknown and a hand-written selector would break on the first redesign.

Two layers of agency, and why that needs care

This connection stacks one agent on another. Your OpenClaw or Hermes agent decides to delegate a web task; Browser Use then plans and executes its own steps inside the page. That is powerful and it is also the reason to keep tasks narrow: a vague objective handed to a nested planner produces a long session whose individual decisions you never see.

The practical rule is to delegate one verifiable outcome per call. "Return the three pricing tiers from this URL as JSON" can be checked. "Research their pricing" cannot.

1. Deploy Browser Use with its HTTP API

Follow the official Browser Use documentation to run the service and expose its HTTP API. Pin the version, configure the model Browser Use itself will call, and front the whole thing with an authenticated TLS reverse proxy — the API can drive a browser anywhere, so it must never be public.

2. Connect it from Dashboard Tools

Open Dashboard Tools, select a running instance, and connect the Browser Use card. The dashboard asks for the base URL — the placeholder is https://browser-use.example.com — and an optional scoped token. It then installs a small HTTP client inside the instance along with a managed skill describing the available calls. That client lives at a managed path — tools/dashboard-api-connectors/browser-use/tool — and the examples below use tool as shorthand for it.

# Inspect what the connector is pointed at, without printing the token
tool info

# Discover the OpenAPI document the service publishes
tool discover

# Hand over one bounded task
tool post /api/v1/run '{"task":"Open the home page and return the main heading"}'

Printed responses are capped at 5 MB, and the client sets a 120-second socket timeout. Read that limit precisely: it bounds a stalled connection, not total runtime, so a Browser Use session that keeps trickling output can run well past two minutes. Put the real deadline on the Browser Use side.

3. Write tasks that can be graded

Name the entry URL. Letting the planner find the site doubles the number of ways it can go wrong.
State the output shape — a table, a JSON object, three bullet points — so a wrong answer looks wrong.
Say what not to do: no logins, no form submissions, no purchases, unless that is explicitly the task.
Ask for evidence. A returned URL or quoted line makes a fabricated answer easy to spot.

Production hardening

Authenticate the endpoint and keep it off the public internet; scope the token to this instance.
Block private ranges and cloud metadata addresses from the browser host.
Cap concurrency, session duration, and per-task step count on the Browser Use side.
Never give the browser profile a personal logged-in session for unattended work.
Watch the Browser Use model spend separately — a nested planner is the easiest place for cost to hide.

Browser Use versus Playwright MCP

Pick Browser Use when the goal is known and the path is not. Pick Playwright MCP when you know the steps and want determinism, lower cost, and no second model in the loop. Many teams end up with both: Playwright for the repeatable flows they have already mapped, Browser Use for the one-off "go find out" requests.

Frequently asked questions

What does Browser Use add that a browser driver does not?

Planning. A driver needs the steps; Browser Use takes a goal — "find the pricing page and return the tiers" — and works out the navigation and clicks itself. That suits agent work where the page structure is unknown until you look at it.

Where do the browser sessions run?

On your Browser Use deployment, not in the bot. The instance installs a scoped HTTP client only, so browser workers, sessions, and their memory footprint stay on the external server.

Does Browser Use need its own model key?

Yes. Browser Use runs its own planning loop and needs a model configured on its side, separate from the model your OpenClaw or Hermes agent uses. Budget for two model bills, and keep the Browser Use key scoped to that deployment.