The robot data loop is cheap once and expensive on the ninetieth run

A post on Hugging Face's blog, published under the Amazon namespace, walks through running a full robot data loop inside a single Strands agent: record a demonstration, sync it to a Hugging Face Storage Bucket, train by streaming the dataset back, and deploy the checkpoint to hardware ^[1]. The framing is the part worth keeping: run that loop once and every piece works, run it every day and you start paying for the same byte transfers over and over ^[2].

The post names where the bytes move. The recordings you upload keep growing, each training run copies the whole dataset to the GPUs before it starts, and every new checkpoint ships out while the next batch of recordings comes back ^[3]. That is three recurring transfer legs per cycle, and only one of them is new data ^[4].

The proposed working layer is Storage Buckets, described as a mutable, non-versioned, Xet-backed object-storage repository type announced in March 2026 ^[5]. A bucket sits beside your dataset repositories in the same hf:// namespace and uses the hf CLI you already have ^[6]. Three mechanisms follow from that. Each sync uploads only the bytes that changed ^[7]. Training streams the dataset straight from the Hub instead of downloading it, frame by frame, decoding camera video on the fly, with no local copy ^[8]. Deployment to hardware is one keyword argument change, mode="real", on the same Robot() object that did the recording ^[9][10]. The on-disk format stays exactly as LeRobot wrote it ^[11], and since the LeRobot dataset format is already used by more than 90,000 datasets and models on the Hub from more than 8,000 publishers, according to LeRobot Project Pulse, a recording made this way is readable without conversion ^[12][13].

Strands Robots itself is an open source SDK from AWS under Apache 2.0 that exposes robot abstractions, simulation, and the LeRobot stack as AgentTools ^[14]. The Robot() factory resolves a name against a registry of arms, humanoids, mobile bases, and hands; the post uses an SO-100, and the earlier post in the series deployed to a physical SO-101 ^[15][16]. The argument for putting an agent in the middle is decision volume rather than autonomy: which episodes to keep, when the scene has drifted enough to re-record, whether today's batch is enough to train on, which checkpoint replaces the one on the arm, each coming up dozens of times over a collection campaign ^[17]. Once the agent triggers an episode, the rollout proceeds at the robot's control frequency until it ends, with the trained policy producing every action ^[18].

What the supplied text does not contain is any number attached to the cost claim: no transfer volumes, no deduplication ratios, no streaming throughput measured against a control loop, no pricing ^[19]. It also does not say where the training compute sits relative to the bucket, so "one place" here means one namespace and one CLI, not a stated compute-and-storage adjacency ^[20]. The removal of the full download is a real change in shape; the size of the saving is asserted, not shown.

Watch three things. Whether streaming at the robot's control frequency holds for multi-camera episodes, since that is the claim doing the most work. Whether the non-versioned, mutable nature of buckets ^[5] complicates saying later which episodes produced which checkpoint. And whether the runnable notebook at examples/notebooks/05_streaming_data_loop.ipynb ^[21] reports any transfer figures the post itself withholds.