Action chunking is a policy design in which each inference predicts a sequence of future actions instead of oneSource 2. The term comes from psychology, where actions grouped into one unit are cheaper to store and executeSource 2 Source 17.

Five photographs of ALOHA 2 bimanual robot arms at work, labelled Robot Finger Replace, Shirt Hanging, Gear Insertion, Shoelace Tying and Kitchen Stacking.
Chunked policies now do dexterous bimanual work such as tying shoelaces and hanging shirts. ALOHA Unleashed collected over 26,000 demonstrations for these five tasks on ALOHA 2 and ran each predicted chunk open loop.
Paper figure: Tony Z. Zhao et al. / arXiv. Licence: CC BY 4.0.

Diffusion, flow and vision-language-action policies now all chunkSource 18. Try “100 moves per plan”.

Action chunking
Batching 100 moves lifts success from 1% to 44%
How the robot plans
Adjust more
1101004000%25%50%moves per plantask successestimate1%, measured44%, measuredone move at a time: 400 decisions100 moves per plan: 4 decisions4 decisions per task instead of 400:44 successes in 100 tries

100 moves per plan: 44% success, 4 decisions per 400-move task

Only the two dots have published numbers; the line and dashed taper are authored estimates.

Fewer decisions means fewer chances to slip: deciding 4 times per task instead of 400 made a simulated robot far more reliable.
How this was made

Chunk size k is how many moves the robot commits to per decision. The two dots are ACT's own ablation (Zhao et al., 2023): 1% success at k = 1 and 44% at k = 100, the mean of two simulated tasks, Cube Transfer and Bimanual Insertion, each trained on scripted and on human demonstrations with temporal ensembling disabled. The paper plots the other chunk sizes it trained but gives numbers only for these two. The line between them is a log-linear interpolation drawn for reading, and the dashed line past k = 100 is an estimate: the paper reports a slight decline at k = 200 and k = 400 without exact numbers.

The ticks count decisions in a 400-step episode, 8 s of motion at 50 Hz: one per step at k = 1, and 400 / k rounded up otherwise. The x axis is logarithmic.

Task success rises from 1% at chunk size k = 1 to the measured 44% peak at k = 100, and at the current k = 100 the curve reads 44% success against 4 closed-loop decisions per 400-step episode; the dashed estimate line past k = 100 stands in for the slight decline the ACT ablation reports at k = 200 and k = 400 without exact numbers.

Sampled success rate and decision count by chunk size
chunk size ksuccessdecisionsprovenanceplayhead
11%400measuredoff
2514%16interpolatedoff
5025%8interpolatedoff
10044%4measuredplayhead
20039%2estimatedoff
30034%2estimatedoff
40030%1estimatedoff
Measured points: ACT ablation (Zhao et al., 2023), mean of two simulated tasks. The taper past 100 moves per plan is an estimate.

Why chunking works

Behavior cloning with per-step error ε on the expert's states can accumulate cost quadratic in episode length T, because each mistake carries the robot into states the expert never visitedSource 1. DAgger relabels the states the policy visits; its excess cost is linear in T only if u, the rise in expert cost-to-go after one action, does not grow with TSource 1:

O(εT2)behavior cloningO(u εT)DAgger\underset{\text{behavior cloning}}{O(\varepsilon T^2)} \qquad \underset{\text{DAgger}}{O(u\,\varepsilon T)}

Action chunking shortens the horizon instead: k actions per inference cut it k-foldSource 2. With continuous actions, smooth deterministic imitators can suffer execution error exponentially larger in the horizon than their training error, part of why chunking and diffusion policies workSource 19, and chunking avoids that compounding through control-theoretic stabilitySource 20.

ACT: chunking with a CVAE

Action Chunking with Transformers (ACT), introduced with the ALOHA bimanual teleoperation hardware, wraps chunking in a conditional variational autoencoder: training encodes each demonstrated action sequence as a latent style variable, and at test time the policy decodes a chunk from camera images and joint positions with that latent at zero. Dropping the CVAE objective barely changes scripted-data results and cuts human-data success from 35.3% to 2%Source 2.

