Cost per Capability

When a device costs thirty dollars, every part in it has to justify itself. This post is about the number we optimize for: cost per capability, the usefulness a device delivers per dollar of hardware.

The bill of materials is the product

Open up an affordable robot toy and you will find a few dollars of plastic, a geared motor, a small battery, and a chip that costs less than lunch. None of those parts are precision instruments. The camera is noisy, the motor has play in it, and the chip has a few hundred kilobytes of memory to work with.

The usual fix is better parts. A sharper camera, tighter motors, a faster chip. Each one is defensible on its own, and together they push the toy past the price where most families will ever buy it. Great devices get built this way, but they end up in a small number of homes.

Our fix is software. A model can learn what a device's parts actually do, slop and noise included, and compensate for them. It can sharpen a cheap camera's output, absorb a motor's backlash, and pick behaviors that stay inside what the hardware can manage. The bill of materials stays small. The intelligence does the heavy lifting.

What the constraint buys

Designing for cheap hardware sounds like a limitation. In practice it is a filter that makes the product better.

It forces honesty about features. If a capability has to fit in a few hundred kilobytes, you learn quickly which ones matter to the person using the device and which ones were only there for the spec sheet.

It forces robustness. Parts from a low-cost supply chain vary from unit to unit. Software that adapts to each device as built, not as designed, survives that variance.

And it keeps the customer's math simple. A thirty dollar device either does something worth thirty dollars every day, or it ends up in a drawer. Cost per capability is that judgment, applied before the product ships instead of after.

How we build for it

In practice, we train large models on data from real devices, then shrink them until they fit the chip the product can afford. Distillation, quantization, and pruning are not afterthoughts; they shape what we train in the first place.

We also measure capabilities the way a customer would: how often the robot actually completes the task on a table in someone's home, not its score on a benchmark dataset.

The goal is a device that behaves like it costs ten times its price. That is the standard we hold our work to. If engineering under that kind of constraint sounds like fun, take a look at our open roles.