Action chunking

Overview

A policy that outputs one action per control step must finish its inference before the next step. A policy that outputs a chunk of H future actions gives the controller a plan that lasts H steps, so inference can run less often 2512.05964 §1. The cost is a seam: while the robot executes one chunk, the next chunk is still being computed, and it has to start from the moves the robot has already committed to.

The problem is the inference delay d, the number of control steps between starting a generation and having its result. The first d actions of the new chunk cannot be executed in time, so they are taken from the old chunk. The scheme is valid when d <= H - s, where s is the number of actions executed per chunk 2512.05964 §3.

The invariant the continuity variants share: the new chunk's first d actions equal the committed prefix, and the rest of the chunk is generated to continue it. Variants differ in where the prefix is enforced (inference or training) and what it costs.

The chunk length H is a separate choice. Longer chunks plan further ahead, and shorter ones react more finely. The horizon strongly affects performance, and on one base model longer horizons helped long-horizon LIBERO suites but hurt short ones 2511.19433 §1 fig. 1. The multi-horizon variant below trains for several lengths at once instead of fixing one.

A third use reads the chunk overlap as a diagnostic. If the new chunk disagrees with the unexecuted part of the old one, the policy may be failing. The failure-detection variant below uses this idea without changing how the robot is controlled 2606.21386 §3.2.

Variants

Synchronous execution (baseline)

The controller waits for each chunk to finish, then executes it. It is the reference that real-time methods are compared against. In the real-world tests of the training-time paper, both real-time variants were faster than this baseline at the same success rate 2512.05964 §5.2.

OFT is a fine-tuning recipe that runs this way. It executes the whole chunk, K = 8 steps on LIBERO and K = 25 on ALOHA, open-loop before it queries the model again 2502.19645 §5.1 2502.19645 §6.1. Its focus is speed: it predicts the chunk in one parallel pass instead of decoding it token by token, and the authors report 108.8 Hz for parallel chunking against 4.2 Hz for autoregressive OpenVLA on one A100 2502.19645 tab. 2. The paper does not address the seam between consecutive chunks.

Chunked generative heads without a continuity scheme

Octo and GR00T N1 use a chunk as the output unit of a generative action head. The cards record no continuity mechanism for either. Octo's diffusion head denoises the whole chunk, flattened into one vector, and the transformer runs once per prediction 2405.12213 §3.3 2405.12213 app. D. Its released pretraining config uses a 4-step chunk, which the paper does not state 2405.12213 app. D. GR00T N1's flow-matching head outputs H = 16 actions per chunk and integrates with K = 4 Euler steps. The authors report 63.9 ms per chunk on an L40 GPU in bf16 2503.14734 §2.1. Neither paper says how often a new chunk is requested or how consecutive chunks are joined, so that choice is left to the implementer 2503.14734 §2.1.

VideoVLA denoises a 6-step action chunk jointly with future video latents, and its first 3 steps are the ones executed 2512.06963 §3.4 2512.06963 §4.1. Its card notes that the released repository does not contain the execution loop. HACTS trains ACT policies on human-correction data, but it states no chunk size for them 2503.24070 §4.2.

Emma-X's paper emits one action per model call 2412.11974 app. F, but its training target is a chunk of actions up to the next segment start, and the released Bridge evaluation runs that whole chunk open-loop before it queries the model again run_bridgev2_eval.py create_dataset.py. Emma-X is therefore a chunked head in practice, with the replanning rule set by the code.

DPPO fine-tunes a diffusion policy with on-policy RL. Its policy outputs T_p future actions, of which T_a are executed 2409.00588 §3. The paper is about fine-tuning, and it does not describe how consecutive chunks are joined. The paper reports that T_a < T_p can be fine-tuned with a UNet but is unstable with an MLP 2409.00588 §4.3 2409.00588 app. B. The DPPO card lists the code's loss details.

Inference-time real-time chunking

