Dream Labs Raises $90M and Opens Dream-1 Robot Control API

How Dream-1 Changes the Robot Software Purchase

A robot policy connects what a machine observes to what it does next. Buying that capability through an API changes who has to train, host and update the model. A hardware developer can concentrate on the body and its interface, while the model provider sells recurring access to control intelligence. The customer's remaining work is integration, testing and deciding when the system is dependable enough to use.

Dream Labs' product site describes a simple interface: supply camera images, the robot's state and a task, then receive actions. Its playground separates real robots in the company's lab from simulation. A browser visitor can therefore examine behavior without buying a machine, although a successful lab interaction says little about that visitor's own hardware or workspace. Public access makes scrutiny easier; it does not remove the need for evaluation.

The distinction matters for humanoid robotics because useful manipulation is often a separate engineering problem from walking. A model that transfers between two-arm systems could reduce repeated software work across robot bodies. It still leaves locomotion, balance, whole-body coordination and safe operation around people to be demonstrated for the relevant product.

Under the Hood: A Shared Target for Different Arms

Dream Labs' technical account describes a World Action Model, which predicts visual futures and actions together. For transfer to unfamiliar robots, Dream-1 can specify end-effector poses: where each gripper should finish and whether it should open or close. The robot's inverse-kinematics solver translates those targets into joint movements. Zero-shot, in this context, means transfer without collecting training demonstrations from that particular robot; it does not mean the underlying model learned without data.

That separation is useful but consequential. A desired gripper position is not a complete specification of the path an arm takes. The quality of the local solver and the robot's reachable workspace still affect the outcome. Dream Labs explicitly identifies those limits and labels Dream-1 a research beta that has not been validated for safety-critical use.

Public API access also differs from downloading a policy and running it locally. A hosted service can make the model easier to start using, but reproducibility requires recording the model version, robot configuration and evaluation conditions. Otherwise, a result obtained before a service update may be difficult to compare with one obtained afterward. For a physical system, the useful unit of comparison is the entire working setup, including the cameras, grippers and controller.

There is relevant precedent in the Universal Manipulation Interface, a 2024 research system from Stanford, Columbia and Toyota Research Institute researchers. UMI used hand-held grippers and a carefully designed observation/action interface to transfer learned policies across robot platforms. Its experiments also examined latency matching and coordination between grippers. The broader lesson is that a shared interface can make transfer possible, while details of timing and physical geometry remain part of the control problem.

What the Independent Benchmark Measures

Robocurve's current leaderboard reports the following results on RoboDojo-RC Tier 1. Its comparison uses 120 task attempts per configuration. The caps differ: 40 model calls for language models and 3,600 control steps for the robot policies. These figures describe this evaluation setup, rather than a universal ranking of robot intelligence.

A 59.3% mean score is not a 59.3% task-completion rate. Robocurve's published protocol uses I2RT YAM arms and awards partial credit for observable progress, using human graders and task-specific rubrics. Tier 1 comprises six relatively easy tasks selected after testing an earlier model on a larger set. Tasks include stacking bowls, capping a pen and putting objects in a safe. This is useful evidence of manipulation capability within a bounded test, with a substantial distance remaining between partial progress and a completed workflow.

Dream Labs: The Company Behind the API

B Capital led the announced seed round along with Kindred Ventures. The disclosed participants include A.Capital, Unusual Ventures, SV Angel, Wing VC, Scribble VC and Adrian Aoun. Dream Labs says it will spend the new capital primarily on compute as it broadens the tasks, robots and user base the service supports. The announcement does not supply a valuation, revenue figure or fleet-wide operating record.

CEO and co-founder Joel Jang and the founding team come from NVIDIA robotics research. The company's team page connects the new business to DreamZero. That history helps explain its emphasis on video-based world models, but the commercial service must earn its own reliability record. A research team's previous result and an investor's confidence address different questions from whether a customer can complete repeated work at an acceptable cost.

The financing release reports more than 20 hardware partners and supported machines costing roughly $2,000 to $10,000. MakerMods CEO Ryan Chan describes its robot beginning to attempt previously unprogrammed tasks within minutes. That is a named partner's launch testimony, rather than independently measured uptime or evidence that a factory has purchased a complete autonomous workflow.

What This Means for Robot Economics

The $3 hourly inference price makes the software bill easier to estimate. It excludes the robot, integration, maintenance, connectivity and human assistance. More importantly, an hour of model availability is not necessarily an hour of completed productive work. A practical comparison needs the number of successful cycles, the time lost to failures and the labor required to recover.

At the advertised rate, eight hours of continuous Dream-1 inference would cost $24 before those other expenses. This is simple budgeting arithmetic, not a price for a completed shift. A useful operating record would pair that bill with completed cycles per hour, interventions per hundred attempts and the time required for each reset. Those measurements reveal whether inexpensive model access produces inexpensive work, or whether an apparently small software cost sits inside a labor-intensive experiment.

Cloud delivery also creates a systems question. The model, network connection and local controller must work together while a physical machine is moving. UMI's timing experiments illustrate why observation and action latency belong in the engineering assessment. A buyer should measure that complete loop on its own hardware, rather than infer responsiveness from the location of a data center or the speed of an edited demonstration.

An API can lower the cost of starting an experiment. It can also give small hardware teams a route to capabilities they could not afford to train alone. Whether that advantage persists in a deployed product depends on repeatability and support, including how the system behaves when it cannot complete an instruction. The launch offers a way to investigate those questions; it does not settle them.

Frequently Asked Questions

What's Coming Next

The most informative next milestones are repeatable customer tasks, clearly reported failure and intervention rates, and evidence of transfer on machines outside the launch demonstrations. Buyers also need to see how performance changes with different grippers, workspaces and network conditions. Independent trial records, such as Robocurve's browsable runs, make it possible to inspect more than a headline average.

Hero: February 2026 DreamZero research demonstrations, Figure 3 of World Action Models are Zero-shot Policies, by Seonghyeon Ye and co-authors / NVIDIA, CC BY 4.0. Original figure mirrored unchanged; responsive display may crop. Historical research context, not Dream-1 launch footage or a customer deployment.