How it works

Three claims

1. An agent trains the policy

   An agent with a key you scoped can start a training run, watch its log, stop it, and never spend past the budget you set. It trains on a computer where you started a runner, or on cloud GPUs where the hub has them. Every checkpoint goes through the sim tests and scores PASS or FAIL before it is anything but a file.

   POST /v1/runs · key:train · POST /v1/rolloutsThe quickstart, step 2

2. A person approves it onto the robot

   An agent can only ask. Putting a policy on a robot is a decision a signed-in person makes in the browser; no key of any scope can make it. The request names one policy file by its checksum, is checked against what the robot said it accepts, and lasts the minutes you choose. The robot itself verifies the signed approval before it moves.

   POST /v1/devices/{id}/approvals · session onlyWhat a person approves

3. Any robot, through one declaration

   A robot's card carries its interface: joint order, fixed or floating base, default pose, servo gains, what an action means, how often it runs. Training, the sim tests, the viewer and the connected robot all read that one declaration. Its fingerprint is what every policy is checked against.

   RobotCard.interface · interface_fingerprintAdd your robot

A handoff is a full page, never a modal: who asks to run what on which robot for how long, what the hub checked before asking, and a deliberate approve or a deny with a reason. Every slot below is a field of the request the API stores; after the decision the same URL is the audit record.

who asksrequested_by · requested_via · requester · plan

An agent through its key, a person through a session, or a planner on behalf of a plan — named, never anonymous.

what would runmodel_repo · onnx_path · contract_fingerprint · model

One ONNX file, pinned to the bytes it had when the request was filed, with the IO contract it declares.

on which robotdevice_id · device · endpoint

The registered device, its adapter and its declared fail-safe; the hosted endpoint it would consume, if any.

for how longminutes · reason

A window in minutes and the requester's reason. Approve once; there is no always.

what the hub checkedchecks[]

The device accepts this contract, the control class may run there, the fail-safe is declared, the latest sim-test scorecard or its absence, the embodiment fingerprint against the robot's current interface, the pinned digest still matches.

the decisionstatus · decided_by · decided_at · decision_reason · approval_id

Approved or denied, by whom, when, and why — the same URL is the audit record afterwards.

Checks the hub runs before asking:device.contractmodel.control_classdevice.fail_safesim_gate.scorecardembodiment.fingerprintartifact.digestendpoint.serving

Works with your agent

One REST contract, four thin surfaces over it: the web app, the lucen CLI, generated TS and Python SDKs, and the lucen-mcp MCP server. Scopes nest, so a key that ships data cannot spend GPU money, and no key at all can approve a robot.

{
  "mcpServers": {
    "lucen": {
      "command": "lucen-mcp",
      "env": {
        "LUCEN_API_KEY": "lucen_sk_...",
        "LUCEN_API_URL": "https://api.mousemouse.ai"
      }
    }
  }
}

The Training Coach

Point it at a training run — trained here or imported — and the Coach returns a diagnosis, in-whitelist proposals and an experiment plan — and every claim cites a card distilled from a real sim2real programme, with the sentence it came from. The hub rejects a report that cites a card which does not exist, or proposes changing the observation space; it never repairs one. It spends model budget under key:train.

A 12-DoF biped with RobStride actuators, 9.792 kg, whose robot card on this hub is the spec sheet as data: joint limits, the actuator table, the embodiment interface a policy is checked against, and the MJCF the sim gate, the Sim tab and the viewer all load. The hub works with any robot; Laika is Lucen’s own.