The prefix is enforced while the chunk is being generated. The authors describe this as inpainting guided by the committed actions, implemented with pseudoinverse guidance. That needs a vector-Jacobian product, which is a backward pass, at every denoising step 2512.05964 §1 2512.05964 §4. The original method is arXiv:2506.07339 (no card yet; see arXiv).

Its drawbacks, as reported by the training-time paper: the per-step overhead raises latency, and inpainting handles large inference delays poorly 2512.05964 §1 2512.05964 §5.1. Its advantage: it can use overlapping actions beyond the committed prefix, with decreasing weights 2512.05964 §4 2512.05964 §6.

Training-time real-time chunking

Card: Training-Time Action Conditioning for Efficient Real-Time Chunking.

Instead of inpainting at run time, the policy is trained to continue a prefix. Three changes to a standard flow-matching policy 2512.05964 §4:

1. Per-action flow timestep. Each action token gets its own flow timestep. In a diffusion transformer with adaLN-zero conditioning, the scale, shift and gate can differ between tokens, without new learnable parameters 2512.05964 §4 2512.05964 fig. 2.
2. Clean prefix. During training, the ground-truth prefix is fed in noise-free, with its flow timestep set to 1 2512.05964 §4.
3. Postfix-only loss. The loss is computed only on the postfix actions 2512.05964 §4 2512.05964 alg. 1.

The delay is sampled at random during training because it is unknown in advance and may vary at run time 2512.05964 §4. The simulated experiments use delays 0 to 4 with exponentially decreasing weights 2512.05964 §5.1. The real-world experiments draw delays uniformly between 0 and 10 2512.05964 §5.2.

At run time the sampler takes the same inputs as inference-time RTC's action generation, the prefix and the delay, and returns the postfix. It is a drop-in replacement, and it adds no inference computation 2512.05964 §1 2512.05964 §4.

Temporal fusion of overlapping predictions

Cards: FPC-VLA fuses a window of past predictions, OTTER names the same idea for its inference, and FILIC uses ACT's chunking with temporal ensembling.

Each step's action is a weighted average of the predictions made for that step at earlier observations. Prediction k was made from the observation k steps ago 2509.04018 §3.3. The pose and the gripper are fused separately. The pose weight is a sigmoid of the cosine similarity to the latest pose, times an exponential decay in k. The gripper weight is the decay alone 2509.04018 eq. 7 2509.04018 eq. 12. The authors split them because the gripper can move while the arm stays still, and a pose similarity says nothing about it 2509.04018 §3.3. In their four-task ablation, with the rest of the system kept, using only the latest prediction averaged 38.0% task success, the full fusion 82.1%, and a plain average 73.9% 2509.04018 tab. 7.

OTTER's paper names temporal ensembling together with receding-horizon control, and it gives no weights 2503.03734 §3.2. The released script sets the weights, and the OTTER card records them and the execution length.

The fusion weights are fixed formulas with set constants, not learned values 2509.04018 eq. 7 2509.04018 eq. 10, and the fusion runs on the policy's output 2509.04018 §3.5. Its cost is extra policy calls: FPC-VLA's algorithm queries the policy for each of its N past observations at every step 2509.04018 alg. 1.

FILIC's policy is ACT-based and outputs 25-step chunks at 25 Hz. It uses temporal ensembling, but its weighting is not stated, so the paper gives no rule to copy 2509.17053 §4.1 2509.17053 tab. 1. Its experiments compare force inputs and do not isolate the ensembling step, so the paper gives no evidence on how much the fusion contributes 2509.17053 §5.4.

Chunk-overlap consistency for failure detection

Card: VLA-FAIL, a failure detector for finetuned VLA policies.

