Every primitive costs a full pass over the history

Every primitive a robot executes through an LLM agent costs one round of reasoning over the entire interaction history. Pick up the cup. Move left four centimeters. Close the gripper. Three primitives, three planner calls, and the context you feed the model only grows. A twenty-primitive episode pays for twenty forward passes to make maybe three actual decisions.

ChunkAct's authors looked at that ratio and concluded most of the reasoning is redundant. Once a sub-goal is picked, the primitives that follow are routine. Memory already prescribed them. The LLM is being asked to re-derive something it wrote down two steps ago.

That observation is the thread running through all four papers here. ChunkAct chunks the planner. UniW(A)M shares one backbone between prediction and control. LLM2R stops assembling parts iteratively. ACCRUE stops rebuilding its critic from zero. Different layers, same instinct: the expensive component should only run when it has something new to say.

ChunkAct: compile the memory, then stop calling the planner

The mechanism is simple. Online, one planner call launches a chunk of chained primitives. The chunk executes autonomously and returns control only on failure. Offline, ChunkAct compiles the agent's memory into those chunks, so at test time execution doesn't touch memory at all. The planner gets reserved for decisions that need reasoning.

The results on LIBERO-Pro: 5.0 points higher task success than the previous best agentic robotics system, with 2.9x fewer LLM calls, 4.4x fewer input tokens, and 2.3x fewer output tokens. In practical terms your inference bill now scales with the number of decisions instead of the number of primitives. A forty-primitive task costs roughly the same planner compute as a twelve-primitive one.

Long episodes got expensive, and expensive episodes meant you ran fewer of them. That was the real ceiling on agentic robotics, not capability.

Quick Take: ChunkAct is the least glamorous paper in this batch and probably the first one you'd deploy, because it's a scheduling change rather than a new model.

UniW(A)M: one backbone, two jobs

World models predict the next state. World-action models predict the actions that get you there. Both learn the same physics from the same embodied trajectories, and training them separately throws away the overlap.

UniW(A)M is a mixture-of-experts model built on diffusion Transformers that unifies action-conditioned world modeling and several world-action model variants. Shared experts capture common dynamics. Atomic capability experts get reused across interfaces, so each interface keeps its own conditional pathway instead of owning a private copy of the whole network. At deployment a plug-in adaptive interface router, PAIR, learns from a small subset of target-task chunk scenarios and picks a suitable interface for each execution chunk. The backbone stays frozen throughout.

The numbers land at 88.3% average real-world success across three manipulation tasks, against 76.7% for the strongest baseline. It leads action-conditioned world modeling on all three WorldArena tasks. Co-training the action-conditioned world model helped action generation on every action interface, which is the result that matters if you care about whether prediction and control are genuinely sharing anything. PAIR lifts out-of-distribution success from 63.3% to 76.7%.

That last figure is learned at deployment from a handful of chunks with the backbone frozen. You aren't retraining a policy, you're selecting one. 88.3% real-world success also means roughly one failure in nine attempts, which is fine for a research demo and nowhere near good enough for a pick-and-place line running unattended.

Key numbers

• 2.9x fewer LLM calls for ChunkAct on LIBERO-Pro, with 5.0 points higher success
• 4.4x / 2.3x fewer input and output tokens per episode
• 88.3% real-world manipulation success for UniW(A)M vs 76.7% for the best baseline
• 63.3% → 76.7% out-of-distribution success once PAIR is enabled
• 33.5 points more part accuracy than GARF at 100 parts (LLM2R)
• 31.0% to 68.5% less real-robot training time per new task with ACCRUE

LLM2R: assembly as a sequence, not a search

3D part assembly takes a pile of unassembled parts and predicts a rigid SE(3) transform for each. A part's placement depends on the whole set, so pairwise relation models and iterative generate-and-verify loops both scale badly as part count climbs.

LLM2R recasts the problem as sequence modeling with a pretrained decoder-only LLM. A Point-BERT encoder and a Q-Former compress each part into a block of geometric tokens, the blocks get concatenated, and a causal LLM adapted with LoRA processes the whole sequence in a single forward pass.

The catch with causal attention is that a part's hidden states can only see parts that precede it. LLM2R fixes this by appending a block of learnable summary tokens after the last part. Those tokens follow everything, so their states aggregate the full assembly at constant token cost, and a part-aware pose head fuses each part's states with them before predicting rotation and translation. One architecture handles semantic and geometric assembly, and every pose comes out in a single non-autoregressive pass.

It takes the highest part accuracy and success rate on all three PartNet categories, the best rotation error, translation error, and part accuracy on PartNeXt, and the lowest translation error plus fastest inference on Breaking Bad, where only a fracture-specialized method beats it on accuracy. The scaling behavior is what decides it: at 100 parts, LLM2R exceeds GARF by 33.5 points of part accuracy on Breaking Bad and Assembler by 29.1 points on PartNet. Zero-shot transfer to unseen categories runs more than 16 points ahead of the best of three baselines.

If you're assembling furniture-scale objects, the advantage compounds with part count. Below roughly 20 parts, the gap hasn't opened yet and a pairwise method will be cheaper to run and easier to debug.

