Skip to main content
A run is one execution of a harness: a message goes in, the agent works on its machine, and what comes out is a transcript, some outputs, a tree of whatever it spawned, and a bill. This page starts one and follows it to the end.

What a run needs

Two ids and an input. The harness is the code the agent is — the tree that runs is the tip of its main branch, and the run records the exact commit it got.
The machine is the computer it runs on. A run happens somewhere: the filesystem it writes to, the shell it opens and the browser it drives all belong to a machine, and that machine keeps them between runs. Machines are listed on /v1, which speaks raw UUIDs:
v2 wants that id in public form, which is a pure encoding of the same UUID:
The machine must already run the harness you name. Point a run at a machine belonging to another harness and it is refused: 422 validation_failed, “The machine runs a different agent.”, with /machine_id: the machine runs another harness.

Create a run

201, with Location: /v2/runs/run_01M1GFRNR5F4N8S2JZV85T30A4. The run is queued, not finished — the call returns as soon as the work is accepted.
string
required
The harness to execute. It runs the tip of main, and the answer tells you which commit that was.
string
required
The machine to execute on. Required unless you continue a chat that is already on one.
object
required
{"role": "user", "content": [...]}. Content parts are {"type":"text","text":...}, {"type":"json","value":...} or {"type":"file","url":...,"media_type":...,"name":...}.
string
Continue an existing chat instead of starting a new one. The run inherits that chat’s machine and memory.
object
Yours to use — up to 50 keys of string, number, boolean or null. Keys starting with splox. are reserved.
Send the same key and body again and nothing new happens: the original run comes back with Idempotency-Replayed: true. Send the same key with a different body and you get 409 idempotency_key_conflict.

Follow it

Two ways: subscribe to the event stream, which is what the app does, or poll the run. Streaming is its own page — Streaming — and polling is one request:
A failed run carries a failure object with a stable code, a message written for a person, and whether retrying could help:

Read the transcript

Messages are the conversation the model actually had, oldest first:
Roles are user, assistant, tool and system. Everything that is not plain prose arrives as a json part with its own type inside — tool_call, tool_result, reasoning — so a client that only knows about text can render the text parts and ignore the rest without losing them.

Read the outputs

Outputs are what the run produced, as opposed to how it got there. The final answer is one of them:
type is result or artifact; value is arbitrary JSON. If you want one thing from a run, this is the endpoint to read.

The tree

An agent hands work to sub-agents, and each of those is a run of its own. The tree is a consistent snapshot of the whole family:
Depth is counted in chats, not runs: every run of this run’s own chat is depth 0 — the two above are two turns of the same conversation — and a chat spawned by it is depth 1. child_run_ids are the runs of the chats this one started.

The bill

input_tokens counts only the prompt tokens that were not served from cache, which is why it looks small beside cache_read_tokens: an agent turn re-sends a long prefix and the provider serves most of it from cache. total_tokens is the honest figure. Usage covers the same set of runs the tree does, so two turns of one chat report the same numbers, and final is false while anything in that set is still running.

Cancel

Cancelling is idempotent and always answers 200 with the run as it now stands. A run already in a terminal state comes back unchanged — cancelling a finished run is not an error. A run that is mid-turn normally passes through cancelling before it reaches cancelled.

List runs

Newest first, by (created_at, id). Filters: status (comma-separated, e.g. status=running,waiting, or repeated status= parameters), harness_id, created_after, created_before, plus cursor and limit. Follow page.next_cursor while page.has_more is true.

A second turn in the same chat

Pass chat_id and the run joins the conversation rather than starting one — same machine, same memory, and the agent can refer back to what it already did:
The new run reports the same chat_id, and its single output is the answer to a question that only makes sense in context:

The same run in the SDKs

The published SDKs (Python and Node 0.5.4, Go v2.0.0) do not send machine_id, so runs.create against the current API answers 422 validation_failed with /machine_id: machine_id is required. Until they ship it, create runs over HTTP as above; every other call in all three SDKs works against the live API.