This variant does not change the policy or the controller. Under receding-horizon control, the unexecuted tail of the previous chunk overlaps the head of the new one. The score compares the two overlapping sequences, dimension by dimension, and divides each difference by how fast the new chunk moves in that dimension, so that slow and fast motions weigh alike. The score is averaged over the overlap and smoothed with an exponential moving average. It is one of two signals in the paper; the alarm fires when either one passes its threshold 2606.21386 §3.2 2606.21386 §3.3.

It needs no failure data, and it uses the policy outputs that control already produces 2606.21386 §3.2. The paper reports that it catches jerky-motion failures well, while the feature-distance signal detects earlier and less accurately 2606.21386 §5.

The variant requires a policy that re-plans before finishing its chunk. The paper says it does not apply to fully open-loop chunks 2606.21386 §6 2606.21386 app. B.

Multi-horizon training with gated fusion

Card: Mixture of Horizons in Action Chunking.

Instead of one chunk length, the action head is trained on several. Candidate horizons h_1 < ... < h_N = H each take the first h actions of the ground-truth chunk. They share one observation encoding and go through one batched action-transformer pass, with padding and masks for the shorter ones 2511.19433 §3.2. A linear gate outputs one logit per step and horizon. A softmax over the horizons still valid at each step fuses them, and a balance loss keeps the gate from collapsing onto one horizon 2511.19433 §3.2.

The authors present it as a plug-in for action heads that predict chunks. They apply it to flow-matching policies and to a one-step regression head 2511.19433 §3.1 2511.19433 §4.1. Author-reported gains on LIBERO are about one point per base model, for example pi0.5 from 97.7 to 99.0 2511.19433 tab. 1. A single fixed horizon of 30 on pi0.5 gave 97.7; the stride-3 candidate set gave 99.0 2511.19433 tab. 3. The authors report that the gate beat uniform averaging of the horizons 2511.19433 tab. 4.

It does not remove the compute cost of the chunk. Each candidate adds a suffix pass, and the authors' overhead claim depends on their hardware 2511.19433 §1 2511.19433 app. overhead.

Consensus-based execution length

Also from Mixture of Horizons in Action Chunking, and it needs the gate above. At each replanning call, the policy compares the fused action at each step with the horizon predictions still active there, weighted by the gate. It then executes steps while the disagreement stays under a threshold and enough horizons remain active 2511.19433 §3.3 2511.19433 alg. 1. The threshold is a ratio r times the mean disagreement over the first n steps 2511.19433 alg. 1.

The authors report higher throughput, about 2.5 times the default execution rate, with LIBERO-Long still above the fixed-length pi0.5 baseline 2511.19433 §1 2511.19433 §4.4 2511.19433 fig. 6. The sweep is only plotted in the paper. Plain temporal ensembling does not replace the gate: the authors report that adding it on top of MoH slightly hurt the Long suite 2511.19433 tab. 5 2511.19433 §4.5.

Sampled chunks with MBR selection after a retry

Card: CycleVLA, which adds a stop signal and a progress value to the action head, and a VLM check at subtask transitions.

This variant decides which chunk to run after a retry, not how to join two chunks. The policy draws N chunks from the same observation and subtask. Each chunk becomes a path of summed translation and rotation deltas, and the chunk run is the one with the smallest average distance to the others. The paper uses L2 distance and N = 8 2601.02295 §4.2 eq. 4 [arxiv:2601.02295 §5.1]. On LIBERO, the MBR choice after a backtrack scored 95.3%, against 92.5% for random choice among the same retries 2601.02295 tab. 6.

The action head gets two extra outputs for each action: a stop signal and a progress value. Progress near the end of a subtask triggers the VLM check. The backbones are pi0.5 and OpenVLA-OFT with a diffusion head [arxiv:2601.02295 §4.1] 2601.02295 §5.1.

The authors report large gains from the whole loop. For pi0.5, LIBERO-Plus average rises from 65.0 to 86.0 2601.02295 tab. 1, and LIBERO from 96.9 to 98.5 2601.02295 tab. 2. Each backtrack adds N policy forward passes, and the authors report that always-on MBR, without the VLM gate, takes about 2.2 times the inference time of the main method 2601.02295 §5.4 2601.02295 tab. 9.