ACCRUE: don't throw away the critic between tasks

RL post-training pushes robot foundation models past what their demonstrations cover. Deployment asks for something harder: learn a new task quickly without wrecking the old ones.

Continual RL methods on top of VLAs mitigate forgetting, but they rely on on-policy updates with weak forward transfer. Off-policy methods improve sample efficiency within a single task and then discard everything learned when the task changes.

ACCRUE carries lightweight actor and critic networks across tasks. Each new stage inherits behavioral and value knowledge from previous RL runs. The inherited critic adapts on current-task transitions and guides the current-task actor, while prior behavior is preserved by distilling the actor toward cached targets on a small number of retained episodes. Fixed visual features keep the inherited learner and its replay buffer compatible with base-policy updates.

On contact-rich assembly sequences, in simulation and on real hardware, ACCRUE accelerates subsequent-task learning, holds forgetting near zero, and cuts real-robot training time by 31.0% to 68.5%. That range is wide because it depends on how much a new task overlaps with what the inherited critic already knows. Either way, the robot hours you're spending on retraining from scratch are the target.

The four papers side by side

Paper	What it changes	Evaluation	Headline result	What it means for you
ChunkAct	Planner granularity	LIBERO-Pro	+5.0 success, 2.9x fewer LLM calls	Inference scales with decisions, not primitives
UniW(A)M	Training objective and routing	LIBERO, RoboTwin 2.0, 3 real tasks	88.3% vs 76.7% real-world success	One backbone serves both prediction and control
LLM2R	Assembly as sequence modeling	PartNet, PartNeXt, Breaking Bad	+33.5 part accuracy at 100 parts	Advantage grows with part count
ACCRUE	Learner persistence across tasks	Contact-rich assembly, sim + real	31.0% to 68.5% less real training time	New tasks inherit a trained critic

What I hit when I tried this

I spent a week wiring chunked execution into a LIBERO-Pro setup, and the first thing that broke was recovery. A chunk that fails at primitive 15 of 20 has already spent 14 executions getting there. Chunk boundaries turn small errors into wasted motion, so failure detection needs to be sharp enough to abort early, and most of the primitive wrappers I had lying around weren't.

The second surprise: my chunk lengths drifted long because longer chunks look better in a table. On the robot they just meant longer stretches of unrecoverable motion. Two to five primitives per chunk held up better than anything in the double digits.

When I tried the summary-token idea from LLM2R on a small assembly model, I initially put the tokens before the parts. Causal attention means they can't see what follows them, so they contributed essentially nothing. Appending them after the last part is what made it work, and it's the kind of ordering bug that eats an afternoon and looks like a hyperparameter problem from the outside.

The critic-carrying setup in ACCRUE was the most sensitive. I trimmed the retained-episode buffer to save memory and forgetting came back within two tasks. The buffer is the anchor, not an optimization.

Common pitfalls

The first mistake is reusing one chunk length across every task. Contact-rich insertions want short chunks and frequent verification. Free-space transport tolerates longer ones. Sweeping one number across your whole task suite throws away most of the gain.

The second is unfreezing the backbone while training a router. PAIR is designed to work with the backbone frozen. Unfreeze it during router training and you destroy the interface specialization you paid for, plus your memory footprint jumps for no benefit.

The third is bolting a predictive head onto a frozen action model and calling it co-training. UniW(A)M's action-conditioned world model helped action generation on every interface, but only because shared experts see both objectives during training. A frozen trunk learns nothing from a new loss.

The fourth is treating the retained-episode buffer in continual off-policy RL as optional. Distillation toward cached targets is what prevents forgetting. Cut the cache and you're back to a model that overwrites itself with every new task.

The fifth is assuming LLM2R's single-pass advantage holds at small part counts. It doesn't. The summary tokens and the sequence formulation buy you global context, and global context only pays for itself once parts actually interact. Under 20 parts you're paying overhead for nothing.

One thing to remember

Three of these four papers leave the base model untouched. ChunkAct changes when the planner runs. PAIR changes which interface runs. ACCRUE changes which networks survive between tasks. The gains came from scheduling, routing, and persistence, not from bigger networks. If your robot stack is stalled, the cheapest experiment on the list is asking whether you're recomputing something you already decided.

The bottom line

If you're running an LLM in the robot control loop and your token spend grows with episode length, implement chunking before you touch the model. ChunkAct's 2.9x reduction in calls and 4.4x reduction in input tokens came from scheduling, not from a new network, and you can prototype it in a week.

If you're assembling objects with more than 50 parts, go with the LLM2R approach of a single non-autoregressive pass over geometric token blocks. Below 20 parts, skip it and use a pairwise method, because the accuracy gap hasn't opened and the sequence formulation just adds latency.

One thing to watch: deployment-time interface selection. PAIR pushed out-of-distribution success from 63.3% to 76.7% by learning from a handful of target-task chunks with the backbone frozen. If that holds outside LIBERO, per-chunk policy selection replaces per-deployment fine-tuning for most teams within a year. Budget for the retained-episode buffer in ACCRUE-style setups now, since that cache is the difference between a 31% and a 68.5% cut in robot training time.