A rendered ALOHA 2 workcell: two pairs of black robot arms facing each other across a table inside an aluminium frame with overhead cameras, with letters A, B and C marking measured segments.
ACT was introduced with ALOHA, a low-cost bimanual rig on which a person demonstrates by moving leader arms. A render of the ALOHA 2 workcell, with its frame segments labelled A, B and C.
Paper figure: Tony Z. Zhao et al. / arXiv. Licence: CC BY 4.0.
100
chunk size k
2 s of motion per inference
50 Hz
control rate
~80M
policy parameters
ResNet-18 backbones plus transformer
44%
success at k=100
1% at k=1, simulated ablation

ACT reference configuration

observations
4 RGB cameras plus joint positions
action space
14-dim continuous, two 6-DoF ViperX arms plus grippers
training objective
L1 reconstruction plus KL on the style latent
test-time latent
z fixed to zero (deterministic decode)
execution
temporal ensembling over overlapping chunks

The 14 action coordinates are six joints and one gripper coordinate for each of two six-DoF ViperX arms; the paper's "7+7=14 DoF" counts the grippers. ACT's implementation description specifies L1 reconstruction, while the printed algorithm uses MSE; both add a weighted KL termSource 2.

The chunk-size dial

In ACT's ablation, averaged over two simulated tasks with temporal ensembling off, success rises from 1% at k=1 to 44% at k=100 and dips at k=200 and k=400, near open-loop control; chunked BC-ConvMLP and VINN follow the same trendSource 2. A small k brings back compounding error, and a large one reacts slowly to unexpected statesSource 21. The best execution horizon is task-dependent: in flow-based VLAs success rises and then falls as it lengthensSource 22, and PACE, which picks it online, lifted real ALOHA and Franka success from 50.7% to 70.4%Source 23.

Temporal ensembling and its limits

The pinned ACT reference implementation uses temporal ensembling: it queries the policy every timestep and averages, oldest to newest, the retained predictions for the current action. Weights are wi=exp⁡(−m⋅i)w_i = \exp(-m \cdot i), where i=0i = 0 is the earliest prediction and m=0.01m = 0.01, so the oldest prediction weighs mostSource 3. The best decay rate varies by taskSource 21.

Temporal ensembling
Three overlapping plans vote; the oldest gets the loudest voice
Original schematicoldest plan, 51%next plan, 31%newest plan, 19%the move it makes
Blending several overlapping plans smooths the robot’s motion, so one odd prediction jerks the arm less.
How this was made

A schematic, not data. In ACT the robot asks its policy for a fresh chunk of future moves at every control step, so the chunks issued at earlier steps each still hold a prediction for the current move. Temporal ensembling averages those predictions, and the oldest gets the largest weight.

Counting from the oldest (i = 0), prediction i gets the raw weight w_i = exp(−m·i); the weights are then divided by their sum. The drawing uses m = 0.5 so the three weights differ visibly: raw 1.00, 0.61, 0.37, which is 51%, 31%, 19% of the vote. The ACT reference code uses m = 0.01, which makes the weights almost equal.

Diagram: Robot Wiki contributors / Robot Wiki (original diagram). Licence: CC BY 4.0.
temporal_ensembling.py
# ACT reference convention: preds contains current-step predictions already
# selected and ordered oldest-to-newest. Index 0 is the oldest retained
# prediction, not "zero chunks ago". Reference m=0.01. This helper does not
# reproduce ACT's raw-buffer nonzero occupancy filter.
def temporal_ensemble(preds: list[np.ndarray], m: float = 0.01) -> np.ndarray:
    weights = np.exp(-m * np.arange(len(preds)))   # w_i = exp(-m * i)
    weights /= weights.sum()
    return np.tensordot(weights, np.stack(preds), axes=1)

For oldest-to-newest predictions [0, 10, 20] after selection, m=0.01m = 0.01 gives normalized weights of about [0.33667217, 0.33332222, 0.33000561] and an average of 9.93333444; the reference occupancy filter would discard a literal zeroSource 3.

When consecutive chunks diverge in strategy, say left versus right around an obstacle, averaging them can backfireSource 21. Demonstration pauses, unpredictable from a single Markovian state, freeze single-step policies, as both ACT and Diffusion Policy documentSource 2 Source 5.

