encrypted checkpoints

Code, and how to run any folder here

Branch (train + publish + fetch + serve + in-process inference, one place): https://github.com/ismty0805/Isaac-GR00T-AlinVLA/tree/hyeonmo/allex-frontier

Everything below is driven from run_scripts/deploy/allex_wan22/ on that branch — registry.yaml records every folder in this repo (lineage, training yaml, run name, rungs on HF, the normalization/geometry contract the checkpoint carries), and the scripts read it:

cd run_scripts/deploy/allex_wan22 && source env.sh          # REPO / CKPT_ROOT / HF_KEY_FILE ...
./fetch.sh   <folder|alias> <step>                           # download one rung from here + decrypt
./serve.sh   <folder|alias> <step>                           # robot: ZMQ policy server for RRC (gate -> run_gr00t_server, EMA weights)
./infer.sh   <folder|alias> <step> --dataset-path <lerobot>  # no robot: open-loop on dataset episodes -> MSE/MAE (+ --save-npz)
./registry.py list                                           # folders, codebase, rungs

Aliases: ours, i2vmimonly, i2vmim, baseline, bmethod, joint, fastwam. contract_gate.py refuses to serve a rung whose config.json / processor_config.json / experiment_name disagree with the registry. FastWAM is served by the same serve.sh (it dispatches to serve_fastwam.sh, same ZMQ wire, FastWAM venv).

The arms (rows32 cohort = 32 model rows x 100k steps, allex v1..v6, shared stats)

folder	what it is	training yaml (`run_scripts/train/wam_dit4dit/k8s/`)
`allex_mimonly_eefrel_h24_rows32_100k_4gpu/`	ours — V2V history (hist5s3: 5 past frames, 13/37) + iBOT MIM-only representation loss (L18<->L18, γ 0.01, two-view), local cosine OFF	`allex_mimonly/hyeonmo_allex_mimonly_eefrel_h24_100k_4gpu_bs32.yaml`
`allex_i2vmimonly_eefrel_h24_rows32_100k_4gpu/`	ours minus history — I2V (1 condition frame, 1/25) + the same iBOT MIM-only loss, `WAM_V2V_ALIGN_LOSS=none`	`allex_i2vmim/hyeonmo_allex_i2vmimonly_eefrel_h24_100k_4gpu_bs32.yaml`
`allex_baseline_i2v_h24_rows32_100k_4gpu/`	baseline — I2V, no representation loss at all (γ 0)	`allex_baseline/hyeonmo_allex_baseline_i2v_h24_100k_4gpu_bs32.yaml`
`allex_i2vmim_localcos_eefrel_h24_rows32_100k_4gpu/`	⚠ the first "ours minus history" launch: I2V + MIM plus the old L3->L18 local cosine (γ 0.01) because the knob was never exported. Two deltas from ours, not one. Kept for the record	`allex_i2vmim/hyeonmo_allex_i2vmim_eefrel_h24_100k_4gpu_bs32.yaml` (SUPERSEDED, refuses to launch)
`allex_fastwam_rows32_100k_4gpu/`	FastWAM (Wan2.2-5B + ActionDiT, fastwam trainer) on the same data, stats and plate — the cohort's external comparator	fastwam repo `configs/task/allex_fastwam_rows32_100k.yaml` (`model.pt` per rung)

Pre-cohort folders (earlier generations, 64 rows, trained before the 2026-09-19 normalization fixes — see the table and the "two bugs" section further down):

folder	what it is	training yaml
`bmethod_armrel_h48_stride6_v1v6/`	B-method: iBOT + arms RELATIVE, h48 stride 6	`run_scripts/deploy/allex_wan22/legacy_launch/hyeonmo_frontier_allex_v1v6_bmethod_armrel_s6h48_4gpu.yaml` (lineage `hyeonmo/wan-22-frontier`)
`joint_h48_stride6_v1v6/`, `joint_h24_stride3_v1v6/`	V2V joint baseline, absolute actions, allex v1..v6	`legacy_launch/hyeonmo-frontier-allex-v1-{s6h48-,}g4.yaml` (+ in-pod v1->v1..v6 switch, see `legacy_launch/README.md`)
`joint_h48_stride6/`, `joint_h24_stride3/`	same yamls, allex v1 only (80 ep), rungs saved before the switch	same

