Provide robot data

You run teleoperation, own a robot cell or operate remotely. Buyers order units from your listings with credits already held. You record each unit under a code Latent issues, deliver it with a manifest, and are paid for every unit the buyer accepts, or that is accepted for them at the deadline. Nothing is priced by the hour.

Go to Sign in, pick Provide robot data, and enter your work email. The link works once and expires in 20 minutes. One account can both order and provide. Use this same account for your API keys, or your cell will not see your orders.

Turn on emails for new orders in Settings, Email. New orders also show in the Provider console and in node latent.mjs orders.

In the Provider console, fill in a name, kind, country (two letters) and the platforms you operate. Location, bio, rigs, hours per week, latency to the robot and up to six links are optional but are what buyers read. Your public page is /providers/<slug>. Create the profile; it starts as a draft only you can see.

A listing is one unit type on one platform with a price per accepted unit, from $1.00 to $100,000.00, and a minimum quantity per order. You receive the price minus the platform fee shown in the console.

Weekly capacity is shown to buyers and not enforced: decline larger orders or agree a schedule in the messages. After the first listing you can add the other unit types at the same price in one click.

With one active listing, press Submit for review. Latent checks the profile, usually within one business day, and emails you when you are listed. You can keep editing meanwhile; once listed, edits go live as you save.

Each order arrives with the buyer's credits already held, and Latent emails you. Read the terms first: instruction, rubric, required streams, minimum length and the decide window. They are frozen and every reject code refers back to them. Accept to commit to the quantity, or decline to release the hold; you can tell the buyer why. Orders not answered within 3 days are declined automatically. Questions go in the order's messages.

Per robot, the record and connect steps live at /robot: the Axol's install line, and the lerobot-record recipe for a reBot B601, a Maker Arm Station or any other LeRobot arm, with the recording code in the task string.

A connected Axol

An Almond Axol connects with one install line from Connect a robot, then records and delivers by itself: an order you accept records on the robot, which gets a fresh recording code for each take and delivers the take after you save it. There are no codes to issue and nothing to deliver by hand. The first take, from the headset to the delivered unit, is in the Axol guide. To test the whole path alone, press Practice take on the robot in the console: an order of 1 unit with no buyer and no credits.

Browser

Drop the episode's folder on the order page. Files are hashed on your machine, then sent into Latent custody with Upload to Latent, the default wherever Latent storage is on. With Hosted by me, only the hashes are sent.

Cell CLI

Node 22, no install, one file served by Latent. Check it against the published sum before you run it (on a Mac, use shasum -a 256 -c - in place of sha256sum -c -).

curl -fsSLO https://latentenergy.com/tools/latent.mjs
curl -fsSL https://latentenergy.com/tools/SHA256SUMS | grep ' latent.mjs$' | sha256sum -c -
node latent.mjs orders

Every command on this page runs the downloaded file with node latent.mjs, from the folder you saved it in.

In Account settings, Create a key, label it after the machine, and keep Read and Order ticked. Tick Cell keys as well when the machine registers its own signing key with node latent.mjs key register. It starts with vc_ and is shown once. On the recording machine, put it in the shell, then run node latent.mjs orders to confirm it sees your orders.

export LATENT_API_KEY=vc_...
node latent.mjs orders

Write latent.json in the folder you run from with operator_id, robot_id, station_id, format, camera_count and storage_base. The key stays in the shell, not in the file. The site address is read only from LATENT_ORIGIN, never from the file.

{
  "operator_id": "op-01",
  "robot_id": "axol-01",
  "station_id": "station-01",
  "format": "lerobot_v3",
  "camera_count": 2,
  "storage_base": "https://files.example.com/cell-01"
}

Recording by hand, issue one code per unit you will record in the next 72 hours before each take: on the order page, or with node latent.mjs seeds <order> <n>. Press Show card on the order page, or print the open codes, and hold it in the overview camera's view for the first 3 seconds, then record. The recording must start after the code was issued and before it expires. Each code is used by exactly one unit. A connected Axol gets its own codes; on its orders the order page issues none.

node latent.mjs seeds <order> 3

Where Latent storage is on, each unit's files go into Latent custody by default: the order page, the cell CLI and the Axol package upload them, Latent hashes the stored bytes, and the buyer downloads from Latent. The storage URL is then latent:// and the upload id, set for you. An order can require custody.

To host the files yourself (Hosted by me on the order page, --no-custody for the CLI), put each episode's folder where the buyer can download it over https and give that link as the storage URL (storage_base in latent.json does it per folder). A unit without a link warns the buyer and is likely to be rejected.

• Browser: drop the folder, check the filled fields, press Deliver.
• CLI: node latent.mjs deliver <order> ./episode --seed <episode id>.
• A connected Axol: nothing to do. It delivers each take about 20 seconds after you save it, and the order page shows the result.

node latent.mjs deliver <order> ./episode-1 --seed <episode id>

A failing check refuses the delivery, creates nothing and keeps the code open; fix it and deliver again. A file hash already delivered anywhere on the market is refused.

Interventions need the takeover span, a failure class and, if you give latency, a median under 300 ms. Corrections need the failed log reference and the policy version.

node latent.mjs deliver <order> ./takeover-1 --seed <episode id> --takeover 12:36 --failure grasp_miss --latency 60:120 --policy policy-v7

node latent.mjs deliver <order> ./fix-1 --seed <episode id> --failed-log <failed run id> --policy policy-v7

The buyer accepts or rejects each unit within the order's decide window (7 days unless the order sets another) and may extend once. Latent emails you a summary of each batch of decisions.

A reject names a code: not as specified, wrong platform, missing streams, truncated, duplicate, quality below the bar, takeover not needed, takeover late, or other with a reason. A unit nobody decides is accepted at its deadline. Latent can reverse an accept within the clawback window (14 days by default).

If you disagree with rejects, open a dispute from the order page; on a completed order you can do so inside the clawback window.

When an order completes, or is cancelled, with at least one unit still charged, each side rates the other once: overall, quality, communication and timeliness, and a text. A review of a cancelled order is labelled as one. The window closes 14 days after the order completed or was cancelled; neither side can review during a dispute, so the time the dispute lasts is added back to the window when it closes.

A review stays sealed until it is published: only its author sees it, and the order record shows a seal of it, never its ratings or text. Both reviews publish together as soon as both sides have written one. A lone review publishes 14 days after it was written, and only once the window has closed and the order is not in dispute, so the other side never reads it before writing theirs. The order page checks each published review against its seal.

Acceptance rate, response time and units completed on your page come from finished orders, not from your profile.

Each accepted unit adds the price minus the fee to your earnings. Earnings stay pending until 14 days after the order completes, are held while an order is disputed or the buyer's account is frozen, then become payable.

Providers in the United States set up payouts from the console: press Set up payouts and give your identity and bank details to Stripe in Stripe's own onboarding. Latent never sees your account number. Latent sends your payable balance to your Stripe account on the schedule the console shows, and Stripe pays it out to your bank. Providers elsewhere are paid by bank transfer, and each payment is recorded in the console.

Latent needs a W-9 (US) or W-8 (non-US) on file before your first bank transfer, and before your first payout through Stripe until Stripe's tax reporting is confirmed for this site. Latent asks for it at verification, and the console says whether you still need one.

Every payout appears in your console. Latent emails you when a payout is sent or fails, when a reversed payout is held for review, and when that amount is released back to your payable balance.

When you write to support, include the request id the CLI prints. The full list of checks and error codes is in the API docs.