Real-Time Chunking (RTC) treats the hand-off between chunks as inpainting: it freezes actions that will already have run and generates the rest. With π0.5 at five denoising steps, model latency was 76 ms for the baselines and 97 ms for RTC, plus 10 to 20 ms over LAN. At 100 or 200 ms of injected delay, temporal-ensembling variants triggered protective stops, while RTC held average task throughput through +200 ms without retrainingSource 6, over six tasks, ten episodes eachSource 7.

A training-time variant matched inference-time RTC at lower computeSource 24, LeRobot ships RTC for Pi0, Pi0.5 and SmolVLASource 25, and A2C2's per-step correction head beats RTC by 23 points on KinetixSource 26. In the toy below, press “None” to watch the two plans agree.

Ensembling vs real-time chunking
Averaging two good plans can produce one bad move
Thinking delay
Adjust more
Each groove is a good plan. Run the plotter.averaging 0% (fails) · real-time chunking 100%

Illustrative: a toy scene, not measured robot data.

When a new plan arrives late, averaging it with the old one can pick a path neither plan chose; real-time chunking keeps them consistent.
How this was made

Deterministic toy, not measured throughput. This qualitative model illustrates a possible cross-mode hand-off: the arm can pass an obstacle on the left or on the right, and the demonstrations hold both. Temporal ensembling averages the plan in flight with newer ones. With an added delay d, the weight it keeps on the committed go-left plan is w = 0.5 + 0.5 / (1 + (d / 125 ms)³), and the executed move is (2w − 1) × 0.8, where +0.8 is go left and −0.8 go right. A move within 0.25 of either counts as on a plan; anything weaker than 0.55 heads into the obstacle, and the toy score falls from 100% to 0% as it does. Real-time chunking freezes the moves already committed, so it stays on the go-left plan at every delay and its score is held at 100% by assumption.

The presets are the three settings the π0.5 real-time chunking experiment tested: +0, +100 and +200 ms of injected delay on top of 76 ms model latency for the baselines (97 ms for RTC) and 10 to 20 ms over the network. Its temporal-ensembling variants triggered protective stops at +100 and +200 ms, and RTC showed no drop in average task throughput across six tasks through +200 ms (Black, Galliker and Levine, 2025). The toy's percentages, its curve between those settings, the flat RTC line and the slider's reach past +200 ms are assumptions; the delay where it collapses is not a universal latency threshold.

The plotter is a schematic of that hand-off. Each groove is one plan, the pen's place on the beam is the executed move, and the post is as wide as the moves that count as off both plans. It replays a 24-tick hand-off sampled once per controller tick; the late plan arrives at tick 8, where the trip dog sits on the ruler. Running, it moves 7 ticks a second.

0501001502002400%100%added delay (ms)toy scorereal-time chunkingaveraging plans

Deterministic toy, not measured throughput: at 200 ms of added delay, the normalized toy scores are 0% for temporal ensembling, marked failed, and 100% for RTC. The experiment's temporal-ensembling variants triggered protective stops at its +100 and +200 ms settings; where this toy collapses between them is an assumption, not a universal latency threshold. The curve between settings and its continuation beyond +200 ms are illustrative assumptions.

Sampled toy throughput scores by added delay
delay (ms)ensemblingchunkingensembling statusplayhead
0100%100%nominaloff
6085%100%degradedoff
1000%100%failedoff
1400%100%failedoff
2000%100%failedplayhead
2400%100%failedoff

Across the 24-tick hand-off at 200 ms of delay the real-time chunking action stays on the committed go-left mode at 0.80 while the ensembled action leaves both valid modes, ends at 0.16 and runs into the post; the post between the two plan grooves is drawn for illustration, and the grooves are the modelled modes rather than measured actions.

Sampled executed action across the hand-off
tickensemblingchunkingensembling validity
00.800.80on a mode
40.800.80on a mode
80.590.80on a mode
120.160.80off-mode
180.160.80off-mode
230.160.80off-mode
Deterministic toy after the real-time chunking experiment of Black, Galliker and Levine (2025, arXiv 2506.07339).

The lineage in numbers

In the table, not disclosed means the source omits the value, and weights means download availability. Physical Intelligence's openpi README lists base checkpoints for π0, π0-FAST and π0.5Source 10.