Comparators that live in other repos: GR00T N1.7 → hmkang/frontier_demo_gr00t_n17_allex_v1v6_enc (branch hyeonmo/frontier-gr00t); AGRA / DreamZero → branches hyeonmo/dreamzero-frontier, agra-frontier (not published here).

Files in this repository are AES-256-CBC encrypted (openssl enc -aes-256-cbc -pbkdf2 -iter 200000 -salt), one .enc per original file, no compression. They are not usable without the key.

Normalization: two eras in this repo. Read the table, not the folder name.

Folders here were produced before and after two normalization bugs were fixed on 2026-09-19. Every checkpoint records which era it belongs to, so you never have to guess:

# after decrypting
python -c "import json;c=json.load(open('checkpoint-XXXXX/processor_config.json'));\
print(c.get('use_percentiles'), c.get('use_relative_action'))"

folder	data	clip	action rep	era
`joint_h24_stride3/`	allex v1 (80 ep)	fdf3 nin13/nout37, h24	absolute	pre-fix
`joint_h48_stride6/`	allex v1 (80 ep)	fdf6 nin25/nout73, h48	absolute	pre-fix
`joint_h24_stride3_v1v6/`	allex v1..v6 (480 ep)	fdf3 nin13/nout37, h24	absolute	pre-fix
`joint_h48_stride6_v1v6/`	allex v1..v6 (480 ep)	fdf6 nin25/nout73, h48	absolute	pre-fix
`bmethod_armrel_h48_stride6_v1v6/`	allex v1..v6 (480 ep)	fdf6 nin25/nout73, h48	arms RELATIVE	pre-fix — ⚠ see below
`allex_mimonly_eefrel_h24_rows32_100k_4gpu/`	allex v1..v6	fdf3 nin13/nout37, h24	arms RELATIVE (EEF, XYZ_ROT6D)	post-fix: `use_percentiles=True`, `use_relative_action=True`
`allex_baseline_i2v_h24_rows32_100k_4gpu/`	allex v1..v6	fdf3 nin13/nout37, h24	arms RELATIVE (EEF, XYZ_ROT6D)	post-fix: `use_percentiles=True`, `use_relative_action=True`
⚠ `allex_i2vmim_localcos_eefrel_h24_rows32_100k_4gpu/`	allex v1..v6	fdf3 nin13/nout37, h24	arms RELATIVE (EEF, XYZ_ROT6D)	post-fix — I2V + MIM + L3→L18 local cosine (γ 0.01), see note
`allex_i2vmimonly_eefrel_h24_rows32_100k_4gpu/`	allex v1..v6	fdf3 nin13/nout37, h24	arms RELATIVE (EEF, XYZ_ROT6D)	post-fix — I2V + MIM only = ours minus history (`WAM_V2V_ALIGN_LOSS=none`)

The two rows32 rows are read from the checkpoints themselves (processor_config.json, 2026-09-22). The pre-fix rows are dated by when they were uploaded and by the action rep recorded in the previous revision of this README; their source directories are no longer on the training filesystem, so the flag values were not re-verified here. For anything in a pre-fix row, read processor_config.json out of the checkpoint (command above) rather than trusting this table.

The rows32 folders are the current frontier-demo cohort: 32 model rows, 100k steps, warmup 5000, q0.1/q99.9 arm normalization. They are not affected by anything below.

The two I2V + MIM folders — read this before comparing them to `allex_mimonly`

allex_mimonly (ours) = V2V history (hist5s3) + iBOT MIM-only, WAM_V2V_ALIGN_LOSS=none. The ablation "ours minus history" was launched twice:

