The published DINO-WM architecture (DinoDynamics, same as dino_step_60000.pt) trained on MimicGen square_d0. Predicts DINOv2 patch features of the next frame, not pixels:

frame_emb has 3 slots — two history frames plus the query frame. Forward returns (B, 2, 196, 384): the transformer sees 2 frames × 2 views × 196 context tokens + 2 conditioning tokens + 2 × 196 queries = 1,178 tokens, and only the query tail is returned.

Trained with the MSE head, residual=False, matching the published checkpoint's configuration. (to_latent is not part of the world model — it is a feature→SD3-VAE-latent head for pixel metrics, built only when a VAE is passed and trained on detached features.)

20,000 steps, 0.21 s/step, 12.6 GB peak on one B200 (~70 min).

copy_feat_mse is the error of simply reusing the current frame's features, so the model explains about half of frame-to-frame feature motion. It starts worse than copying (val 1.667, ratio 1.13) and crosses below the baseline early.

It plateaus. The last ~8 validations span 0.729–0.803 with no trend — run-to-run oscillation is as large as any remaining improvement, so the second half of training bought a few percent rather than a step change. If a materially better model is wanted, the lever is capacity or data, not more steps.

Do not compare this ratio against our dense DINOv2 world models on threading_d0: different task, different predictor, 196 vs 256 patches, 196 vs 224 px input. Those numbers are not commensurable.

Three splits, all square_d0:

history=2, dino_size=196, state_dim=9 (eef_pos 3 + eef_quat 4 + gripper_qpos 2), horizon 8.

dino_step_{5000,10000,15000,20000}.pt and resume_last.pt. Use step 20000; earlier steps are kept because the metric plateaus, so a shorter run is nearly as good if compute matters.