Action horizon (predicted actions) and reported frequency (Hz). Setup-specific prediction, execution and controller rates are not interchangeable. Applicable unpublished values are not disclosed. Weights mean download availability, not license openness.
Action representationWeights
RT-1202213Everyday Robots commanded control256 discrete bins per dimnot disclosedPretrained weights not disclosed in the checked RT-1 paper; its code-release statement is not a weight release
ACT202310050CVAE decoder, continuous k x 14not disclosedThe checked ACT paper announces software/hardware and per-task training, not downloadable pretrained checkpoints
Diffusion Policy20231610DDPM over action chunksdownloadable
Octo202464ALOHA finetuning: executes 12 of 64; not universalnot disclosedNo universal rate disclosed; separate setups: Franka prediction 15 Hz, coffee controller 10 Hz, ViperX control 5 Hzdiffusion action head (chunked)downloadable
pi0202450Executes 16 on UR5e/Franka; 25 on other evaluated robots20UR5e/Franka; other evaluated robots 50 Hz (paper: up to 50 Hz)flow matching, continuousdownloadable
pi0.520255050 predictions (inclusive H=49); executed count not disclosed in the v1 paper50v1 paper mobile-manipulation targets; not inference throughputpaper: flow matching + FAST supervision; openpi: flow head onlydownloadableopenpi snapshot lists the base π0.5 checkpoint; download availability does not establish license terms
pi0.62025not disclosedPredicted and executed counts not disclosed in the November 17, 2025 model cardnot disclosedRobot-control Hz not disclosed in the model card; 63 ms chunk inference uses five denoising steps, three cameras and one H100continuous-action flow matching; FAST backbone supervision during trainingnot disclosedModel-specific weight-release and licensing terms not disclosed in the checked pi0.6 model card
pi0.7202650Five denoising steps; executes either 15 or 25; paper does not map these choices to robots20UR5e reference; other tested robots 50 Hzcontinuous-action flow matching; FAST backbone supervision during trainingnot disclosedModel-specific weight-release and licensing terms not disclosed in the checked pi0.7 paper
GR00T N1.7202640N1.7 README model horizon; executed count is rollout-dependent, not disclosed as one valuenot disclosedNo universal robot-control Hz disclosed in the checked N1.7 README; inference throughput is not control frequencyflow-matching DiT head, relative EEFdownloadableGA README lists downloadable weights; License section: code Apache 2.0, weights NVIDIA Open Model License
Helix 022026not disclosedChunk length not disclosed in the January 27, 2026 announcement; not inapplicable200S1 joint targets (200 Hz), tracked by S0 actuator commands (1 kHz)not disclosedWeight-release and licensing terms not disclosed in this announcement

Octo's ALOHA fine-tuning example predicts 64 actions and executes 12 before replanningSource 8, and RT-1 predicts one action per timestep; its paper announces open codeSource 11. π0 generates its chunks with conditional flow matchingSource 9, and π0.5 combines FAST tokens with flow matchingSource 12, though openpi supports only its flow-matching headSource 10.

The π0.6 model card, dated November 17, 2025, reports 63 ms per action chunk with five denoising steps and three cameras on one H100Source 15. π0.7 predicts 50-step chunks and executes 15 or 25, at 20 Hz on UR5e and 50 Hz elsewhere; it distills experience from RL-trained π*0.6Source 16. NVIDIA's GR00T N1.7 README lists a predicted horizon of 40 and downloadable weights, under Apache 2.0 in its overview and the NVIDIA Open Model License in its License sectionSource 13; GR00T N1 processed actions "in chunks as in Zhao et al. (2023)" with H=16Source 27.

Figure's January 27, 2026 announcement has Helix 02's S1 sending full-body joint targets at 200 Hz, tracked by S0 actuator commands at 1 kHzSource 14. Gemini Robotics turns about 250 ms of end-to-end latency into an effective 50 Hz control frequency by packing several actions into each chunkSource 28.

Chunking on mobile robots and in RL

Mobile ALOHA moves the recipe to a wheeled whole-body platform, where co-training on static ALOHA data raises success substantiallySource 4, and ALOHA Unleashed scaled it to over 26,000 real demonstrations for 5 tasks with a diffusion policySource 29. In RL fine-tuning, Q-chunking runs RL in a chunked action space for better exploration and unbiased n-step backupsSource 30.