When to use which

The fusion gains above come from a single author-reported ablation table, on four tasks across three robots 2509.04018 tab. 7.

The RTC performance claims above are the authors' own, from one simulator and two real tasks on one base model. The paper reports no exact success numbers in its text, only in figures 2512.05964 fig. 3 2512.05964 fig. 5. The multi-horizon and consensus numbers are also author-reported, mostly on LIBERO with 3B-class base models 2511.19433 §4.1. The failure-detection results are also author-reported, on their own simulated and real tasks 2606.21386 §5.

Implementation sketch

The common core of the training-time variant: a sampled prefix mask, a clean prefix with flow timestep 1, a loss on the postfix, and a sampler that overwrites the prefix at every step. Inference-time RTC replaces the overwrite with guidance. Shapes are (B, H, D) for a batch of chunks.

# Training step with a simulated delay  [arxiv:2512.05964 §4] [alg. 1]
def training_loss(model, obs, chunk, max_delay):
    # Draw delay per example and the prefix mask it implies  [§4]
    delay = sample_delay(batch_size, max_delay)            # (B,)
    prefix = arange(H)[None, :] < delay[:, None]           # (B, H)
    # One flow timestep per action; prefix is clean at timestep 1  [§4]
    t = where(prefix, 1.0, sample_uniform(batch_size)[:, None])
    noise = sample_normal_like(chunk)                      # (B, H, D)
    x_t = t[..., None] * chunk + (1 - t[..., None]) * noise
    # Velocity target and loss on the postfix only  [alg. 1] [§4]
    v = model(obs, x_t, t)
    err = (v - (chunk - noise)) ** 2
    post = logical_not(prefix)[..., None]
    return sum(err * post) / (sum(post) + 1e-8)

# Sampler: prefix is pinned to committed actions at every step  [alg. 1]
def sample(model, obs, prefix_actions, delay, num_steps):
    x = sample_normal_like(prefix_actions)                 # (B, H, D)
    mask = arange(H)[None, :] < delay[:, None]             # (B, H)
    t, dt = 0.0, 1.0 / num_steps
    for _ in range(num_steps):
        # Overwrite the committed prefix before each update  [alg. 1]
        x = where(mask[..., None], prefix_actions, x)
        tt = where(mask, 1.0, t)
        x = x + dt * model(obs, x, tt)                     # Euler step  [§3]
        t += dt
    return x  # use x[:, delay:]; see Pitfalls

The failure-detection variant reuses the overlap between chunks. The score below follows the paper's description 2606.21386 §3.2:

# Chunk-overlap score for one control step  [arxiv:2606.21386 §3.2]
def overlap_score(old_chunk, new_chunk, executed, v_min, alpha, prev_ema):
    # The unexecuted tail of the old chunk overlaps the head of the new one
    k = len(old_chunk) - executed                          # K = H - R
    old = old_chunk[executed:]                             # (K, D)
    new = new_chunk[:k]                                    # (K, D)
    # Per-dimension speed of the new chunk, floored at v_min  [§3.2]
    speed = max(max(new, axis=0) - min(new, axis=0), v_min)  # (D,)
    # Speed-normalized mismatch, averaged over steps and dimensions  [§3.2]
    raw = mean(abs(old - new) / speed)                     # scalar
    # Exponential moving average; the value of alpha is disputed  [§3.2] [app. F]
    return alpha * prev_ema + (1 - alpha) * raw

The consensus rule for execution length is a loop over the fused chunk. It needs the per-horizon predictions and gate weights from the multi-horizon model 2511.19433 §3.3 2511.19433 alg. 1:

