Quickstart

From a robot file to a policy running on a robot, in the browser: add the robot, train its first policy, gate it in sim, connect a robot with a code, deploy the policy and stop it. A terminal is needed in one place — the jobs that run on your own machine — and every page that queues such a job prints the lines to paste.

Every command on this page was run verbatim before it was published, and docs.test.ts fails the build if this file grows a command that was not. Where a command names this hub, it is printed with the address of the hub serving this page: https://api.mousemouse.ai for the API, https://mousemouse.ai for the web app. Rather type every step? From a terminal is the same hub from the lucen CLI.

Before you start

• An account. Sign in with the button at the top right. Everything below belongs to it — the robot, the runs, the robot you connect — and what is private is invisible to everybody else: a 404, never a 403.
• A robot file: a .zip of the folder that holds an MJCF or a URDF and its meshes. No robot file? Use a reference robot.

1 · Add your robot

Click Add your robot on the front page (or New → Add your robot) and drop the zip on Add your robot.

• Read in your browser, before anything uploads. A path that climbs out of the zip, an absolute path, a symlink or a file that inflates far past its packed size is refused and named. The page finds the model file (pick one if there are several) and reads it with MuJoCo — the build the Sim tab runs.
• You declare what no model file says: the control rate in Hz and what one action means, plus the base for a URDF. Gains (kp, kd), armature and friction are optional flags, and the gains are needed when the model states none (torque motors, or no actuators at all).
• The default pose. A model with a keyframe starts from it, and there is nothing to declare. Without one every joint would start at the model's zero (qpos0), and a joint whose zero sits on a limit makes every sim-gate cell fail however long the policy trains. So the page proposes a pose — each such joint moved a quarter of its range inside the nearer limit, the rest left where they are — and draws it live. Change any value; what you send is what the robot publishes with. A URDF is converted during the check, so its pose is a table without a drawing; the robot page's Sim tab can set it again later.
• Upload and check. Every file is hashed and uploaded straight to storage into a private repo; a file the hub already holds is sent as 0 bytes. The check is lucen robot init and then lucen robot validate on what you uploaded — in a cloud sandbox where this hub has one, otherwise on your own machine by lucen robot worker. The check page says which, and prints the lines when it waits for you.

When it worked: the check's job reads Done, with its pass · warn · fail counts, every warning and failure with what to change, the draft card, and what still needs you. Publish — public or private — and then Published · open your robot. If the check refused it, Drop again with these answers keeps everything you typed, and the files the hub already holds upload 0 bytes.

2 · Train its first policy

On the robot's page, Train a policy. The form has four parts:

1. What to train. MuJoCo PPO trains a reflex policy on CPU, on a task the robot's base decides: a floating base learns to follow a velocity command, a fixed base to hold its default pose and reach joint targets. Isaac Lab PPO runs where this hub hosts it for your account, or on an Isaac Lab box of your own; SmolVLA LoRA fine-tunes a skill policy from one of your datasets, on a GPU.
2. The settings that matter — the length and the template's few settings, at its defaults.
3. Gate while it trains, on by default: every few iterations the newest checkpoint is rolled out in MuJoCo on this robot's own model, and a tripwire can stop a run that is going wrong.
4. Where it runs. Your own machine is free. Lucen cloud is open where this hub has hosted compute: a CPU template within a free monthly allowance for every account, GPUs for the accounts the hub hosts, each with its price before you start.

The hub checks the recipe as you edit — a value it would refuse is shown with its sentence — and Start training submits it. On your own machine the run waits Queued for the runner below.

When it worked: the run page goes Queued → Running, with the live log and curves, → Succeeded. Its Rollouts tab lists every gated checkpoint with its verdict — scored by the same runner that trained it, with no second command — and the robot's Policies tab lists the new model.

Run jobs on your own machine

Nothing trains, checks or rolls out on the hub's own hardware unless this hub has hosted compute and you chose it. A job for your machine waits queued until a worker you started claims it, and the page that queued it prints these lines — the same each time, the last one naming the worker:

curl -fsSL https://api.mousemouse.ai/install.sh | sh -s -- 'cli[rl]'
export PATH="$HOME/.local/bin:$PATH"
lucen auth login
lucen worker run

The installer fetches the lucen CLI from this hub — the packages are not on PyPI, and one by that name there is not ours — with MuJoCo and ONNX Runtime, which the trainer, the robot check and the sim gate all run, and points the CLI at this hub. It uses uv when you have it, else Python 3.12+ with venv. It cannot change the PATH of the shell it was piped into; the second line does.

lucen auth login asks for an API key: make one in API keys, with the train scope. Only a signed-in browser can mint a key, so a leaked key can never mint another. The key is stored in ~/.config/lucen/credentials at mode 0600, never on a command line.

lucen worker run is the runner: it takes your queued training runs, trains them here, publishes each checkpoint as it lands, scores the run's gates as they come, and reports back. Leave it running; Ctrl-C stops it. A runner that dies mid-run does not strand it: the hub re-queues a run whose heartbeat is older than five minutes.

