Tools like Anchor give a model navigate and click; this one takes a sentence and decides the clicks itself. That is far less context per task and far less control, which is why get_session_messages matters: it is the only way to find out what it actually did. Two operational details worth planning for — browser profiles hold real logins, so a profile is a credential, and stop_session's task strategy lets you cancel a runaway step without losing the session's state.
Browser Use's v3 endpoint. We connected and it listed seven tools; the handshake describes itself as a session-based agent with sandbox execution. The unit here is a session, not a click — you give it a task and it drives the browser itself.
- run_session — create a session and run a task, with an optional output schema, proxy country and browser profile
- send_task — a follow-up task in a keep-alive session that is idle
- get_session and get_session_messages — poll for completion, and read the agent's own steps, reasoning and browser actions
- stop_session — end just the current task, or the whole session
- list_sessions — recent sessions with status and cost
- list_browser_profiles — cloud profiles that hold persistent cookies and logins
An API key in the x-browser-use-api-key header. Sessions report their cost, so spend is visible per run.
Paste a URL with a key — add the endpoint to your client