Browser Agents
Browser Agents
Run browser workflows and extract structured data through REST, SDKs, or MCP, or let your coding agent use your own Chrome.
Give Browser Agents a starting URL and a task. It navigates pages, interacts with forms and controls, and returns task outcomes with data and an optional execution timeline.
Browser Agents comes in two editions. Cloud, covered on this page, runs tasks on pre.dev’s browsers: send a task by REST, the SDKs, or the browser_agent MCP tool and get structured data back, with many tasks in parallel and nothing to set up. Local lets your coding agent drive the Chrome you already have open, with your profiles and the accounts you are signed in to. Both come in the free, open-source pre.dev MCP server, set up with npx -y @predotdev/mcp setup. In the pre.dev CLI, type /chrome for Local. See Browser Agents Local.
Run your first task
Extract a page heading with curl, Python, or TypeScript.
Use an MCP tool
Give your assistant browser automation and structured results.
Use your own Chrome
Let a local coding agent work in your profiles, logins, and tabs.
Switch from Claude in Chrome
Two steps. Your Chrome profiles, tabs, and logins carry over.
Choose how the task runs
| Mode | Use it for | Supply |
|---|---|---|
extract | Read page content into a known shape | An output JSON Schema, optionally an instruction |
agent | Navigate, search, fill forms, or perform several steps | A clear instruction and success condition; optionally an output schema |
auto | Let the service choose the execution path | A URL and your goal or schema |
Provide an explicit output when downstream code expects a particular structure. If it is omitted, the service may infer an output schema; do not assume a specific data shape or that every task returns text.
Request lifecycle
- Submit tasks. Send URLs, instructions, and the output shape you need.
- Save the run ID. After credit and queue checks, tasks can start or wait.
- Follow the run. Poll the saved ID or stream available progress events.
- Read each outcome. Check every task’s status before consuming its data.
A completed run can include failed tasks. A rejected submission returns an error; inspect its code and next action before retrying.
One request creates one run, also called a batch in response types. A run contains one or more tasks. Use its id to retrieve progress and results; each task has its own status and credit usage.
The status guide shows each task state and what it costs.
Choose how to receive results
| Interface | Behavior |
|---|---|
| Synchronous request | Wait for the run and return JSON |
| Async request | Return the run ID, then poll or attach a stream |
| Submission stream | Live SSE events and a full final result |
| Existing-run stream | Initial snapshot, live events, and terminal status |
| Live browser | View available browser frames over WebSocket |
Task counts, account in-flight limits, and per-run concurrency are different controls. Check queue status when submitting larger workloads.
Credits
Every browser task is charged a 0.1-credit floor when you submit it, so you need available credits to start. When the task finishes, it is charged any usage above the floor, whether it succeeded or not. Only an ERROR or EXHAUSTED task keeps the floor and nothing more.
Read billing and limits for details.
Benchmarks
Our runs on two public benchmarks of tasks on live websites, next to the numbers TinyFish publishes for its own runs:
| Benchmark | Browser Agents | TinyFish, published |
|---|---|---|
| WebVoyager, 641 tasks | 93.9% | 91.1% |
| Online-Mind2Web, 300 tasks | 78.3% | 89.9% |
The Browser Agents figures are the mean of two full runs of each benchmark: 93.1% and 94.7% on WebVoyager, 80.3% and 76.3% on Online-Mind2Web. Under a stricter WebVoyager rule that needs a screenshot showing each claim, the mean is 91.4%. TinyFish’s numbers come from its own runs, with a different harness, patch set, and grader, and we did not re-run them. On Online-Mind2Web, Browser Agents trails TinyFish’s published number.
The benchmark report covers the protocol, results by site and level, the patched tasks and why, and a CSV of every task result from both runs.
Cloud browser tasks do not expose persistent login profiles, reusable cookie sessions, or a recurring-schedule API. Schedule submissions in your own application and provide the inputs each task needs. For work behind a login, use Browser Agents Local: your coding agent works in the Chrome you are already signed in to.