> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pre.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser Agents

> Run browser workflows and extract structured data through REST, SDKs, or MCP.

export const Workflow = ({label, steps, note}) => <figure className="pd-visual not-prose" aria-label={label}>
    <ol className="pd-workflow">
      {steps.map((step, index) => <li key={step.title}>
          <span className="pd-step-number" aria-hidden="true">{index + 1}</span>
          <strong className="pd-figure-title">{step.title}</strong>
          <p>{step.description}</p>
        </li>)}
    </ol>
    {note && <p className="pd-workflow-note">{note}</p>}
  </figure>;

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.

<CardGroup cols={2}>
  <Card title="Run your first task" icon="play" href="/browser-agents/quickstart">
    Extract a page heading with curl, Python, or TypeScript.
  </Card>

  <Card title="Use an MCP tool" icon="plug" href="/browser-agents/mcp-tool">
    Give your assistant browser automation and structured results.
  </Card>
</CardGroup>

## 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

<Workflow
  label="Submit browser tasks and retrieve each outcome"
  steps={[
{ title: "Submit tasks", description: "Send URLs, instructions, and the output shape you need." },
{ title: "Save the run ID", description: "After credit and queue checks, tasks can start or wait." },
{ title: "Follow the run", description: "Poll the saved ID or stream available progress events." },
{ title: "Read each outcome", description: "Check every task’s status before consuming its data." }
]}
  note="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](/browser-agents/api/task-status#batch-and-task-states) includes an interactive example of queued, running, completed, and failed work.

## Choose how to receive results

| Interface                                                   | Behavior                                           |
| ----------------------------------------------------------- | -------------------------------------------------- |
| [Synchronous request](/browser-agents/api/run-task)         | Wait for the run and return JSON                   |
| [Async request](/browser-agents/api/run-task#async)         | Return the run ID, then poll or attach a stream    |
| [Submission stream](/browser-agents/api/run-task#streaming) | Live SSE events and a full final result            |
| [Existing-run stream](/browser-agents/api/stream-task)      | Initial snapshot, live events, and terminal status |
| [Live browser](/browser-agents/api/live-browser)            | View available browser frames over WebSocket       |

Task counts, account in-flight limits, and per-run concurrency are different controls. Check [queue status](/browser-agents/api/queue-status) when submitting larger workloads.

## Credits

Successful tasks have a **0.1-credit minimum**; more complex tasks can cost more. Failed tasks settle at zero credits. Submission reserves or charges the task floor before execution, so you need available credits to start. Read [billing and limits](/browser-agents/api/run-task#billing-and-limits) for details.

## Benchmark

Explore the [interactive benchmark report](https://pre.dev/browser-agents-benchmark.html) for task results, costs, timings, and execution traces. The [reproduction repository](https://github.com/predotdev/browser-agents-benchmark) includes task definitions and scoring rules.

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.