Call your model

You launched the fine-tune and watched the loss come down. When it finished, you had a checkpoint of a model that has seen nothing but your task. This chapter is where you call it.

Callable by name

You don't redeploy anything at the table. When training finishes, the checkpoint is admitted to the registry and comes up as a live endpoint on its own — the path every fine-tune is designed to take. The red-cube-bowl run went live through that path — admitted, callable by name. It also surfaced a bug in the admission probe itself; fixed since, so the path holds for every fine-tune that follows.

You also don't pick a base model or a serving config to get there. Back on the landing page, the newt library chose the SO-101 base for the arm; the same match carries through here. You name your fine-tune, and the library resolves the rest — which base it warm-started from, which arm it speaks to. The escape hatch to override that choice exists, and stays out of your way.

The same words you recorded with

There's one string you have to get right, and you already chose it: put the red cube in the bowl. That's the instruction every recorded episode carried, and it's the instruction you hand the model now. The words you trained with are the words the model answers to — recording and inference are two ends of the same sentence.

The call that proves it

Here is the payoff, and here is exactly how far it's proven.

Call the model first with the hardware mocked — open-loop, no motion. The endpoint answers, and what comes back is a real action chunk: your model's own (30, 6) output, thirty steps of six-axis motion, the right shape on the wire. That is the moment the course was built toward. On the red-cube-bowl run, the very first authenticated call returned exactly that — real chunks, from weights trained on nothing but those demonstrations. Your model, answering you by name.

Each of those six columns has a name, too. The response carries an axes list straight from your model's registry contract, so you're reading a labeled column instead of guessing from a bare float index.

Recording slot — poster pending

What's proven, and what's next

Be precise about the seam. What's proven is the software chain end to end: the run trained, the checkpoint went live, and it returns correctly shaped chunks for your task when you call it by name. What comes after this chapter is putting those chunks onto the physical arm — the closed-loop step the starter kit owns, and the one that still needs a rig in front of you. The chunks are real; driving the arm on them is the next chapter's work, not a result this one claims.

Not the only way in

Everything above happened through the SDK, but the SDK isn't the only door to the model — it's the fast one. Underneath robot.run(), the call is a single WebSocket connection carrying msgpack-encoded frames: your observation out, an action chunk back, the same shape whichever embodiment is asking. Nothing about that wire is SDK-exclusive — a client in any language that can open a WebSocket and encode msgpack can hold the same connection, log every frame it sends and receives, or replay a call from a saved log later.

Run it yourself

Calling the model by name, pointing it at your embodiment, and running the open-loop check all live in the docs.

→ Call the model — with set up your embodiment for the arm connection, and WebSocket vs HTTP if you're building your own client instead of the SDK.

You have a model that answers to its name from demonstrations you recorded. The next chapter puts its output onto the arm.