Run artifacts

Some runs leave something behind. A run that drove a browser leaves a recording of the session. A run that downloaded a file and kept it leaves the file. Both show up in an Artifacts section on the run screen, and both are served to you under your own login.

A run that produced nothing shows no Artifacts section at all, rather than an empty heading.

What you see

Each artifact is one row: its name, its size, how long ago it was captured, and a Download link when the bytes are actually there. A video plays inline in the row, so you can watch what the browser did without leaving the page. Rows are ordered oldest first, which is the order the session happened in.

Where the browser provider also has its own hosted player for a recording, the row carries a Watch hosted replay link beside our copy. That link is a backstop, never the main route: its lifetime is undocumented and it is a credential into a system whose scope we do not control, which is exactly why we download the recording and keep our own copy instead.

Browser recordings

A recording is scoped to a browser session, not to a run. A run that opened one session and later, after your approval, opened another produces two recordings rather than one merged file. Each is its own row.

Three things about recordings are worth knowing before you rely on one:

• Recording never puts a run at risk. If starting, stopping, downloading or storing a recording fails, the failure stops there. A run that cannot be recorded still completes.
• The interview's browser is never recorded. It is the one session where you may type real login credentials, and a recording is precisely the kind of durable, downloadable file those must never end up in.
• A long approval wait can cost you a segment. If the browser provider reaps a session while the run sits waiting for a human, that segment's video goes with it. The row then says the recording is not stored. We would rather say so than quietly show you a shorter video.

Collected files

A file downloaded inside the browser lives inside that browser and disappears with it, unless the agent deliberately keeps it. Keeping it is an explicit act: the agent calls a tool for that file, right after the download finishes.

Kept files are capped, per file, per run count, and per run total. A file too large to keep still gets a row, under its real name and its real size, saying it was too large to keep. An honest row about a missing file beats no row.

Getting artifacts over the API

GET /v1/runs/{id}/artifacts lists what a run produced: kind, name, size, media type, whether the bytes are stored, and any hosted view URL. The list is never filtered by whether the bytes survived, so a missing file is still visible under its real name.

GET /v1/runs/{id}/artifacts/{artifact_id} serves the bytes. An artifact is addressed by its own id and nothing else; the storage key is resolved on the server and never appears in a response. Recordings are served inline and support range requests, so a video player can seek through one. A collected file arrives as an attachment under its own filename, because a file the agent kept for you is a file you meant to save.