allex_i2vmim_… (uploaded 2026-09-2x) never exported WAM_V2V_ALIGN_LOSS, so the extractor defaulted to cos: besides MIM it also trained the old L3→L18 per-token cosine at γ 0.01. Evidence: launch log [WAN_FADISTILL] ENGAGED … gamma=0.01 … L_align=1.00; wandb train/selfflow_rep_loss fell 1.0 → 0.096 over training (it is exactly 0 for allex_mimonly); the checkpoints ship backbone.extractor._sf_projector.*, which =none never builds. It is therefore two knobs away from ours (no history and an extra alignment term). Kept as published for the record; do not read it as the clean ablation.
allex_i2vmimonly_… (uploaded 2026-10-02) is the relaunch with export WAM_V2V_ALIGN_LOSS=none and nothing else changed. Launch log on all four ranks: [WAM_V2V_ALIGN_LOSS] none — _sf_projector NOT built and … align=NONE(local cos off, global branch only). This is the clean "ours minus history". Rungs: 20k / 40k / 50k / 60k / 80k / 100k.

Both decode with the same code and the same processor_config.json contract as allex_mimonly.

⚠ The two bugs, and what they mean for the older folders

Both were fixed on 2026-09-19. This section is history for the pre-fix folders, not a live warning. An earlier revision of this README said "Status 2026-09-12: not yet fixed" — that line is obsolete and was removed, because left in place it reads as a warning about the newer folders too.

Bug 1 — the RELATIVE override discarded the percentile choice. state_action_processor.py picks q01/q99 instead of min/max in one place (:124). For RELATIVE arm keys it then replaced the entire norm-params entry with the raw relative_action stats (:168), and that copy carries raw min/max — so the percentile choice was undone for exactly the arm keys. A run could pass --use-percentiles and still min-max-normalize its arms, while hands / neck / waist used q01-q99: two scale conventions inside one model. Measured on allex_v1v6_armrel, (max-min)/(q99-q01) was median 2.4x right / 2.2x left, worst cell 4.6x — the arms occupied ~40-45 % of the [-1, 1] range the hands and neck used in full. Fixed by re-applying the percentiles after the override, and raising rather than continuing if the relative stats carry no q01/q99.

Bug 2 — RELATIVE conversion was never switched on at all. The flag reached a field nothing read, so the processor kept its False default. With it off, the arm target silently stayed the absolute wrist pose, inference was absolute too (consistently wrong rather than visibly broken), and the relative stats were never consulted — which also made Bug 1's fix unreachable dead code. Fixed the same day.

Which folders are affected: only those trained before 2026-09-19 that declare RELATIVE arms — bmethod_armrel_h48_stride6_v1v6/. The joint_* folders are ABSOLUTE-action runs and were never affected by either bug. Check processor_config.json as shown above rather than trusting the name.

Inference: current code runs the older checkpoints correctly

You do NOT need to check out an older commit. Both flags are written into processor_config.json by save_pretrained and restored by from_pretrained (use_percentiles, use_relative_action, both defaulting to False). A checkpoint therefore carries its own normalization contract, and the 2026-09-19 fixes are guarded by those same flags — the new branches simply do not execute for a False checkpoint. Verified on disk: pre-fix checkpoints saved 2026-09-18 read False/False, post-fix ones saved 2026-09-22 read True/True.

One caveat: this holds for the from_pretrained path. An eval harness that rebuilds the processor from a training config or from WAM_USE_RELATIVE_ACTION in the environment instead of loading the saved processor_config.json can override the checkpoint's own setting — check what your harness does before trusting a number.

A naming trap: `q01`/`q99` do not always mean 1 % / 99 %

gr00t/data/stats.py writes percentile values into fields named q01/q99. When the stats were built with --use_eef_relative_percentile_999, those fields hold 0.1 % / 99.9 %, and the file records this in _percentiles. For the AllEx v1..v6 dataset the arms' relative_stats.json carries _percentiles = [0.001, 0.999], while stats.json for the ABSOLUTE keys has no marker and holds the 1/99 default. So "percentiles on" means 0.1/99.9 for the arms and 1/99 for hands + neck, in both the WAM and the GR00T arms of this cohort. Read _percentiles, not the field name.

Decrypt a folder

for f in checkpoint-XXXXX/*.enc checkpoint-XXXXX/experiment_cfg/*.enc; do
  openssl enc -d -aes-256-cbc -pbkdf2 -iter 200000 -pass file:/path/to/key.txt -in "$f" -out "${f%.enc}"
done

Downloads last month: -; Downloads are not tracked for this model. How to track

Inference Providers NEW

This model isn't deployed by any Inference Provider. 🙋 Ask for provider support