Technical Summary: Rethink Before You Execute: Adaptive Execution for World Action Models

Problem Statement

World Action Models (WAMs) represent a paradigm for robot manipulation that jointly predicts future actions and environmental evolution. Standard WAM deployment involves generating a "chunk" of future actions and executing a fixed prefix of that chunk before triggering a replanning step. The authors argue that this fixed execution horizon is fundamentally mismatched to execution dynamics.

As illustrated in the paper, the reliability of action chunks is stage-dependent:

• Easy stages: Chunks remain accurate for many steps, making frequent replanning computationally wasteful.
• Hard stages: Errors accumulate rapidly after only a few steps, making a fixed horizon prone to failure if it does not replan early enough.

Existing adaptive execution methods rely on proxy metrics such as action entropy, prediction consistency, or attention weights. The authors contend these are insufficient because they do not explicitly measure the critical factor for execution: whether the task is actually advancing. A sequence can be smooth (low entropy) yet make no progress, or high-entropy yet advance the task. Furthermore, many existing methods (e.g., verification via future imagination) introduce prohibitive computational costs or require online reinforcement learning, which is impractical for deployment.

Methodology: TempoWAM

The paper proposes TempoWAM (Timing Execution by Monitoring Progress Online), a lightweight, plug-and-play execution scheme that adapts the execution horizon based on estimated task progress rather than step counts. It consists of two primary components:

1. Recurrent Progress Monitor (RPM)

The RPM is a lightweight module that estimates the task progress ($v_t \in [0, 1]$) that would be reached if the current candidate actions were executed. It takes the following inputs:

• Current Observation ($o_t$): Encoded via the frozen visual backbone of the base WAM.
• Candidate Action Prefix ($c^{rem}_t$): The next $n_t$ actions from the remaining chunk, encoded by a recurrent encoder.
• Execution History ($v_{t-1}$): The previous progress estimate, injected via a learned projection to maintain temporal context.
• Task Instruction ($\ell$): Embedded from the base WAM.

The module uses a GRU core to aggregate these features and output a progress estimate. It is trained on demonstration trajectories using a binary cross-entropy loss against time-based progress labels ($y_u = u/T_{ep}$), augmented with smoothness and history-consistency regularizations to ensure stability and robustness to visual noise.

2. Adaptive Execution Protocol (AEP)

The AEP decides whether to continue executing the current chunk or to discard the remainder and replan. It operates by comparing the observed progress rate ($\rho^{cur}_t$) against a required progress rate ($\rho^{need}_t$).

• Progress Rate: Instead of absolute progress, the system evaluates the rate of advancement per step.
• Calibration: To bridge the gap between training supervision and deployment reality, the protocol employs a two-timescale calibration factor ($\kappa_{final}$):
  • Offline Calibration: A task-specific factor ($\kappa_{task}$) is derived from demonstration episodes via least squares fitting.
  • Online Adaptation:
    • Intra-episode: An Exponential Moving Average (EMA) updates the factor to track drift within a single episode.
    • Inter-episode: A scaling factor ($\delta'$) adjusts based on the success rate relative to a target ($s^*$). If success is below target, the protocol tightens (replans earlier); if above, it relaxes (replans less) to improve efficiency.

The decision rule is: if the calibrated ratio $r_t \ge 1$, execution continues; otherwise, the chunk is discarded, and the WAM is invoked for a fresh prediction.

Key Contributions

1. Shift in Criterion: The authors demonstrate that assessing action rationality alone is insufficient for adaptive execution. They argue that task progress is the natural and necessary criterion for deciding when to replan.
2. Plug-and-Play Architecture: TempoWAM is designed to be a lightweight add-on. It does not require modifying or retraining the backbone WAM. It operates entirely at the execution layer, making it compatible with various WAM architectures (demonstrated on FastWAM and Motus).
3. Efficiency-Success Trade-off: The method achieves a superior balance between computational cost (inference calls) and task success by dynamically extending chunk reuse on easy stages and triggering early replanning on difficult stages.

Experimental Results

The authors evaluated TempoWAM on simulation benchmarks (LIBERO, RoboTwin 2.0) and real-world robotic tasks.

• RoboTwin 2.0:

  • Short-horizon tasks: TempoWAM preserved or slightly improved success rates while reducing WAM inference calls compared to fixed horizons.
  • Long-horizon tasks: It improved success rates by 1.54 points (clean) and 0.87 points (randomized) while reducing executed steps, outperforming fixed horizons of 12 or 24 steps.
  • Comparison: It significantly outperformed adaptive baselines like Auto-Horizon (attention-based) and AAC (entropy-based), which either failed to improve success or incurred excessive computational costs.

• LIBERO Benchmark:

  • TempoWAM reduced average WAM calls from 14.88 to 12.46 while preserving success rates across all four suites (Long, Spatial, Object, Goal).
  • On the LIBERO-10 suite, it improved success from 95.00% to 95.60% while reducing calls.

• Real-World Robots:

  • On three tasks (take drinks, pick and place, pack hand cream), TempoWAM reduced calls by 26.9% on the easiest task ("take drinks") and improved success by 13.3 percentage points on difficult tasks generally (specifically the "pack hand cream" task, which is the hardest among the evaluated set).
  • Cross-Backbone Generalization: When attached to the Motus WAM without retraining, TempoWAM improved success by 59 points specifically on the "move_can_pot" task, confirming its architecture-agnostic nature.

• Computational Overhead:

  • The RPM adds negligible overhead. With visual encoding, it consumes 3.54% of the time of one optimized WAM inference call; with shared features, this drops to 0.34%.

Significance and Claims

The paper claims that TempoWAM addresses a critical limitation in current WAM deployment: the rigidity of fixed execution horizons. By grounding execution decisions in estimated task progress, the system adapts to the actual state of the environment rather than relying on indirect uncertainty proxies or predetermined step counts.

The authors emphasize that their approach is progress-aware and efficient. It does not require expensive future imagination or online RL training. Instead, it leverages a lightweight recurrent monitor and a calibrated protocol to dynamically adjust the execution horizon. The results suggest that for WAMs, the decision to replan should be driven by whether the remaining actions are still advancing the task, a capability that TempoWAM provides consistently across simulation and real-world domains.

The paper concludes that while time-based labels are valid for non-repetitive, progress-monotonic tasks (which covers their evaluated benchmarks), future work is needed to handle periodic or symmetric tasks where observation-to-label mapping is not one-to-one.