Proposal: teach lerobot/smolvla_libero the four Week 1 phrasings that failed, with N demos per item, and measure success against N. The curve is a price list for a "fit the robot to how your users talk" service.

It has seen every Object demo, but only with one sentence per task. What is new is the wording. Split: train on the first N demos per item relabeled with the original sentence and A to D; choose checkpoints on initial states 10 to 14; test on states 0 to 9; and add four unseen phrasings E to H that are only ever used in the test.

Wrote E to H under fixed rules (none of the verbs pick, place, grab, put, pack; a sentence structure different from A to D; the basket stays the target) and froze them in data/wordings.json before any training.

Every N gets the same 3000 steps (lr 2.5e-5, warmup 200, batch 32), and checkpoints are scored on the validation states while training runs, so overfitting would show up as a falling validation curve. The best checkpoint per N goes to the test.

run_all.sh starts one tmux session: the N = 0 test, the training chain, one watcher per run, and a final waiter. A dry run with stub scripts caught two bugs before any GPU time: parallel jobs appending to one results file corrupted it (now one file per job, merged at the end), and results depended on job grouping (now the RNG is reseeded per episode).

A new account needs a $250 prepay or a support ticket that takes one to two business days. RunPod rents an A100 SXM 80 GB by the hour with prepaid credit, so I rewrote setup.md for a RunPod pod. On the pod, the smoke test (butter, original sentence) succeeded, and a 200-step training probe used 28 GB of GPU memory at 0.46 s per step.

nproc reports the host's 256 CPUs, but the pod has 16 vCPU, so every evaluation process spawned hundreds of threads and starved training. Fix: OMP_NUM_THREADS=1 (and MKL, OpenBLAS) in the environment, then restart. To fit the time budget, validate at steps 1000, 2000, and 3000 only.

Yes, the jobs live in tmux on the pod. Before leaving, check that training passed step 1000, the first checkpoint exists, no process is far above 100% CPU, and there is disk and credit left.

All six runs finished in about six hours and $11. Taught phrasings: 31% at N = 0, 80% at N = 1, 92% at N = 20 and 40. Unseen: 29% at N = 0, then 74-79% for every N. Six untrained items: 87% to 60-72%.

No. Per item it is mixed: cream cheese rises, orange juice falls from 36/40 to 23/40, and they cancel out. A likely reason: every demo carries the same five sentences, so more demos add ways to move, not ways to be asked. With one seed per N, it is a hypothesis.

The original sentence was only there for the four trained items; the other six never appeared, so the whole model drifted toward the four. The checkpoint choice never looked at them, and even the step-1000 checkpoints forgot as much, so it happens early. Mixing in a few demos of every item is the fix to try next.

One demo per item does most of the work: that is the price, and the Side Hustle story. Then the twist (more demos do not help new phrasings) and the cost (forgetting).

Scenes chosen by a rule: N = 0 fails and every fine-tuned model succeeds. Also a 1x4 orange juice grid (N = 1, 10, 20, 40) and a butter-versus-ketchup grid for forgetting.

Filled now means "in the fine-tuning data" (the original sentence and A to D); hollow means not (E to H, and the six other items). Both charts use the same rule and legend.

Wrote a short model card with the charts and the results table, uploaded it, and made the Hugging Face repo public with all six checkpoints.

Pulled the Week 2 rules and judging criteria with get_challenge_details, checked another submission for the template, searched DEV for related posts (one on whether fine-tuning turns a VLA into an imitation learner), and staged the post as an unpublished draft. Rewrote it around tables, charts, and videos. This session is saved with submit_agent_session and embedded in the post.