Skip to main content
A run is one task. You create runs — nothing else. A run automatically gets a browser, a session (for follow-ups), and a workspace (for files) as needed, and returns their ids.

Start a run

The raw endpoint returns immediately (the run is async):
You get sessionId (to continue) right away; files live on that conversation automatically (no workspace id to handle — see Files). The browser is provisioned in the background — its browserId is not in this response; it appears on GET /runs/{id} once ready. Then watch the run until status is completed and read result (the answer string; output is only populated for structured output). The SDK run() waits for you and returns the finished run.

Run body

Common fields (full list in the API reference):
There is no top-level browser_profile_id on a run — pass it inside browser ({"browser": {"profile_id": "..."}}). And there is no structured_output request field yet: completed runs have a typed output field in the response, but the request parameter is not accepted by the API today (422 Extra inputs are not permitted). To get structured data now, describe the exact JSON shape you want in the task text and parse result.
A run provisions its browser. It does not accept an existing browser_id. If you want to drive a browser yourself over CDP, create a standalone browser instead — that’s a different flow.

Structured output

There is no structured_output request parameter yet — sending one returns 422 "Extra inputs are not permitted". Until it ships, get structured data by describing the exact JSON shape in the task text and parsing result:
The run response reserves a typed output field for native structured output; it is null until the request-side schema parameter is released.

browsercode

Same shape, different agent — for code + files + terminal work: