A robot policy carries far more context than it acts on — views it never consults, frames that repeat what the last one showed, geometry behind the gripper. Compress that context with a tool built for language model serving and the benchmark stays green while the motion falls apart: 3.75× the jerk at 78% visual token pruning, with the success rate intact. We compress the context a policy actually carries, in whatever modality it arrives, and hold the motion fixed — the same trajectory for fewer joules per task.
What generic compression costs
Published literature, not our results. The context and model figures are §IV of From Inference Efficiency to Embodied Efficiency (arXiv:2603.19131); the energy ratio is Decoupling Vision, Language, and Action (arXiv:2609.18374).
Why it cannot be borrowed
Robot deployment has structure that language model serving does not. Every one of these is compute a generic compressor leaves on the table.
Views overlap. Consecutive frames are nearly identical. Most of a depth cloud sits behind the gripper or on empty floor. Consecutive text tokens are none of these things, so nothing built for language serving knows which of them to drop.
One forward pass yields many timesteps of output. No language model has that output shape, so nothing built for one knows how to compress against it.
The next chunk has to be ready before the current one finishes playing, or the arm stutters at the seam. That is a hard deadline on a one-second budget, not a throughput target, and on an AGX Orin a frontier policy already spends most of it.
A two-millimetre grasp and a traverse across empty floor should not get the same compute or the same precision. The requirement varies by orders of magnitude inside one episode.
Joules per task, jerk, path length, completion time. Not throughput. Compute and actuation sit in the same order of magnitude — 22 W of servos against a 20 W Orin NX — so what the chip saves and what the motors spend land on one bill.
End to end
One control step, from camera to motor. Five of the seven steps carry waste that a generic tool cannot see, and each gets its own cut. The last step is where we check that none of the saving came back as worse motion.
Cameras and a depth sensor capture what is in front of the robot. The joints report where the arm is.
Raw sensor data. The waste starts once it is turned into tokens for the model.
Each camera view becomes a grid of image tokens, and the depth cloud becomes 3D tokens, so the policy knows where the cup, the shelf and the gripper are.
Keep only the views and points the policy actually consults. Overlapping views, empty table and far walls are dropped before the encoder sees them.
Where the policy carries history, recent frames are stacked so it can tell what is moving and how far the task has got.
Drop frames that repeat what the last one already showed, keyed to the current task phase.
A vision encoder turns pixels into features the rest of the model can reason over.
The encoder was sized for captioning photos. Remove the blocks control does not need, and distil what is left.
The backbone combines what the robot sees with the instruction and its own state.
Narrow each layer and lower its precision, checked against the motion it produces rather than a text benchmark.
The action head turns noise into a chunk of future joint targets, several timesteps from a single pass.
Distil the denoising loop into a short-step action expert that produces the same motion.
The controller plays the chunk out on the motors and the arm moves. This is where the battery is actually spent.
Joules per task, jerk, path length and completion time. A cut upstream only counts if these hold.
Back to step 1 with a new observation. The controller plays the chunk out at 50 Hz while the policy replans underneath it — roughly once a second on an AGX Orin, and it has to finish before the chunk does.
The stack
Context compression and model compression are different problems. Context is modality-agnostic — whatever a policy carries, views, frames, geometry or state, most of it is never consulted, and a token dropped upstream is a token the backbone never attends over. Model compression is per-stage, and it is where vendor toolchains start and stop. Stages 01–03 are context, 04–06 are model, and both are cut against a single budget measured in what the robot physically spends. There is no runtime to adopt and nothing to integrate: what comes back is a checkpoint.
| Stage | What is wasted | Robot-specific lever | Status |
|---|---|---|---|
| 01Views | Overlapping views, image tokens the policy never consults | Context pruning across the views a policy carries | Built |
| 02History | Frames that repeat what the last one already showed | Temporal context pruning, keyed to the task phase | Built |
| 03Geometry | Dense point clouds the policy never consults | 3D context pruning on the geometric tokens | Built |
| 04Encoder | A vision tower sized for captioning, not for control | Depth and width reduction distilled into the encoder | In progress |
| 05Backbone | Full precision and full width at all times | Motion-preserving pruning, quantization, distillation | In progress |
| 06Action head | Denoising steps the task does not need | Flow distillation into a short-step action expert | Next |
Where the saving comes from
Generic compression cuts the same amount everywhere, context and model alike. The policy moves worse, the episode runs long, and the motors spend what the chip saved. We cut where the task allows it and hold the motion fixed, so the saving survives all the way to the battery.
Static geometry and repeat frames are dropped before the encoder sees them, so a traverse across empty floor costs a fraction of a grasp.
Depth and precision go where millimetres matter. The action head runs two denoising steps, not eight.
Jerk, path length and completion time are held to the uncompressed policy while we cut, so nothing the chip saves is handed back to the motors.
The metric
We report what the robot spends, not what the chip reports. Energy per completed task, jerk, path length, completion time and success rate measured together, because compression that improves one by wrecking another is not a gain. It is a transfer.
No published benchmark puts actuator energy and compute energy in the same table. The spread between policies doing identical work is already six to fifteen times, and most of that gap came from architecture rather than any quantizer. Measuring it is how we know which cut to make, and it is the part nobody else is doing.
Energy per action-chunk call
Derived from the 6–15× range reported for the decoupled policy · estimated, single workstation · arXiv:2609.18374
Research
The methods are ours. The compiler that composes them, and the measurement data behind the allocation, are the product.
Cutting the geometric context a manipulation policy carries, without disturbing the motion it produces.
Exploiting temporal redundancy in the observation stream, keyed to what the current task phase actually requires.
Who we work with
A robot priced under ten thousand dollars cannot put a flagship inference module in its bill of materials and hold a margin. Compute is the line item that has to come down.
Vendor toolchains optimize vendor hardware. If the robot ships on anything else there is no toolchain, and no one measuring what compression did to the motion.
Every task that falls back to a human operator is labor on the balance sheet. Autonomy that fits onboard is margin recovered.
Contact
We will tell you what it costs today in joules, jerk and path length, and what it costs after.