Rethink Before You Execute: Adaptive Execution for World Action Models
1. Paper overview
In one sentence: TempoWAM uses predicted task progress to spend replanning calls where action chunks become unreliable, trading computation against success through a calibrated execution rule. motivationexecutionrpmratescalibrationrobotwinrobots
| At a glance | What to know |
|---|---|
| Research problem | Author claim A fixed execution horizon spends WAM calls on still-reliable actions during easy stages, yet can retain unreliable actions during difficult stages. The authors propose predicted task advancement as a more relevant execution criterion than action plausibility or uncertainty alone. motivation |
| Core mechanism | |
| A key reported result | Real-robot pack hand cream: 63.3%; 57.2 calls. SR (%); successful-episode calls. Long, difficult dual-arm packing task; 30 trials. Baseline: 50.0%; 49.4 calls. A reported 13.3-percentage-point success gain costs more calls. No uncertainty intervals are supplied. robotsprotocol |
| Reading caution | Author claim The mirrored take-drinks diagnostic fails under time labels. The authors restrict the supported regime to progress-monotonic, non-repetitive observations and propose phase or semantic labels for periodic/symmetric tasks. aliasing |
Core contributions
- Source description
Offline task calibration and adaptation within and across episodes convert predicted progress into a task-scaled execution threshold; experiments include frozen FastWAM and transfer to Motus. calibrationprotocoltransfer
Figure 2. The monitor intervenes between action generation and execution. Original paper, p. 2 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Follow the top row from the WAM to the unconditional first prefix. The remaining-actions block loops upward through execution when the answer is yes; no leads to discard and replanning. Chunk exhaustion has its own route to a fresh WAM call. The lower-left panel expands the decision: the current observation, instruction, candidate actions, candidate length, decision index and prior progress enter RPM; its predicted progress reaches AEP. Equation (11) supplies the precise branch rule: continue when the calibrated ratio is at least one, replan below one. The lower-right panel illustrates how the same protocol can shorten or extend reuse across stages. executionrpmratescalibration
What it supports. The learned output is progress after candidate execution, while the robot still executes actions generated by the frozen WAM. This placement permits the execution horizon to change without retraining that backbone. It also means every new chunk begins with an unchecked prefix before the monitor evaluates further reuse.
Where the evidence stops. The figure and caption define a prospective prediction. Section 3.4 calls the corresponding rate observed, but it is computed from predicted progress differences. Treat the estimate as a decision signal, not a measured future outcome.
2. Motivation
2.1 The problem and the proposed response
A fixed execution horizon spends WAM calls on still-reliable actions during easy stages, yet can retain unreliable actions during difficult stages. The authors propose predicted task advancement as a more relevant execution criterion than action plausibility or uncertainty alone. motivation
2.2 What this reading follows
A robot can receive a sensible action chunk whose later actions become unreliable after contact or positioning errors. Replanning at a fixed interval handles this unevenly: an easy segment may tolerate more reuse, while a difficult segment needs earlier correction. TempoWAM places a small recurrent progress monitor between a frozen WAM and execution. It predicts the progress expected after the next candidate actions, then compares their predicted rate with a calibrated requirement. The experiments show both fewer calls at unchanged success and higher success at increased calls. Reading those outcomes together reveals the contribution: allocating replanning effort according to the execution state. motivationexecutionrpmratescalibrationrobotwinrobots
3. Research context
We place the paper in the collection through its world–action interface. The catalog labels and the reading’s assessment are shown separately.
| Catalog dimension | Recorded classification |
|---|---|
| Major category | WAMs |
| Architecture | Not applicable |
| Prediction paradigm | Other mechanisms |
| Quadrant | Outside quadrants |
3.1 Evidence-based assessment
Supports the recorded classification
The recorded Outside quadrants / Other mechanisms / Not applicable architecture classification fits an execution-layer monitor and scheduler. TempoWAM does not introduce a joint future/action generator or inverse-dynamics policy. Its recurrent history and inference scheduling support the memory and efficiency tags; the backbone’s architecture should not be assigned to the wrapper. executionrpmcalibration
This is the collection’s architectural analysis, not a new related-work survey. Benchmark comparisons and their protocols appear in Section 6.
4. Problem formulation
4.1 Inputs and outputs
| Inputs | Outputs |
|---|---|
|
|
4.2 Equations and their role
5. Method in detail
5.1 Separate action generation from the decision to keep executing
Start with a WAM that has already produced an action chunk. TempoWAM leaves that generation process intact and executes a short initial prefix. At the next decision, the monitor sees the new observation together with the remaining candidate actions, rather than judging the original chunk in isolation. A recurrent action encoder summarizes the proposed prefix; frozen visual features summarize the current scene. Previous progress and a recurrent state provide execution history, while the instruction identifies the task. The output estimates where progress would stand after the proposed prefix. AEP then accepts that prefix or discards the remainder and requests a fresh chunk. This ordering matters: the monitor predicts an effect before execution, and the backbone remains responsible for generating the actual controls. executionrpmconfigurationcalibration
Figure 4. The decision threshold changes the timing of WAM calls within an episode. Original paper, p. 7 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Use the legend before reading the timelines. Gray triangles indicate reuse, green crosses indicate discarding the remainder, and green diamonds indicate a fresh call after chunk exhaustion. The upper panels plot the calibrated decision ratio relative to the red threshold; the lower panels place TempoWAM and fixed-24 inference calls on the episode-step axis. On the microwave example, crosses cluster in the shaded hard stage and connect to additional calls below. On the stapler example, reuse dominates and fresh calls follow exhaustion. Equation (11) resolves the exact inequality even where a plotted marker lies close to the threshold. behaviorcalibrationrobotwin
What it supports. The microwave example ends in TempoWAM success and baseline failure, while both stapler runs succeed. Together these cases illustrate the intended mechanism: respond to a deteriorating chunk before the fixed schedule would replan, and retain a reliable chunk when an early fresh call would add little value.
Where the evidence stops. These are selected episodes, not aggregate causal evidence. The ratio panels lack numeric vertical ticks, so exact ratio values cannot be recovered. Use the benchmark tables to assess overall success and cost.
5.2 Turn a progress prediction into a task-scaled threshold
A fixed progress increment means different things for tasks of different duration. TempoWAM divides the predicted increment by candidate length, then compares that rate with the progress still needed over the remaining average demonstration duration. The required rate also has a floor. Offline calibration fits autoregressive progress predictions against scaled time trajectories and takes the median episode factor for each task. During deployment, an EMA updates this factor from raw rate ratios. A second multiplier changes across episodes according to recent success: falling below the target raises the multiplier and makes the continuation test stricter. Figure 5 isolates within-episode adjustment, while Table 7 shows different final multipliers across tasks. These diagnostics illustrate adaptation; the formula does not guarantee that an arbitrary task reaches its target success rate. ratescalibrationadaptation-diagnostic
5.3 Read the supervision assumption alongside the success numbers
Normalized episode time supplies inexpensive progress labels, but the execution rule relies on differences between the resulting predictions. Smoothness and masked-history consistency therefore serve a practical role: they stabilize the signal that triggers replanning. Mixed teacher forcing exposes the monitor to its own history estimates during training, closer to deployment than always supplying labels. Table 8 supports these choices through higher reported success, although altered call counts complicate comparisons. The mirrored-sequence diagnostic then reveals a more fundamental boundary: visually repeated states can receive incompatible time labels, and this trained monitor fails. As reader analysis, the failure supports caution about supervision, but does not prove history cannot resolve repetition. A recurrence-aware, phase-labeled comparison is needed before generalizing the limitation to all progress estimators. lossesratesrpmablationaliasing
5.4 Training and inference
During training
Use the same demonstrations as the backbone. Soft-label BCE learns normalized-time progress; smoothness matches adjacent predicted and target increments; history consistency penalizes changes caused by zero-masking observations. Padding is masked. Probabilistic teacher forcing mixes ground-truth and predicted history. lossesablation
Train the 2.27M-parameter monitor for 20 epochs with teacher-forcing probability 0.5, observation-masking probability 0.3, smoothness weight 0.1 and consistency weight 0.05. The WAM remains frozen. configurationprotocol
During inference
AEP continues when the calibrated ratio is at least one; otherwise it discards remaining actions and calls the WAM. Exhaustion also requests a fresh chunk. The tested prefix size is 10 in simulation and 4 on robots. No future-image generation is required by this monitor. executioncalibrationconfiguration
The rate is computed from predictions, although Section 3.4 calls it observed progress. Section 3.3 and Figure 2 define the output prospectively, before candidate execution; it is not a direct measurement of that candidate’s realized effect. rpmratesexecution
5.5 Implementation flow
- Generate and begin a chunk
The base policy maps observation and instruction to H actions of dimension d_a. Execute the first n_p actions unconditionally, then consider the next min(n_p, remaining length) actions. execution
- Predict candidate-conditioned progress
Frozen WAM visual features pass through an MLP. A GRU encodes candidate actions, with a length embedding. Observation, action, previous-progress projection and temporal position embeddings feed a recurrent GRU; a sigmoid MLP combines its state, observation features and instruction embedding. A learned start token replaces unavailable previous progress. rpmconfiguration
- Calibrate the progress-rate test
Fit an episode factor by least squares between autoregressive predictions and a scaled time trajectory using average task duration; the median initializes task calibration. Within episodes, an EMA tracks raw progress-rate ratios. Across episodes, a clipped multiplier increases when recent success falls below target. ratescalibration
6. Experiments & results
TempoWAM changes when a robot requests another action chunk. A recurrent monitor predicts progress after the next candidate actions; a calibrated protocol either executes them or requests replanning from a frozen WAM. Experiments show task-dependent computation savings or success gains, with normalized-time supervision limiting applicability to non-repetitive tasks.
6.1 Read the original evidence
Table 1. Short tasks save calls; long tasks spend more calls to improve success. Original paper, p. 4 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Read each condition as three columns: success rate, inference calls and executed steps. The number column counts tasks, not trials; Section 4.1 specifies 100 trials per task. Short tasks are those whose baseline average calls are below ten, and the remaining tasks form the long group. Compare TempoWAM first with Baseline-24 within each group, then use Baseline-12 to ask whether simply replanning more often explains the result. Parentheses show changes against Baseline-24. The overall row aggregates different directions of adaptation, so a higher overall call count can coexist with call savings on short tasks. robotwinprotocol
What it supports. In clean short tasks, calls fall from 5.97 to 5.51 while success rises from 93.71% to 94.74%. In clean long tasks, success rises from 86.93% to 88.47% while calls increase from 15.02 to 21.67. The useful behavior is allocating extra replanning to the latter group.
Where the evidence stops. Calls and steps describe successful episodes only. The table reports no uncertainty intervals and does not match compute budgets. Small printed parenthetical differences can reflect rounding; keep the original values rather than silently correcting them.
Table 5. The physical experiments separate an efficiency gain from success gains. Original paper, p. 6 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Each task has a success-rate column and a call-count column. Section 4.3 gives 30 trials per task. Figure 3 on the same page identifies take drinks as a short, easy single-arm task, pick and place as a long, easy dual-arm task, and packing hand cream as a long, hard dual-arm task involving a bag and zipper. Read the two rows vertically within each task. Then compare across tasks: only take drinks lowers calls, whereas the two longer tasks increase calls alongside success. This prevents the headline call reduction from being generalized to all three experiments. robotsprotocol
What it supports. Take drinks maintains 90.0% success while calls fall from 32.7 to 23.9, the reported 26.9% reduction. Packing hand cream raises success from 50.0% to 63.3% with calls rising from 49.4 to 57.2. Pick and place also improves success, from 93.3% to 96.7%, while using more calls.
Where the evidence stops. These are three physical tasks with 30 trials each and no uncertainty intervals. The table does not report episode wall time, and its successful-episode call counts omit the cost of failed attempts.
6.2 Results and evaluation conditions
| Task & protocol | Reported result | Comparison & interpretation |
|---|---|---|
| RoboTwin execution trade-off 50 tasks; 100 trials/task in each clean/randomized setting; frozen FastWAM. | Overall clean: 92.86%, 10.36 calls, 188.83 steps; randomized: 91.52%, 10.46 calls, 192.80 steps. SR (%); calls and steps on successful episodes | Baseline-24: clean 91.68%, 8.69, 195.49; randomized 91.24%, 8.76, 197.63. Overall success improves while calls increase. Clean short-task calls fall 5.97→5.51; long-task calls rise 15.02→21.67 and SR rises 86.93→88.47%. This is selective spending, not universal acceleration. robotwinprotocol |
| RoboTwin clean open_microwave Representative task; 100 clean trials. | 83%; 27.55 calls. SR (%); successful-episode calls | Baseline-24: 53%, 19.04 calls; Auto-Horizon: 52%, 35.40; AAC: 45%, 109.4. A 30-percentage-point gain over fixed-24 accompanies additional replanning. AAC calls each contain five action samples. task-resultsprotocol |
| LIBERO four-suite average Standard four suites; 50 trials/task; fixed-10 FastWAM comparison. | 97.25%; 12.46 calls; 144.5 steps. SR (%); successful-episode calls/steps | Baseline: 97.25%, 14.88 calls, 144.5 steps. Average success is preserved, not every suite: spatial falls 97.00→96.60% and goal 97.60→97.40%, offset by Long rising 95.00→95.60%. liberoprotocol |
| Real-robot take drinks Short, easy single-arm task on the robotic platform; 30 trials. | 90.0%; 23.9 calls. SR (%); successful-episode calls | Baseline: 90.0%; 32.7 calls. The reported 26.9% call reduction is specific to take drinks. Pick and place instead improves 93.3→96.7% with calls increasing 64.4→68.7. robotsprotocol |
| Real-robot pack hand cream Long, difficult dual-arm packing task; 30 trials. | 63.3%; 57.2 calls. SR (%); successful-episode calls | Baseline: 50.0%; 49.4 calls. A reported 13.3-percentage-point success gain costs more calls. No uncertainty intervals are supplied. robotsprotocol |
| Motus transfer on move_can_pot RoboTwin clean/random settings; TempoWAM attached without retraining. | 94% clean; 87% random. SR (%) | Motus: 35% clean; 75% random. The clean gain is 59 percentage points. Two transfer tasks are reported; no transfer call counts or feature-interface details accompany Table 4. transfer |
| LIBERO monitor component ablation Full monitor versus training/core variants. | Full: 97.25%, 12.46 calls. SR (%); successful-episode calls | Always teacher forcing: 96.20%, 11.02; never: 96.65%, 12.32; without HCR: 96.65%, 12.39; without smoothness: 96.65%, 12.01; LSTM: 97.10%, 13.10. The regularizers and mixed-history training improve reported success, but several variants use fewer calls; these are not comparisons at matched inference budgets. ablationprotocol |
6.3 Ablations and diagnostic examples
Read component removals and qualitative examples within their stated evaluation conditions.
Table 8. Training the monitor’s feedback loop affects both success and call frequency. Original paper, p. 7 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Take the full model as the reference for every parenthetical change. The teacher-forcing rows alter whether previous progress during training comes from labels or the monitor; the full setting uses probability 0.5. HCR is history-consistency regularization under observation masking, while smoothness matches adjacent predicted progress increments to label increments. These choices matter because AEP thresholds differences between successive predictions. The last row replaces the recurrent core with an LSTM. Read success together with calls: a lower call count after removing a component may mean the monitor tolerates unreliable reuse, rather than that the altered method is more efficient at equal quality. ablationlossesconfigurationratesprotocol
What it supports. Always teacher forcing lowers success by 1.05 percentage points and calls by 1.44. Removing HCR or smoothness each lowers success by 0.60 points. The full model’s 97.25% success is the highest reported here, supporting the training choices within this LIBERO evaluation without isolating a matched-cost advantage.
Where the evidence stops. No seed variation or confidence intervals accompany these small differences. Several ablations change call counts as well as success, and the LSTM also changes model capacity and computation, limiting single-factor causal interpretations.
Figure 6. Normalized time ceases to be useful progress supervision in the mirrored construction. Original paper, p. 8 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Read the horizontal axis as the normalized-time training label and the vertical axis as RPM’s prediction. The dashed red diagonal marks perfect agreement. Blue points instead form a nearly horizontal band across the label range. The accompanying experiment appends a reversed copy to each take-drinks demonstration: the robot appears to complete the task and then undo it, so matching visual states occur at different normalized times. Those occurrences receive labels that sum to one. This plot diagnoses the model trained on that artificial sequence construction; it does not report success of a robot executing a reversed task. aliasingrpmlosses
What it supports. The trained RPM fails to recover a useful progress signal under mirrored supervision. The authors use this result to bound their method to non-repetitive, progress-monotonic tasks, proposing phase decomposition or semantic supervision for periodic and symmetric behavior. It exposes an assumption hidden inside the convenient time-derived labels.
Where the evidence stops. The axes have no numeric ticks and no correlation statistic is supplied. Since RPM also receives time and recurrent history, this failure does not prove that aliased observations make learning impossible for every estimator using the full input.
7. Analysis & limitations
7.1 What the evidence leaves open
The mirrored take-drinks diagnostic fails under time labels. The authors restrict the supported regime to progress-monotonic, non-repetitive observations and propose phase or semantic labels for periodic/symmetric tasks. aliasing
This diagnostic shows a failure of the trained monitor, not impossibility for all recurrent estimators: RPM also receives history and time. The plot has no numeric ticks or reported correlation statistic. aliasingrpm
Success-conditioned calls/steps do not establish total deployment cost including failed episodes. Reported comparisons lack uncertainty intervals; small success differences and three physical tasks do not establish broad generalization. protocolliberorobotsablation
7.2 Questions for discussion
- Would adaptive timing still improve success when fixed and adaptive policies have matched total compute budgets, including failures?
- Can phase-aware supervision recover progress estimation on aliased tasks without relying on episode time?
8. Reproducibility audit
8.1 Requirements and known gaps
Reproduction needs frozen WAM checkpoints/features and their demonstrations. Settings include calibration EMA 0.5, initial inter-episode multiplier 0.8, success target 0.95, update rate 0.05 and bounds [0.4,1.0]; simulation uses NVIDIA H20. protocolconfiguration
Table 6 reports per-call latency 181.23→42.31 ms on Thor and 62.15→20.36 ms on RTX 4090 with platform-specific optimizations. RPM is 3.54% of an optimized call with encoding, 0.34% with shared features. These are per-query costs, not end-to-end episode speedups. latency
The supplied method/configuration does not specify optimizer, learning rate, batch size, window length, precise candidate-to-training-label alignment, rejected-candidate state handling or success-EMA coefficient. The no-demonstration fallback initializes calibration at one but leaves average duration acquisition unexplained. Resolve these before claiming exact replication. rpmratescalibrationlossesconfiguration
8.2 Proposed reproduction checks
The following checks are proposals motivated by the paper. They have not been run as part of this reading.
Check 1: Does adaptive timing help at matched computation?
Reader-proposed check, not performed: hold the FastWAM checkpoint, trained RPM, initial task states and trial seeds fixed for open_microwave and click_bell. Compare fixed horizons with offline-only, within-episode and full two-timescale calibration. Reset adaptation consistently between independent runs and record trial order because the full controller carries success information across episodes. Sweep horizons or calibration multipliers to compare success at similar total inference time. Include failed episodes and RPM latency, while separately reproducing the paper’s successful-episode call metric. A timing advantage predicts improved success at matched cost, concentrated around difficult stages. If the advantage disappears after cost matching, the evidence instead favors additional computation or a shifted operating point. calibrationconfigurationprotocoltask-resultsbehaviorlatencyadaptation-diagnostic
Check 2: Can history or phase labels resolve the mirrored diagnostic?
Reader-proposed check, not performed: rebuild the original-plus-reversed take-drinks construction and split by original demonstration before mirroring, preventing paired sequences from crossing train and test. Compare the stated RPM with a time-only control and an RPM without the position input, using the same training budget and held-out trajectories. Then replace global time labels with the phase supervision suggested by the authors, keeping the model fixed. Measure prediction error and correlation separately on forward and reversed segments; do not infer robot success from those metrics. If the recurrent model fits global labels on held-out mirrored sequences, aliasing alone is insufficient to explain the reported failure. If phase labels rescue performance, that supports the proposed supervision remedy. rpmlossesconfigurationaliasing
8.3 Reading coverage
Visual audit: All nine supplied PDF pages were rendered and visually inspected, including the title/authors/version on page 1, Figure 2 on page 2, method equations on pages 3–4, training and evaluation details on pages 4–5, Tables 1–8, Figures 1–6, physical-task definitions and latency on page 6, and the diagnostic and discussion on pages 7–8. References continue through page 9; no appendix is present. All six final original crops were individually viewed and retain their scientific labels and legends. The Figure 2 branches were cross-checked with its caption and Eq. (11); Figure 4 threshold semantics follow that equation without inferring unmarked ratio values. The prospective-versus-observed terminology difference is disclosed in the architecture caution. No source pages remain outside this visual pass; separate supplements were not supplied.
PDF pages inspected for this edition: 1, 2, 3, 4, 5, 6, 7, 8, 9. Appendix coverage: not present.
Original figures and tables remain the work of the source’s authors. Extractions preserve their scientific content; any HTML wrapper layout is disclosed with each figure. The surrounding reading notes are our own.
Text reading scope & known omissions
- Abstract and 1 Introduction (p. 1–2)
- 2 Related Work (p. 2–3)
- 3 Method, including 3.1–3.5 and Eqs. (1)–(15) (p. 3–4)
- 4 Experiments, including 4.1–4.4 and time-label diagnostic (p. 4–8)
- 5 Conclusion (p. 8)
- References (p. 8–9)
Outside the original text pass
- Text extraction does not reconstruct figure images; inspect the retained PDF for figures and equation/table layout.
- Separate supplemental material availability has not been fully verified.
- Identity: the inspected title and all eight authors match the catalog after name-order normalization. The supplied edition is arXiv:2608.09492v1, 10 Aug 2026; no title/author revision discrepancy was observed, and no other edition was supplied or compared.
- The extraction does not reconstruct figure images; all nine original PDF pages and Figures 1–6/Tables 1–8 were therefore visually inspected separately.
- No appendix is present in the nine-page PDF. Separate supplemental material availability has not been fully verified; no supplement was supplied.
- Code was not inspected and experiments were not reproduced.
The visual audit above records the subsequent illustrated pass.
8.4 Traceable evidence
identityPDF p. 1, title/author block and arXiv margin
The title matches the catalog; the eight authors are Feng Ye, Yiming Zhao, Yong Yu, Hongxu Zhou, Yong Pan, Yuan Xue, Peng Jia and Chuanmin Jia. The artifact states arXiv:2608.09492v1, 10 Aug 2026, with Peking University and Simplexity Robotics affiliations.
Go to primary source ↓motivationPDF p. 1, Abstract, Section 1 and Figure 1
The Click Bell illustration contrasts stage-dependent action error and inference cost under fixed horizons. The proposed execution layer monitors task progress to decide when to reuse or discard actions.
Go to primary source ↓executionPDF p. 2, Figure 2 and caption, and Section 2, Adaptive execution; p. 3, Sections 3.1–3.2, Eq. (1)
A frozen WAM supplies action chunks. The first n_p actions execute unconditionally, followed by candidate prefixes of min(n_p, remaining length); failed progress checks discard the remainder and trigger replanning. Exhaustion also triggers a fresh chunk. The execution scheme does not require test-time future imagination.
Go to primary source ↓rpmPDF p. 3, Section 3.3, Eqs. (2)–(5)
RPM predicts progress after a candidate prefix from the observation, candidate actions, length, prior progress, decision index and instruction. Frozen visual features, recurrent action encoding, a learned history projection/start token and position embedding feed a GRU and sigmoid prediction head.
Go to primary source ↓ratesPDF p. 3, Section 3.4, Eqs. (6)–(7)
The progress difference is divided by candidate length, then compared with a required rate based on remaining progress, average demonstration duration, elapsed steps and a 0.2/average-duration floor.
Go to primary source ↓calibrationPDF p. 4, Section 3.4, Eqs. (8)–(11)
Episode least-squares calibration factors are aggregated by median. Within-episode EMA updates kappa from raw ratios; a clipped inter-episode factor responds to an EMA of success. Continue at calibrated ratio at least one, otherwise replan. Without demonstrations kappa starts at one.
Go to primary source ↓lossesPDF p. 4, Section 3.5, Eqs. (12)–(15)
Training uses the backbone demonstrations with normalized-time labels, padded-step masks, soft-label BCE, an absolute error on adjacent progress increments, and squared consistency between original and observation-masked predictions.
Go to primary source ↓protocolPDF p. 5, Section 4.1, Benchmarks and backbone, Baselines and Metrics
Frozen FastWAM is evaluated on 50 RoboTwin tasks in clean/randomized settings with 100 trials per task and four LIBERO suites with 50 trials per task. Fixed horizons are 24/12 and 10 respectively. Calls and steps describe successful episodes; AAC counts five samples in one decision as one call.
Go to primary source ↓configurationPDF p. 5, Section 4.1, Implementation details
The 2.27M-parameter monitor uses GRU core/action encoder and two-layer MLPs; training lasts 20 epochs with p_tf=0.5, p_hcr=0.3, smoothness weight 0.1 and HCR weight 0.05. Prefix sizes are 10 in simulation and 4 on robots. Calibration uses lambda=0.5, initial delta prime 0.8, target success 0.95, eta=0.05 and bounds [0.4,1.0]. Simulation hardware is NVIDIA H20.
Go to primary source ↓robotwinPDF p. 4, Table 1, Short/Long/Overall rows, Clean and Random columns; p. 5, Section 4.2, Results on RoboTwin
There are 35 short and 15 long tasks, grouped by baseline calls below ten versus the rest. TempoWAM reduces short-task calls and raises long-task calls while improving aggregate success. Overall clean SR/calls/steps are 92.86/10.36/188.83 versus 91.68/8.69/195.49; random values are 91.52/10.46/192.80 versus 91.24/8.76/197.63.
Go to primary source ↓task-resultsPDF p. 5, Table 2, open_microwave, turn_switch, click_bell and press_stapler rows; p. 6, Section 4.2, Task-level analysis
On clean open_microwave, TempoWAM reports 83% success and 27.55 calls versus Baseline-24 at 53% and 19.04, Auto-Horizon at 52% and 35.40, and AAC at 45% and 109.4. Clean click_bell retains 100% success while calls fall from 3.00 to 2.04.
Go to primary source ↓liberoPDF p. 5, Table 3, all suite rows and Average row
Average SR stays 97.25% while calls fall from 14.88 to 12.46 and steps stay 144.5. LIBERO-Long/libero_10 SR changes 95.00 to 95.60; spatial 97.00 to 96.60; object remains 99.40; goal 97.60 to 97.40. Auto-Horizon averages 95.80%/20.89 calls and AAC 97.05%/20.54.
Go to primary source ↓transferPDF p. 5, Table 4; p. 6, Section 4.2, Cross-backbone generalization
Attaching TempoWAM to Motus without retraining raises clean/random success from 35/75 to 94/87 on move_can_pot and from 61/60 to 93/86 on place_mouse_pad. Motus normally executes its full 16-step chunk, so the authors attribute gains to earlier replanning.
Go to primary source ↓robotsPDF p. 6, Figure 3, Table 5 and Section 4.3, Real-World Experiments and Results
Three physical tasks use 30 trials each. Take drinks changes from 90.0%/32.7 calls to 90.0%/23.9; pick and place from 93.3%/64.4 to 96.7%/68.7; pack hand cream from 50.0%/49.4 to 63.3%/57.2. Figure 3 shows single-arm take drinks and dual-arm basket/shelf and bag-packing tasks.
Go to primary source ↓latencyPDF p. 6, Table 6 and Section 4.3, Deployment cost
Reported WAM latency changes from 181.23 to 42.31 ms on Thor and from 62.15 to 20.36 ms on RTX 4090 under platform-specific optimization stacks. RPM costs are listed as 3.54% of one optimized call with visual encoding and 0.34% with shared features, without separate platform columns for those percentages.
Go to primary source ↓behaviorPDF p. 7, Figure 4 and Section 4.4, Adaptive execution behavior; p. 4, Eq. (11)
Selected episode timelines show below-threshold discard/replan events during the difficult microwave stage, versus continued reuse on press_stapler. The figure distinguishes replan on discard from replan on exhaustion; the equation specifies continue for r_t >= 1.
Go to primary source ↓adaptation-diagnosticPDF p. 7, Figure 5, Table 7 and Section 4.4, Online calibration behavior / Success-gated adaptation
Figure 5 disables the inter-episode update and plots successful microwave episodes, showing offline starting kappa and higher episode means. Table 7 reports final delta prime 0.68 for click_bell/alarmclock, 0.98 for turn_switch and 0.94 for open_microwave, starting from 0.8.
Go to primary source ↓ablationPDF p. 7, Table 8 and Training Loss Ablations; p. 8, continuation before When Are Time-Based Progress Labels Valid?
LIBERO full model is 97.25%/12.46 calls. Always/never teacher forcing gives 96.20%/11.02 and 96.65%/12.32. Removing HCR or smoothness gives 96.65% with 12.39 or 12.01 calls. LSTM gives 97.10%/13.10. The authors explain probabilistic teacher forcing as balancing training stability and exposure to predicted history.
Go to primary source ↓aliasingPDF p. 8, Figure 6, When Are Time-Based Progress Labels Valid? and Section 5
The take-drinks diagnostic concatenates a demonstration with its time reversal and trains on normalized-time labels. Predictions are uncorrelated with the labels. The authors identify non-repetitive progress-monotonic observations as the supported regime and leave phase decomposition/semantic progress labels to future work; the plot provides no numeric ticks or correlation statistic.
Go to primary source ↓8.5 Primary sources
Rethink Before You Execute: Adaptive Execution for World Action Models ↗
PDF · 4,757 extracted words
Source fingerprint
c286fa2219e6646fe0ea66cf44f243719be22ec2872b8476f55adc0e8f4ed066