The two other jobs have workers of their own, from the same install and the same sign-in. A robot check that waits for you:

lucen robot worker

A sim-gate rollout queued from Run in sim (step 3):

lucen rollout worker

Each worker takes only the jobs of the account whose key it holds. Running them costs nothing: the hardware is yours.

3 · Gate it in sim

The run already gated its checkpoints while it trained. To gate the finished model again — another battery, a longer horizon, another seed — open the model's page, Rollouts, and the Run in sim form: the robot the policy was trained for is preselected and the battery is smoke. Queue rollout opens the sim-gate page, where the rollout waits for lucen rollout worker.

What the hub checks: the policy runs in MuJoCo on the robot's own model, under the policy's IO contract — a contract that does not fit the robot is refused, never run — one cell of the battery at a time, and the hub scores every cell from what the worker measured. A walking robot's cell passes when every seed stays upright for the whole horizon and tracks its command within [0.85, 1.15]; an arm's cell when it settles on its target within tolerance without one step outside its soft joint limits.

When it worked: 3/3 cells PASS (or how many did), a row per cell saying what it asked of the robot — "hold the default pose", "6 joints +0.30 rad from the default pose" — a video per cell where the worker can render one, and the next step: Deploy to robot when a cell passed, Fine-tune when none did.

4 · Connect a robot

On the robot's page, Connected → Connect a robot.

1. On the robot's computer. The page issues a short code, valid for ten minutes, and prints three lines to paste there: this hub's installer for the driver, the PATH line, and lucen-device pair with your code, followed by lucen-device serve. The robot makes its own key, and it never holds an API key. A robot that ships with the driver shows its own code instead: type it on the page.
2. Confirm it is your robot. The page shows what claimed the code — its adapter, the fail-safe the driver probed, the interface it pins, and its key fingerprint, which the robot's screen shows too — and asks how it may run policies: "Run policies a signed-in person approved for this robot" unless you choose otherwise. Name it and Confirm: a signed-in person's act, which no API key can do.
3. Connected. The device reads Online while lucen-device serve runs on it.

The driver's built-in virtual adapter runs no physics and moves nothing: it rehearses the whole path at the policy's control rate, which is what the default pairing gives you. A real robot needs an adapter of its own — Connect your robot is how to write one.

5 · Deploy it, watch it, stop it

On the model's page, Deploy to robot. Pick an online device and how long it may run (1, 2, 5 or 10 minutes; then it stops itself). Before you decide, the page shows what the hub checked: the device accepts this contract, the policy's class may run there, the fail-safe the device declared, the latest sim gate of this model on this robot, the embodiment fingerprint against the robot's current interface, and the digest the approval pins. Deploy stays off while a check fails. Tick the e-stop confirmation and hold the button — or press Enter twice from the keyboard.

When it worked: the live page counts down the window above the robot's signed trail — Approved, Verified (the approval's signature checked on the robot, offline), Pulled (the bytes checked against the pinned digest), Started, Heartbeats. Stop now ends it early: the robot reads the stop off its next heartbeat and signs a Stopped. Afterwards the same URL is the record. An approval runs once; running again is a new approval.

An agent or an API key can only ask. Its request waits in your Inbox, where you open it, read the same checks, and hold to approve or deny with a reason.

6 · Your Inbox, and what it cost

The Inbox puts what waits on your decision first, then what happened — one line per outcome: trained and published, checked and published, a handoff and how it ended — and what is in flight. Usage says what you used today; work on your own machine is free.

To take a robot off the hub, My robots → Disconnect: its credential is revoked at once, anything it is running is asked to stop, its trail stays, and its name is free to use again.

7 · Fine-tune it

On a model trained here, Fine-tune files the next round of its line: resume from a checkpoint that passed its gate, change one thing, and say what you expect the gates to do. The hub previews the round as you edit and refuses one that changes two things at once, resumes from a checkpoint that failed, or does not fit the line's budget — with its reasons. Only a signed-in person may override a rule, with a written reason; the round is then recorded as an override.

No robot file? Try a reference robot

The public robots under lucen/ are reference robots any account can train for. lucen/laika-arm is a six-joint arm on a fixed base: open it, Train a policy, and steps 2 to 5 run exactly as above. The policy is published into your account, and a robot you connect to lucen/laika-arm is yours, not Lucen's.

What runs where, and what costs money

Next

• How it works — the three claims, and exactly what a person approves.
• Add your robot — what is derived, what you must declare, what the hub refuses; the drop and the three commands behind it.
• Connect your robot — an adapter for your own robot, and the fail-safe the driver insists on.
• From a terminal — the CLI path: pull and push data, import a run, train and gate from the shell.
• MCP setup — what an agent can do with a scoped key, and what it can only ask.
• API reference — all of it, with the scope each operation needs.