# Steps to execute from one fused chunk  [arxiv:2511.19433 §3.3] [alg. 1]
def executable_steps(fused, preds, weights, horizons, n, m, r):
    # Gate-weighted disagreement between horizons and the fused action  [§3.3]
    disagree = weighted_l1(preds, fused, weights)          # (H,)
    # Threshold is a ratio of the disagreement in the first n steps  [alg. 1]
    threshold = r * mean(disagree[:n])
    k = n
    for step in range(n, H):
        # Stop when fewer than m horizons still cover this step  [alg. 1]
        if count_active(step, horizons) < m:
            break
        # Stop when the horizons disagree too much at this step  [alg. 1]
        if disagree[step] > threshold:
            break
        k = step + 1
    return k

Contradictions

None known between cited papers. Fourteen cards cover this concept, and their claims do not conflict: they address control, failure detection, chunk length, recovery, fusion and chunked heads. The chunked-head papers use different action heads, a diffusion head 2405.12213 §3.3, an L1 regression head 2502.19645 §4.2 and flow matching 2503.14734 §2.1, and no cited paper compares them on the same tasks, so this page does not rank them. Three of the four earlier cards use disagreement between chunks or horizons as a signal, for different purposes: the failure detector reads it as a sign of failure, the consensus rule reads it as a sign that the policy can safely run longer 2511.19433 §3.3, and MBR selection uses it to pick one chunk among samples 2601.02295 §4.2. The sources do not compare these uses.

Within a source paper, the regression target in eq. 2 of the training-time paper has the opposite sign to the one in its Algorithm 1 2512.05964 eq. 2 2512.05964 alg. 1. Implementations should follow Algorithm 1, which the sampler's direction requires. The sketch above follows Algorithm 1.

Pitfalls

