π₀.₅ fine-tuned on the πR² latency-adaptive staircase noise schedule (arXiv 2607.26055) rather than the usual shared-timestep flow objective. Instead of drawing one noise level per sample and sharing it across all 50 chunk positions, each position gets its own, ramping from clean at the front to pure noise at the back. That is the schedule the πR² inference engine reproduces as a fixed point, so one denoising step per call finishes d actions which are emitted immediately, the buffer slides, and d fresh-noise slots are appended. The robot is fed continuously instead of waiting for a whole chunk.

20% of examples fall back to the ordinary shared-timestep objective (staircase_warmup_prob=0.2), so the weights retain the ability to denoise a chunk from pure noise — needed once to initialize the buffer at the start of an episode.

This checkpoint is usable with --inference.type=pir2, which refuses prefix-trained checkpoints.

Quantile stats. pi0.5 normalizes state and action with NormalizationMode.QUANTILES, but the dataset shipped with only count/max/mean/min/std, so training aborts on the first batch with QUANTILES normalization mode requires q01 and q99 stats. Fixed by copying the dataset to a writable location (dereferencing symlinks, so the shared HF cache blobs are never written through) and running:

--skip-images is safe and fast here because pi0.5 maps VISUAL to IDENTITY, so no video needs decoding. Note the script calls push_to_hub() unconditionally after writing meta/stats.json locally, so it can appear to fail after having already done the useful work. The resulting stats are baked into this checkpoint's preprocessor.

Shape-mismatch handling on load. max_action_dim=66 disagrees with pi05_base's 32, so action_in_proj / action_out_proj cannot be loaded. In PI05Policy.from_pretrained the resulting load_state_dict error is swallowed by a broad except, which returns a randomly initialized model that then trains and logs normally. A local patch drops only the shape-mismatched tensors so the backbone loads and just those two projections start fresh. Without it this run would have silently trained from scratch.

Flat from about epoch 8 onward at 0.072–0.073 with the cosine schedule fully annealed to 1e-5, so this is a converged run rather than a truncated one.

--fps=50 is not optional: the dataset is 50 fps, so consecutive actions are 20 ms apart and the policy has no notion of frame rate beyond that spacing. Running at 30 fps executes the motion 1.67× slower than demonstrated.

--inference.max_delay=1 matters. The engine derives the per-call delay as max(1, min(max_delay, round(mean_latency / (1/fps)))) from a rolling window of measured action-head latencies, and max_delay defaults to chunk_size // 2 = 25 — it is not clamped to the value used in training. Since this checkpoint only ever saw d ∈ {0, 1}, letting the engine pick d=2 or more extrapolates past the trained schedule. A 20 ms tick is tight (one expert substep against a cached prefix measures ~12 ms on an RTX 5090 laptop, before capture and transport overhead), so that is a realistic risk rather than a theoretical one. Pinning max_delay=1 keeps inference in distribution; if calls do overrun, the buffer simply runs a cycle behind rather than going off-schedule.

A future run with --policy.rtc_training_max_delay=3 would cover d up to 3 (60 ms per call at 50 fps) while keeping d=1 in distribution, and would be the more deployable choice.