Upload
Send it to New Theory
Your takes are recorded and culled. Now the dataset leaves the laptop — and the platform half of the loop begins.
This is the seam. One command converts your recordings to a LeRobot dataset, uploads it, and launches the fine-tune, and this chapter is that handoff. Everything from this chapter on runs against the platform, driven by the newt CLI you installed in Quick Start.
1 · Uploading and launching in one command
That one command is pixi run finetune -- --dataset <name> — the dataset name you chose at record time, nothing else. The upload is a stage inside it: it exports every usable episode to datasets/local/<name>/, hands that folder to newt finetune, and newt finetune uploads it and launches the run.
pixi run finetune -- --dataset <name>
Before it sends a byte, newt finetune checks that the export is a real LeRobot dataset: it looks for meta/info.json and confirms the action and observation.state shapes are readable. A malformed export fails on your laptop, in seconds, with a message naming what to fix. That check is deliberately cheap and up front, so you never spend twenty minutes uploading a dataset only to have it rejected at the far end.
The command prints two identifiers, and they aren't the same thing. The staged name is what your dataset uploads as — the name you gave it at record time, printed once. The job handle identifies the run itself, and it's what you pass to newt finetune --handle <job> --status to check the run later without re-watching it. Keep the handle for status. It's also not the model tag — that's a separate value the server mints only when the run succeeds, and the next chapter is where it shows up. Read the staged name and the handle off at launch and keep both.
uploading … MB … staged as <name>, followed by the launch confirmation and a job handle.
Where your data lands
The upload goes to your team's own namespace in the cloud, attributed to your API key. It's your data: the sessions you record come back to you, and the fine-tune you launch reads from your namespace, not a shared pool. You aren't publishing your demonstrations to anyone by uploading them, and you don't manage a bucket or a storage account to get them there — the command handles the destination.
The one honest wait
A dataset of fifty episodes with two camera streams is roughly 2 GB. On a fast connection it moves in a couple of minutes. At the event it won't be a fast connection: one venue's WiFi, shared across every team recording at once, and the same 2 GB takes anywhere from 10 to 60 minutes.
That's the one wait you'll personally sit through, and it's slow because of the room, not because of anything you did. The upload reports its progress in megabytes as it goes, so a stalled connection is visible rather than a spinner that tells you nothing. Start it once your dataset is exported and let it run while you review your takes or set up the next thing. Naming this wait up front is so it doesn't surprise you: it's expected, it's bounded, and it's the last slow step before your data becomes a model.
[ upload-progress visual — the dataset streaming to the cloud ] Placeholder. Progress fills in by the megabyte as the dataset uploads.
the dataset is staged in the cloud under your team's name. The next chapter turns it into a model.