• Prefix after the last step. The algorithm applies the final Euler update to the prefix positions too, so the returned first delay actions are not exactly the committed ones. Execute the committed actions for the prefix and take the postfix from the output 2512.05964 alg. 1.
• Delay range. The real-world text says delays are drawn between 0 and 10, while the listing samples up to, but excluding, the maximum. The maximum delay for the real robots is not stated 2512.05964 §5.2 2512.05964 alg. 1.
• Delays beyond training. The paper does not say what happens when the run-time delay exceeds the maximum seen in training. The authors give a 200 ms latency ceiling at 50 Hz for the real model 2512.05964 §5.2.
• Choosing the delay distribution. The authors say it should match the expected latency, but give no rule for doing so 2512.05964 §6.
• Per-action time signal. The method depends on a time input that differs per action token. Architectures without per-token modulation need a design the paper does not give 2512.05964 §4 2512.05964 fig. 2.
• Small real-world evidence. Two tasks, one base model, results only in a figure, with 68% Wilson intervals for success and ±1 SEM for duration 2512.05964 fig. 5.
• Latency figures. Author-reported: 108 ms per chunk with training-time RTC (about d = 5) against 135 ms with inference-time RTC (about d = 7) 2512.05964 §5.2.
• Overlap score: smoothing alpha. The method text calls alpha = 0.9 the strong setting, the ablation text and its figure caption use 0.1 across all experiments, and the hyperparameter tables list 0.9 2606.21386 §3.2 2606.21386 app. B 2606.21386 app. F. The paper does not resolve this. Treat alpha as tunable and check both values on calibration data.
• Overlap score: overlap size. With H = 30 and R = 10 the overlap should be 20, but the real-world table gives 10 for five X-VLA tasks, and the paper does not say why 2606.21386 app. F 2606.21386 app. G.
• Overlap score: velocity floor. The paper reports that real-world results drop sharply below v_min = 0.01, where the speed normalization amplifies sensor noise on a stationary robot 2606.21386 app. B.
• Overlap score: calibration. Thresholds need calibration rollouts, and one outlier can raise the threshold and reduce recall 2606.21386 app. D.
• Horizon set is not fixed. The multi-horizon paper's default is a stride-3 set up to 30 2511.19433 §4.1. Its released code uses other sets for its configs, so check the set your checkpoint was trained with 2511.19433 §4.1.
• Gains are small on a saturated benchmark. Most LIBERO gains are about one point, and some suites are already near 98 to 100%. Seed variance is reported only for RoboCasa 2511.19433 tab. 2. Treat single-seed LIBERO differences of about one point with caution.
• Compute is not free. Each candidate horizon adds a suffix pass. The paper's negligible-overhead claim depends on the hardware and the size of the action expert 2511.19433 §1 2511.19433 app. overhead.
• Dynamic-inference throughput is a plot. The 2.5 times throughput figure is author-reported and the sweep is only plotted 2511.19433 §4.4 2511.19433 fig. 6. Measure your own execution rate and success.
• Consensus needs the gate. The rule uses the gate weights and per-horizon predictions, so it does not apply to a plain ensemble 2511.19433 §4.5.
• Paper and code differ on details. The consensus rule's off-by-one stop condition, the summed disagreement over denoising steps and the gate noise in the PyTorch path are not in the paper's description. The multi-horizon card's Paper vs code section lists them; decide which one you implement.
• Real-robot evidence is small. Real-robot results come from 10 to 20 rollouts per task on one platform 2511.19433 §5.
• Max horizon 50 is worse than 30 on LIBERO. The appendix's variant with a maximum horizon of 50 scored below the one with 30 [arxiv:2511.19433 app. maximum horizon].
• Delays outside the training range. A run-time delay larger than the maximum sampled during training is not covered by the paper. The authors say the real-world model supports latencies up to 200 ms 2512.05964 §5.2.
• MBR rule in the released code. The paper gives the plain average-distance rule. The released code's default is a different density-based rule, and the plain rule is present but off by default. The CycleVLA card records the line references. Implement one rule on purpose, and say which.
• MBR and reversibility. Backtracking assumes the robot's states can be reversed, and the paper does not reset objects 2601.02295 §4.2 2601.02295 §7. An irreversible event, such as a knocked-over cup, can make the retry impossible.
• Retry cap. After three retries the subtask is forced to complete. The paper does not say how often this happens 2601.02295 app. D.
• Released pi0.5 path. The pi0.5 code depends on forks of two repositories that are not in the released repository, so that path cannot run from it alone. The CycleVLA card has the detail.
• Flow sign convention. The GR00T N1 text writes the interpolation as tau * A + (1 - tau) * noise, the target as noise - A, and the Euler update as A + V / K. These do not agree with each other. The released N1.7 code uses velocity A - noise with noise at flow time 0, which is self-consistent. The sketch above uses that convention. Verify the sign on a toy problem before training 2503.14734 §2.1 2503.14734 eq. 1.
• Sampling time against chunk duration. GR00T N1 reports 63.9 ms to sample a 16-action chunk, and its stated 120 Hz action rate gives about 133 ms per chunk. The paper does not say how often a chunk is sampled, and that timing sets the inference delay d 2503.14734 §1 2503.14734 §2.1.
• Open-loop length trades latency for reactivity. OFT executes its whole chunk before replanning. Longer chunks replan less often and react later to changes. Its tables use only K = 8 and K = 25 2502.19645 §5.1 2502.19645 tab. 2.
• Octo's chunk length is a config value. The paper does not state it. The released pretraining and finetuning configs use 4 steps, so the paper's results do not pin down a chunk length 2405.12213 app. D.
• Fusion window is not stated. FPC-VLA does not give its window N, nor how many of its 15 predicted steps are executed, so the chunk element used for each past prediction is implicit 2509.04018 §4.1 2509.04018 §3.3.
• Similarity term is nearly flat. With the paper's alpha of 0.1, the sigmoid in eq. 8 stays between about 0.475 and 0.525 for cosine values from -1 to 1. The similarity can change the weights by about 10% at most, so check the reported gains against that setting 2509.04018 eq. 8 2509.04018 §4.1.
• Fusion calls the policy repeatedly. The algorithm calls the policy on each of the N past observations at every step, and the paper does not say whether those calls are cached 2509.04018 alg. 1.
• Ensembling weights are not in FILIC. Its policy uses temporal ensembling, but the weighting is not stated 2509.17053 §4.1 [arxiv:2509.17053 tab. 1]. Choose a weighting and state it in your own code.
• OTTER's horizon is inconsistent. Its architecture table gives an action horizon of 12 for real robots and 1 for simulation. The text says 8 steps was best, and the released default is 12 2503.03734 tab. model-arch 2503.03734 §3.2.
• VideoVLA's execution loop is missing from its repository. The model predicts 6 actions and the paper executes 3, but the released inference script saves only the video, so the gripper binarisation and the loop must be written by the implementer 2512.06963 §4.1. The VideoVLA card has the line references.
• HACTS states no chunk size. Its ACT results therefore cannot be compared with other chunked policies on chunk length 2503.24070 §4.2.
• Emma-X re-queries more often than its eval. The paper's loop calls the model at every step, while the Bridge eval executes a whole chunk before it queries again. The Emma-X card has the line references. Choose one replanning rule and state it in your own code 2412.11974 app. F run_bridgev2_eval.py.
• DPPO's executed-step loss. The released code computes the policy-gradient term only over the first executed steps, and the paper does not describe this restriction. The DPPO card gives the line references diffusion_ppo.py.

