0. Take the specification first
1. Connect a model
The API runs an agent against a model credential your organization owns. In the Console, Settings → LLM models, connect one. The connection is verified against the provider when you save it, so a wrong key fails there rather than inside your first turn. Note the credential’s id if you want to name it explicitly. A session created without one uses the organization’s default. You can also do this entirely from the terminal, once you have a token — see model-credentials.md:model is what goes in agent.model. Asking for one this organization has
not connected is refused by name, and so is naming a credential id that is not
one of its own.
2. Get a token
If you have just signed up, you already have one. A read/write key is minted when your account first gets a workspace, and the screen you land on after signing in hands it over. It is shown once and does not expire; Settings lists it as created at signup, and you can revoke it there. If you missed it, or you want a second one, mint it yourself: Settings → Developer access, name it, choose Agent API · read/write, create. The full value is shown once. The kind matters. The default is CLI import, which holds only thecli
scope and is refused by every /v1 route — that default exists so tokens
minted before this API existed keep doing exactly what they did. Choose
Agent API · read if your integration only watches.
/v1/health answers for any valid token, whatever its scopes — it is how you
find out what a token can do without guessing.
3. Set up your caller
Pick your language once — the rest of this page, and the whole site, follows your choice.fetch and urllib are in the runtime you already have.
When the TypeScript and Python clients ship, they
replace this helper and nothing else on the page changes.
4. Create a session
environment.state reports:
preview.published_url above is null because nothing is published yet; see
preview.md for putting what the agent is serving at a public
address.
You do not have to wait for running before sending work: a message queues
against a session in any of these states and the workspace comes up to serve
it. Poll it only if you want to show someone what is happening.
A model is the only thing it needs. When you want this session to hold your
repository, your files, your secrets, or a limit on what the agent may do
without asking, that is all in configuring a session — and none
of it is required to finish this page.
5. Send work
202, not 200: the agent has the work, not the answer. queued: true means
a turn was already running and yours will follow it — accepted, not rejected.
content also accepts a plain string. Send one event per request.
outputs is not decoration. Anything the agent writes under
/workspace/outputs is published as an artifact you can download later;
anything it writes elsewhere lives and dies with the workspace. Step 8 is the
difference.
The other three things you can send — a tool result, a steer, a stop — are in
input.md.
6. Wait for the turn
A turn is one run of the agent. Poll it, or read events.md and stream instead.status is working until it settles, then completed, failed or
cancelled. There is no fourth value: a turn parked on you is still
working. What changes when the agent needs an answer is the session —
status becomes requires_action and required_actions fills in. Poll that,
not this. See required-actions.md.
A cold sandbox makes the first turn minutes rather than seconds.
7. Read what happened
message, tool_call, command_execution,
file_change, approval, question, mcp_unavailable, error. A message
carries role and content; the rest carry a type-specific detail.
error is the one to look for when a session reports failed and you find no
turns: a run that could not start leaves no turn behind, and this item says
why — detail.message. It used to be on the event stream only, so an
integration that polls had nothing to read.
This is the transcript, and it outlives the sandbox.
8. Collect the output
Anything the agent writes to/workspace/outputs is published when the turn
settles, and stays readable after the sandbox is gone.
9. Clean up
Next
You have a session, a turn and its output — an agent worked and you have the file. Everything past this point is about making that reliable. Production integration is the next page if you are putting this in a service: which token to give which process, the loop that survives a dropped connection, and taking many files out at once. Otherwise, by what you are building:- guides — six complete programs: documents to JSON, an agent behind your API, approvals, live progress
- sessions.md — your repository, your files, your secrets, limits on what the agent may do
- saved-agents.md — save this configuration under a name and reuse it
- events.md — stream instead of polling, and resume where you dropped
- required-actions.md — let the agent call your code
- webhooks.md — be told instead of watching
- pagination.md — paging any collection, and finding a session by your own job id