Action Chunking in VLA: A Cheat Sheet for H and K Horizons

Prerequisite

In classic MDP, an agent outputs a single action $a_t$ given a state $s_t$ or an observation $o_t$. However, an action chunking policy $\pi(\mathbf{A}_t \mid \mathbf{o}_t)$ outputs a sequence of actions, or an action chunk,

$\mathbf{A}_t=[\mathbf{a}_{t}, \mathbf{a}_{t+1},\dots,\mathbf{a}_{t+H-1}]$

instead of single action.

Here, $H$ is the prediction horizon (the number of actions predicted) and $K$ is the execution horizon (the number of actions actually executed).

Tip

The execution horizon is often shorter than the prediction horizon ($K \leq H$). This means we intentionally discard the remaining predicted actions and run inference again to react to new observations.

Remark

In academic literature, the term action chunk and action horizon are often used interchangeably.

Prologue

This is a cheat sheet detailing the sizes of the prediction horizon ($H$) and execution horizon ($K$) for several popular Vision-Language-Action (VLA) models.

As of July 2026, there is no universally optimal pair of $H$ and $K$. Based on my observations, $H$ is typically fixed based on the model checkpoint or task, whereas $K$ is a deployment-side choice used for replanning.

Tip

From an application perspective, this means $H$ is fixed during training, but $K$ can be tuned during deployment.

OpenPI

For the default $H$ values in the base checkpoints of $\pi_{0}$, $\pi_{0.5}$, and $\pi_{0}$-FAST, here is the code evidence:

• (H=50)
• (H=32);

During SFT on dataset like DROID and 📄LIBERO: Benchmarking Knowledge Transfer for Lifelong Robot Learning, these values are overridden in the training configurations. The execution horizons are defined by the deployment systems, such as ALOHA broker, DROID controller, and LIBERO replanning loop.

Error

One upstream bug is worth noting: the current DROID server defaults to $\pi_{0.5}$ with $H=15$, but the client still asserts a stale shape of $(10, 8)$. The intended configuration is $(15, 8)$, though the code example currently needs its assertion fixed.

Isaac-GR00T

© NVIDIA Isaac-GR00T

For the latest N1.7 release:

N1.7 checkpoint/task	$H$	$K$ used officially
Base N1.7-3B	40	16 offline; commonly 8 real-time
DROID	40	15 in the real-robot example
LIBERO	16	8
SimplerEnv Google robot	8	1
SimplerEnv WidowX	8	4
Custom SO-100/101	16	16 offline; 8 real-robot

GR00T’s documentation explicitly distinguishes the prediction action_horizon from the execution_horizon. The base N1.7 model uses $H=40$, with $K=16$ for offline evaluation and $K=8$ typically used for real-time deployment (official policy guide). Fine-tuned horizons are specific to the embodiment, as seen in the registered modality configurations.

If you see $H=16$ quoted for GR00T, it likely refers to the older N1 or N1.5 releases and does not apply to the N1.7 base model.

📄MolmoAct2: Action Reasoning Models for Real-world Deployment

These values are stored per embodiment as action_horizon and n_action_steps in the released MolmoAct2 checkpoint metadata. Similarly, the LeRobot configuration for LIBERO uses chunk_size=10, n_action_steps=10.

Warning

There is one concrete exception: the released YAM metadata says $(H,K)=(30,30)$, but the included YAM client hard-codes 25, and its rollout replans every 25 actions. Its effective deployed pair is therefore: $(H,K)=(30,25),$ with the final 5 predictions discarded.