Task Horizon: Why Long Tasks Get Exponentially Harder

Suppose your policy succeeds ninety-five times out of a hundred on a single step. That sounds like a robot you could ship. Now chain thirty of those steps into one task, unloading a dishwasher, say, and multiply: 0.95 raised to the thirtieth power is about 0.21. The same reliable robot now finishes the whole job barely one time in five.

That collapse is the task-horizon problem, and it explains why a polished ten-second clip rarely survives a three-minute chore. Nothing about the robot got worse. The arithmetic did the damage.

The arithmetic of the horizon

If the steps are independent, whole-task success is the product of the per-step success rates, and multiplication is unforgiving. Take a stronger robot, 99% reliable on every step. Over a hundred steps, 0.99 to the hundredth power is roughly 0.37. Even near-perfect single steps decay to a coin flip and worse once the horizon grows long enough. There is no invented statistic here, only the multiplication laid out in the open. The longer the task, the steeper the exponential fall.

This is why a demo reel can lie without a single fake frame. A ten-second grasp shown once, cut clean, tells you almost nothing about a robot asked to run the same skill four hundred times in a shift.

Horizon is not only about counting steps. A longer task usually visits more distinct situations, holds more state in its head, and gives the world more chances to move while the robot is mid-motion. Each of those raises the odds that some step lands outside what training covered. So the raw step count understates the difficulty. The honest horizon is the number of independent things that can go wrong, and that grows faster than the steps do.

Why it is worse than the multiplication suggests

Independence is the charitable assumption. In reality, one small error nudges the robot into states it never saw during training, which is covariate shift. Once it is in unfamiliar territory, the per-step success rate itself drops, so the errors are correlated and self-amplifying rather than independent. A single early stumble can doom everything after it. This is why long-horizon reliability keeps showing up as a central research problem, from the NVIDIA GEAR Lab research to the steady stream of work on arXiv Robotics, rather than a rough edge you can patch after the fact.

Humans hide this problem from themselves. In a lab, an operator quietly nudges an object back into reach, rights a fallen part, or restarts a run that went sideways, and none of it shows up in the highlight clip. The robot on a real floor gets no such help. Every recovery it needs, it must have already learned, which means someone had to capture that recovery as data in the first place.

Ways to shorten the effective horizon

If length is the enemy, most practical fixes share one idea: cut the number of decisions the robot must get right on its own.

Action chunking is the clearest case. Methods like ACT and diffusion policy predict a short burst of actions at once instead of one step at a time, which shrinks the count of independent decisions per task and shortens the multiplication chain. The long-horizon manipulation shown on the Physical Intelligence blog leans heavily on this: package the decisions, and train the model to recover when one goes wrong.

None of these fixes is free, and each trades one hard problem for another. Break a task into skill primitives and you inherit the transition problem: the seams between skills become the new failure sites, and they need their own data to smooth over. Chunk the actions and you trade away reactivity, because a policy committed to the next half-second responds more slowly to a surprise. The horizon does not vanish. It gets redistributed, and the redistribution is only as good as the data behind each piece.

What the data must carry

Each strategy pushes its cost onto the data. Hierarchy needs start-and-end boundaries for every sub-skill. Chunking needs high-frequency action labels that stay aligned to observation. Recovery needs you to deliberately capture failures and the crawl back out of them, not just clean successes. That is exactly where pure success demos mislead: they never show how to recover from an error, and recovery is the skill a long task needs most. Cross-embodiment corpora like Open X-Embodiment help partly because they cover enough varied situations that a policy has seen what to do after it drifts off the ideal path.

This is also why short benchmarks flatter policies. A test that measures single grasps or ten-second tasks sits in the forgiving part of the curve, where per-step reliability barely compounds. Move to a three-minute task and the same policy that scored 90% on the benchmark can slide below 40% on the job. If an evaluation never stresses the horizon, it is measuring the easy question and quietly skipping the one that deployment actually asks.

Short tasks forgive mistakes; long tasks multiply them. Cutting the decisions a robot must get right alone tends to beat collecting ten thousand more demonstrations.

Treat length as the first constraint

Asking how long a task is often teaches you more than asking how much data you need. Halve the effective horizon and the exponential curve you are fighting turns far gentler, and the tools that halve it are almost always structure and data together, not a bigger model on its own. A long task does not shrink because you trained longer. It shrinks because you broke it into pieces, chunked the decisions, and backed it with recovery data. Whoever takes that seriously is likelier to turn a lab demonstration into a real shift on a factory floor.