Sessions
A session is the unit everything else on the platform hangs off: it is what operators are paid for, what clients are billed for, and what datasets are cut from. This page documents its lifecycle, the activity events you will see in the log, and what happens after a session ends.
Last updated 2026-08-09
The session lifecycle
Every session moves through a small, fixed set of states. The current state is always visible in the dashboard, and each transition is logged as an activity event, so the history of a session can be reconstructed exactly.
| State | What it means | How it changes |
|---|---|---|
| PENDING | The session exists but no operator is connected yet | Becomes ACTIVE when the operator connects, or CANCELLED if it never starts |
| ACTIVE | An operator is connected and controlling the robot; recording and billing time are running | Can move to PAUSED, COMPLETED, or CANCELLED |
| PAUSED | The session is temporarily halted and no control inputs are accepted | Returns to ACTIVE on resume, or ends from here |
| COMPLETED | The session ended normally; the recording is finalized and the client can rate the operator | Terminal state |
| CANCELLED | The session ended before normal completion, whether by a party or by the platform | Terminal state |
The distinction that matters most in practice: COMPLETED sessions produce a finalized dataset and a ratable operator, while CANCELLED marks sessions that did not run their course. Both are terminal; a session is never reopened.
Activity events
While a session runs, the platform writes a timestamped event log. Clients see it live during monitoring, and it stays attached to the session afterwards for auditing. These are the events you will encounter.
| Event | Meaning |
|---|---|
| SESSION_START | The operator connected and the session became ACTIVE |
| SESSION_END | The session ended and moved to a terminal state |
| PAUSE | The session was paused; control input is suspended |
| RESUME | The session returned from PAUSED to ACTIVE |
| ACTIVITY_CHECK | A periodic check confirming the operator is actively controlling the robot |
| INACTIVITY_WARNING | No operator input for a while; the operator is warned before anything is stopped |
| INACTIVITY_STOP | The operator stayed inactive after the warning and the platform stopped the session |
| OPERATOR_SWITCH | Control passed from one operator to another within the same session |
| ERROR | Something went wrong, such as a stream drop or a control fault, and was logged |
The inactivity chain exists to protect the client budget. ACTIVITY_CHECK events fire periodically; a stretch without input produces an INACTIVITY_WARNING, and continued silence an INACTIVITY_STOP. For operators the practical advice is simple: if you need to step away, pause the session instead of letting the warnings arrive.
Session chat
Client and operator share a chat for the duration of the session. It is the channel for task instructions, scene problems, and coordination: an object out of reach, a camera that needs adjusting, a change in what the client wants demonstrated. Messages are stored with the session and can be reviewed after it ends, which is useful when a rating or a dispute needs context.
Rating after completion
When a session reaches COMPLETED, the client can rate the operator on a 1 to 5 star scale and leave feedback. Ratings feed the operator's overall score and their visibility on the platform, so they are the main quality signal the marketplace runs on. Rate honestly: an inflated rating for a sloppy session sends the next client to the same experience.
Session data becomes training data
Throughout an ACTIVE session the platform records robot telemetry, operator inputs, and the camera feeds. After completion, the recording is organized into episodes and appears in the client's dataset browser in LeRobot format. From there it can go directly into training pipelines for ACT, Diffusion Policy, SmolVLA, or GR00T fine-tunes, with the usual caveat that GR00T requires LeRobot v2.1.
This is why session discipline matters beyond politeness. Every pause, every idle stretch, every improvised detour is part of the recording. Clean sessions produce clean episodes; messy sessions produce data that has to be reviewed and trimmed before it is usable.
Extending a session
When work runs longer than planned, a session can be extended rather than cut off at the booked end. Extension is only possible while the session is still running and the robot has no conflicting booking behind it; the extra time is billed like the rest of the session under your plan. If an extension is not possible, complete the session normally and book a follow-up: the dataset browser keeps the episodes of both sessions side by side in the same environment.
Frequently asked questions
What is the difference between COMPLETED and CANCELLED?▾
COMPLETED means the session ran its course: the recording is finalized and the client can rate the operator. CANCELLED means it ended early, whether a party ended it or the platform stopped it. Both are terminal states.
Can another operator take over mid-session?▾
Yes. A handover is logged as an OPERATOR_SWITCH event, so the session record always shows who was in control at any point in time.
What exactly triggers an inactivity stop?▾
A sustained period without operator input. The platform first logs an INACTIVITY_WARNING; only if the operator remains inactive after the warning does INACTIVITY_STOP end the session. Pausing deliberately avoids the whole chain.
Where does the data go after a session?▾
Into the dataset browser of the environment the robot belongs to, organized as episodes in LeRobot format. The client who booked the session owns the data.
Run your robots on AY-Robots as a client: set up environments, pair arms and cameras, book and monitor sessions, browse datasets, and track billing.
What a remote robot operator does on AY-Robots: get certified, run teleoperation sessions, deliver clean training data, and get paid via Stripe Connect.