---
kind: concept
slug: action-chunking
title: Action chunking
summary: >-
  Robot policies predict and execute a block of future actions. Real-time chunking keeps consecutive blocks continuous under inference delay, and training-time variants move its cost into training. Overlapping predictions can be fused. Multi-horizon training with a learned gate picks the chunk length. Chunk overlap also flags failures, and consensus among sampled chunks picks the retry chunk.
tags: [robot-learning, real-time-control, latency, failure-detection, failure-recovery, vla]
papers: ["2405.12213", "2409.00588", "2412.11974", "2502.19645", "2503.03734", "2503.14734", "2503.24070", "2509.04018", "2509.17053", "2511.19433", "2512.05964", "2512.06963", "2601.02295", "2606.21386"]
related: [diffusion-inpainting, diffusion-models, flow-matching, vision-language-action-model, imitation-learning, impedance-control, digital-twin, model-predictive-control, anomaly-detection, task-decomposition, decoding-strategies, teleoperation, video-generation]
status: draft
updated_at: 2026-11-01
---

## 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
[arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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 [arxiv:2502.19645 §5.1] [arxiv: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 [arxiv: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 [arxiv:2405.12213 §3.3] [arxiv:2405.12213 app. D]. Its
released pretraining config uses a 4-step chunk, which the paper does not state
[arxiv: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 [arxiv: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 [arxiv: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 [arxiv:2512.06963 §3.4]
[arxiv:2512.06963 §4.1]. Its [card](/papers/2512.06963) 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
[arxiv:2503.24070 §4.2].

Emma-X's paper emits one action per model call [arxiv: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 [code: experiments/robot/bridge/run_bridgev2_eval.py#L183]
[code: GCOT/create_dataset.py#L307-L309]. [Emma-X](/papers/2412.11974) 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 [arxiv: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 [arxiv:2409.00588 §4.3] [arxiv:2409.00588 app. B]. The
[DPPO card](/papers/2409.00588) 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 [arxiv:2512.05964 §1] [arxiv:2512.05964 §4].
The original method is arXiv:2506.07339 (no card yet; see
[arXiv](https://arxiv.org/abs/2506.07339)).

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

### Training-time real-time chunking

Card: [Training-Time Action Conditioning for Efficient Real-Time Chunking](/papers/2512.05964).

Instead of inpainting at run time, the policy is trained to continue a
prefix. Three changes to a standard flow-matching policy [arxiv: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
   [arxiv:2512.05964 §4] [arxiv: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 [arxiv:2512.05964 §4].
3. **Postfix-only loss.** The loss is computed only on the postfix actions
   [arxiv:2512.05964 §4] [arxiv:2512.05964 alg. 1].

The delay is sampled at random during training because it is unknown in
advance and may vary at run time [arxiv:2512.05964 §4]. The simulated
experiments use delays 0 to 4 with exponentially decreasing weights
[arxiv:2512.05964 §5.1]. The real-world experiments draw delays uniformly
between 0 and 10 [arxiv: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 [arxiv:2512.05964 §1]
[arxiv:2512.05964 §4].

### Temporal fusion of overlapping predictions

Cards: [FPC-VLA](/papers/2509.04018) fuses a window of past predictions,
[OTTER](/papers/2503.03734) names the same idea for its inference, and
[FILIC](/papers/2509.17053) 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 [arxiv: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
[arxiv:2509.04018 eq. 7] [arxiv: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 [arxiv: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%
[arxiv:2509.04018 tab. 7].

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

The fusion weights are fixed formulas with set constants, not learned values
[arxiv:2509.04018 eq. 7] [arxiv:2509.04018 eq. 10], and the fusion runs on the
policy's output [arxiv: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
[arxiv: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 [arxiv:2509.17053 §4.1] [arxiv: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
[arxiv:2509.17053 §5.4].

### Chunk-overlap consistency for failure detection

Card: [VLA-FAIL](/papers/2606.21386), 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
[arxiv:2606.21386 §3.2] [arxiv:2606.21386 §3.3].

It needs no failure data, and it uses the policy outputs that control already
produces [arxiv:2606.21386 §3.2]. The paper reports that it catches jerky-motion
failures well, while the feature-distance signal detects earlier and less
accurately [arxiv: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 [arxiv:2606.21386 §6]
[arxiv:2606.21386 app. B].

### Multi-horizon training with gated fusion

Card: [Mixture of Horizons in Action Chunking](/papers/2511.19433).

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
[arxiv: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 [arxiv: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
[arxiv:2511.19433 §3.1] [arxiv: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
[arxiv:2511.19433 tab. 1]. A single fixed horizon of 30 on pi0.5 gave 97.7; the
stride-3 candidate set gave 99.0 [arxiv:2511.19433 tab. 3]. The authors report
that the gate beat uniform averaging of the horizons [arxiv: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
[arxiv:2511.19433 §1] [arxiv:2511.19433 app. overhead].

### Consensus-based execution length

Also from [Mixture of Horizons in Action Chunking](/papers/2511.19433), 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 [arxiv:2511.19433 §3.3]
[arxiv:2511.19433 alg. 1]. The threshold is a ratio `r` times the mean
disagreement over the first `n` steps [arxiv: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
[arxiv:2511.19433 §1] [arxiv:2511.19433 §4.4] [arxiv: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 [arxiv:2511.19433 tab. 5] [arxiv:2511.19433 §4.5].

### Sampled chunks with MBR selection after a retry

Card: [CycleVLA](/papers/2601.02295), 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` [arxiv: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 [arxiv: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] [arxiv: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 [arxiv:2601.02295 tab. 1], and LIBERO from 96.9
to 98.5 [arxiv: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 [arxiv:2601.02295 §5.4]
[arxiv:2601.02295 tab. 9].

## When to use which

| Situation | Use | Why |
|---|---|---|
| You can retrain or fine-tune the policy, and inference latency limits control | Training-time RTC | No per-step overhead at inference; the authors report parity with inference-time RTC on two real tasks at lower compute [arxiv:2512.05964 §5.2] |
| You cannot change the trained model, or cannot add a per-action time signal | Inference-time RTC | The training-time method needs the per-action flow timestep [arxiv:2512.05964 §4]; the paper gives no recipe for architectures without per-token modulation |
| Inference delay is large and varies | Training-time RTC | Inpainting handles high delays poorly, and the simulated gap grows with delay [arxiv:2512.05964 §5.1] [arxiv:2512.05964 fig. 3] |
| Inference delay is 0 or 1 steps in simulation | Either; check your own numbers | Training-time RTC was slightly lower there; the authors attribute this to fewer supervised first actions [arxiv:2512.05964 §5.1] |
| You need soft use of overlapping actions beyond the committed prefix | Inference-time RTC | Training-time RTC uses a hard prefix only [arxiv:2512.05964 §6] |
| Tight training budget | Check before choosing training-time RTC | It needs extra training: 8 fine-tuning epochs in simulation [arxiv:2512.05964 §5.1] and 8,000 gradient steps per real task [arxiv:2512.05964 §5.2] |
| The best chunk length differs across your tasks, and you can retrain the action head | Multi-horizon training | One model covers several lengths; the authors report gains of about one point on LIBERO [arxiv:2511.19433 tab. 1] [arxiv:2511.19433 tab. 3] |
| You want fewer replanning calls, and the model has the MoH gate | Consensus-based execution length | The authors report higher throughput, with the numbers only in a figure [arxiv:2511.19433 fig. 6] |
| Chunk length is fixed by your controller or you cannot retrain | Keep one horizon, and tune it on your tasks | The multi-horizon gains come from training on several lengths [arxiv:2511.19433 tab. 4] |
| An autoregressive VLA decodes too slowly for your control rate, and you can fine-tune it | Parallel decoding with a chunk and a continuous L1 head (OFT) | The authors report 108.8 Hz against 4.2 Hz on one A100, with no degradation on their tasks [arxiv:2502.19645 tab. 2] [arxiv:2502.19645 §4.2] |
| Starting a new chunked flow or diffusion head | Pick the chunk length for your own control rate and delay | The reported lengths are task-specific: 16 for GR00T N1 [arxiv:2503.14734 §2.1], 8 on LIBERO and 25 on ALOHA for OFT [arxiv:2502.19645 tab. 4] [arxiv:2502.19645 tab. 5] |
| Fine-tuning a diffusion policy with on-policy RL, and you want to execute fewer steps than the policy predicts | Keep `T_a` and `T_p` equal with an MLP; a UNet can use `T_a < T_p` | The paper reports the MLP case as unstable and the UNet case as trainable [arxiv:2409.00588 §4.3] [arxiv:2409.00588 app. B] |
| Your policy returns overlapping chunks and you want smoother joins at run time, and you can afford `N` policy calls per control step | Temporal fusion of overlapping predictions | The fusion is an inference-time rule over the policy's outputs; the latest-only ablation dropped to 38.0% against 82.1% [arxiv:2509.04018 §3.3] [arxiv:2509.04018 tab. 7] |
| Failure detection for a receding-horizon chunked policy, with no failure data | Chunk-overlap consistency | It needs only the policy's own outputs; the paper gives its author-reported results on its own tasks [arxiv:2606.21386 §5] |
| Policy runs fully open-loop chunks | Not chunk-overlap consistency | The paper says the score does not apply [arxiv:2606.21386 §6] [arxiv:2606.21386 app. B] |
| Subtasks can fail and be retried, the robot can return to an earlier state, and you can afford a VLM call per check | Sampled chunks with MBR selection after a retry | The gain comes from the backtrack loop; the paper's real-robot tests use one arm and three tasks, 15 trials each [arxiv:2601.02295 §6.2] |

The fusion gains above come from a single author-reported ablation table, on
four tasks across three robots [arxiv: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 [arxiv:2512.05964 fig. 3] [arxiv:2512.05964 fig. 5].
The multi-horizon and consensus numbers are also author-reported, mostly on
LIBERO with 3B-class base models [arxiv:2511.19433 §4.1]. The failure-detection
results are also author-reported, on their own simulated and real tasks
[arxiv: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.

```pseudocode
# 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 [arxiv:2606.21386 §3.2]:

```pseudocode
# 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
[arxiv:2511.19433 §3.3] [arxiv:2511.19433 alg. 1]:

```pseudocode
# 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 [arxiv:2405.12213 §3.3], an L1 regression head
[arxiv:2502.19645 §4.2] and flow matching [arxiv: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 [arxiv:2511.19433 §3.3], and
MBR selection uses it to pick one chunk among samples [arxiv: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 [arxiv:2512.05964 eq. 2]
[arxiv: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 [arxiv: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 [arxiv:2512.05964 §5.2]
  [arxiv: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 [arxiv:2512.05964 §5.2].
- **Choosing the delay distribution.** The authors say it should match the
  expected latency, but give no rule for doing so [arxiv: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 [arxiv:2512.05964 §4] [arxiv: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
  [arxiv: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)
  [arxiv: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 [arxiv:2606.21386 §3.2]
  [arxiv:2606.21386 app. B] [arxiv: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 [arxiv:2606.21386 app. F] [arxiv: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 [arxiv:2606.21386 app. B].
- **Overlap score: calibration.** Thresholds need calibration rollouts, and one
  outlier can raise the threshold and reduce recall [arxiv:2606.21386 app. D].
- **Horizon set is not fixed.** The multi-horizon paper's default is a stride-3
  set up to 30 [arxiv:2511.19433 §4.1]. Its released code uses other sets for
  its configs, so check the set your checkpoint was trained with
  [arxiv: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 [arxiv: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 [arxiv:2511.19433 §1] [arxiv: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 [arxiv:2511.19433 §4.4]
  [arxiv: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 [arxiv: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 [arxiv: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 [arxiv: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](/papers/2601.02295)
  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 [arxiv:2601.02295 §4.2]
  [arxiv: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 [arxiv: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](/papers/2601.02295) 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 [arxiv:2503.14734 §2.1] [arxiv: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` [arxiv:2503.14734 §1] [arxiv: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` [arxiv:2502.19645 §5.1]
  [arxiv: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 [arxiv: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 [arxiv:2509.04018 §4.1] [arxiv: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 [arxiv:2509.04018 eq. 8] [arxiv: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 [arxiv:2509.04018 alg. 1].
- **Ensembling weights are not in FILIC.** Its policy uses temporal ensembling,
  but the weighting is not stated [arxiv: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 [arxiv:2503.03734 tab. model-arch]
  [arxiv: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 [arxiv:2512.06963 §4.1]. The
  [VideoVLA card](/papers/2512.06963) has the line references.
- **HACTS states no chunk size.** Its ACT results therefore cannot be compared
  with other chunked policies on chunk length [arxiv: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](/papers/2412.11974) has the line references.
  Choose one replanning rule and state it in your own code
  [arxiv:2412.11974 app. F] [code: experiments/robot/bridge/run_bridgev2_eval.py#L183].
- **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](/papers/2409.00588) gives the line references
  [code: model/diffusion/diffusion_ppo.py#L96-L98].

## Papers

- [Training-Time Action Conditioning for Efficient Real-Time Chunking](/papers/2512.05964): 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](/papers/2511.19433): 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](/papers/2601.02295): 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](/papers/2405.12213): a pretrained transformer policy whose diffusion head denoises whole action chunks; no continuity scheme.
- [Fine-Tuning Vision-Language-Action Models: Optimizing Speed and Success](/papers/2502.19645): 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](/papers/2503.14734): a humanoid VLA whose flow-matching head outputs 16-action chunks with 4 Euler steps; the linked code is a later release.
- [VLA-FAIL](/papers/2606.21386): 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](/papers/2509.04018): 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](/papers/2503.03734): 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](/papers/2512.06963): 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](/papers/2503.24070): 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](/papers/2412.11974): 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](/papers/2409.00588): 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](/papers/2509.17053): 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.