Papers

• Training-Time Action Conditioning for Efficient Real-Time Chunking: trains the policy on simulated inference delay with a clean action prefix, so no inference-time guidance is needed; matches inference-time RTC on two real tasks and beats it in simulation at delays of 2 and above.
• Mixture of Horizons in Action Chunking: trains one action head on several chunk lengths at once, fuses them with a learned per-step gate, and uses how much the horizons agree to decide how far to execute.
• CycleVLA: adds stop and progress outputs to a VLA, has a VLM decide whether to move on or backtrack at subtask transitions, and picks the retry chunk by MBR among sampled chunks; author-reported gains on LIBERO-Plus and LIBERO.
• Octo: An Open-Source Generalist Robot Policy: a pretrained transformer policy whose diffusion head denoises whole action chunks; no continuity scheme.
• Fine-Tuning Vision-Language-Action Models: Optimizing Speed and Success: OFT, which predicts an action chunk in one parallel pass with an L1 head and executes it open-loop; the speed gain is the contribution.
• GR00T N1: a humanoid VLA whose flow-matching head outputs 16-action chunks with 4 Euler steps; the linked code is a later release.
• VLA-FAIL: flags failures in finetuned VLA policies with a feature-distance score and a chunk-overlap score, without failure data; the overlap score is the failure-detection variant above.
• FPC-VLA: fuses past action predictions with pose-similarity and time-decay weights, and queries a VLM supervisor at gripper changes; the fusion is the temporal-fusion variant above.
• OTTER: a VLA on a frozen CLIP that predicts chunks of delta end-effector actions; its chunk length and the temporal ensemble are set in the released code, which is a re-implementation.
• VideoVLA: denoises a 6-step action chunk jointly with future video latents, starting from a pretrained video diffusion transformer; the first 3 steps are executed.
• HACTS: a leader-follower teleoperation arm that records human corrections for ACT and RLPD policies; the chunk size of its ACT policies is not stated.
• Emma-X: a VLA with grounded chain-of-thought and look-ahead gripper targets; its training target is a chunk per segment, and the Bridge eval executes it open-loop.
• Diffusion Policy Policy Optimization: on-policy PPO fine-tuning of a diffusion policy that executes T_a of T_p predicted actions; chunk size affects which policy heads train.
• FILIC: an ACT-based policy with 25-step chunks and temporal ensembling, fed an estimated end-effector force and run through a joint-space impedance loop; the paper does not state the ensembling weights.