Dream Labs Dream-1: the $3-an-hour robot brain, explained

TL;DR

Dream-1 is a robot brain you rent by the hour. Dream Labs launched it on October 19, 2026 as a public API that drives two-armed robots with parallel grippers, including robots it was never trained on, for $3 an hour ($2 for the lighter Dream-1-flash). You send camera images, the arm positions, and a task in plain English. It sends back the next 1.6 seconds of movement.

The headline numbers are real, and so is the catch. On an independent benchmark from Robocurve it scored 59 against 48 for Claude Opus 5.5 and Gemini 4 Argon. But Dream Labs' own tables show full task success of 40% at best on its home robot, and 6% on tool use. Its CEO calls it "a research beta". It is a big step for hobbyists and small robot makers, not a warehouse worker yet.

If your work is software, not arms, the useful version of this idea already exists. A robot model is infrastructure; eesel is the employee: ready-to-work AI teammates for your helpdesk and your blog. An industrial automation company uses one to put a drafted answer on every engineering support ticket before a person opens it.

What is Dream Labs' Dream-1?

Dream-1 is a robot foundation model that Dream Labs describes as a "World Action Model". In plain words, it learned how scenes change from video, and then it links that understanding to the movements of robot arms. The launch post sums up the pitch: give it a new two-armed robot with parallel grippers, connect it to the API, and it starts doing tasks "out of the box", with no fine-tuning and no demonstrations from that robot.

I build AI agents for a living at eesel, so when I read launch posts like this one I come with one specific question, which is what the model really receives and what it hands back. Dream-1's answer is refreshingly concrete. The homepage says you "send camera images, the robot's current state, and a task", and Dream-1 "returns the actions your robot needs to execute it." That is the same shape like an LLM tool call, the kind AI agents make all day, except the output is joint angles instead of text.

The scope for today is deliberately narrow. Dream Labs says Dream-1 "is a manipulation policy for bimanual robots with parallel grippers", meaning two arms, each with a simple two-finger pincer. Mobile robots and dexterous hands are listed as future work. That narrowness matters in terms of everything below, because most of the impressive results are living inside it.

It landed in a quite busy month. Robot brains are this year's frontier model race, also with Skild AI's S1 learning tasks from one video and Google pushing Gemini 4 Argon for robotics. What Dream Labs added is the part which those launches mostly don't have, a public API with a price per hour.

How does a World Action Model work?

A World Action Model predicts how the next few video frames will look like and what the arms should do, in one step. Dream Labs' own line is that "controlling a robot and imagining what that robot will do are the same problem." Every robot is showing up to the model in the same way, as pixels.

Here is the loop as the research page lays it out:

1. Observe. Three cameras feed in: one head view and one wrist view per arm. Add the arm state and the task text.
2. Predict. The model jointly generates "imagined frames" of the near future and an action chunk for the arms.
3. Act. The robot executes the chunk. Each API call covers 1.6 seconds of motion.
4. Correct. The real camera frame replaces the imagined one, and the loop runs again.

The clever bit is about the action format. Dream-1 can output joint angles for robots it knows, but it can also output end-effector poses: where each gripper should be, and whether it is open or closed. Any two-armed parallel-gripper robot shares that language, and its own inverse kinematics (IK) solver, the math that turns "put the gripper here" into motor angles, does the translation. Dream Labs is upfront that this is also one weak point: zero-shot performance "depends partly on your robot's" IK solver.

The idea is not new for this team. The founders published DreamZero in February 2026, the paper that introduced World Action Models. DreamZero ran a 14B-parameter video diffusion model at 7Hz and adapted to the YAM robot with 30 minutes of data. Those are the DreamZero's numbers, not the Dream-1's, and Dream Labs hasn't published Dream-1's size.

Which robots can Dream-1 control?

Dream-1 was trained on one robot only, the I2RT YAM, and Dream Labs tested how far this transfer goes. The answer: 27 unseen robots in simulation and 4 unseen real ones, scored relative to the YAM at 100%.

The real-robot results ran on earlier Dream-1 checkpoints that never saw those robots, according to the launch post:

In simulation, the spread is wider. The two-armed PiPER kept 91.2% of the YAM score, while Bracket Bot fell to 36.6%. In between sit familiar research robots like ALOHA (63.1%), the 18-year-old PR2 (73.8%), a pair of UR5e arms (69.8%) and the Hugging Face-friendly SO-101 (54.2%). Each simulated robot got 300 rollouts: 150 testing whether it follows instructions, and 150 on tasks it hadn't seen.

My read is that the further a robot drifts from the YAM's shape, the more the score drops. That's not a knock, it's what you would expect, and Dream Labs publishes the bad rows next to the good ones. One fun detail from a Dream Labs researcher, Jeremy Collins: Dream-1 "has never trained on a single frame of simulation", so even the sim results are a form of real-to-sim transfer.

How good is Dream-1, really?

Better than the general-purpose AI models in robot control, and still well short of reliable. Both halves of that sentence comes from numbers Dream Labs itself published, which I respect.

Let's start with the good half. Robocurve, a public benefit corporation that is measuring robotics capabilities, evaluated Dream-1 before the launch on its RoboDojo-RC Tier 1 benchmark, with 120 real-world attempts per configuration.

The launch post adds that Dream-1 costs 16x less per task attempt than Gemini 4 Argon and runs 1.7x faster than GPT-6 Astra. Its pitch is that LLMs "excel at planning" but robots "still require a fast, general System 1 to act." That framing is fair, a frontier LLM thinking through every grip is slow and expensive, which you can see in Gemini 4 Argon's pricing.

Now the honest half. On its own home robot, Dream Labs reports the full success rates by task type, and they are quite low.

A 40% pick-and-place success rate means that the robot finishes the job less than half of the time in the easiest category. "Progress scores" (partial credit) are higher, from 42% to 69%, so the arm usually gets somewhere useful before it fumbles. Dream Labs says it plainly: "Robotics won't be solved on day one."

The sharpest critique on Hacker News came from a commenter who looked past the demos:

"If you look at what they actually demonstrate, zero-shot embodiment generalization is limited to controlling two-finger grippers on two stationary arms. The embodiments are all very similar, and when they're slightly different (even just replacing two fingers with five fingers) they can't do zero-shot anymore."

modeless, Hacker News

That is a fair point, and it is matching with Dream Labs' own scope statement. The question is whether "two arms, two fingers" is a niche or a market. Dream Labs is betting it's a market: it says a two-armed setup now costs "as little as $2k", and that Hugging Face's $399 Microduck sold 10,000+ units in four days.

How much does Dream-1 cost?

Dream-1 costs $3 per hour of robot run time, and Dream-1-flash costs $2 per hour. Dream Labs' launch post does the math: each call returns 1.6 seconds of actions, so an hour is 2,250 calls, or about $0.0013 per action for Dream-1 and $0.0009 for flash.

The shift and monthly rows are my arithmetic from Dream Labs' hourly rates. The fine-tuning price comes from the developer platform, which says a job costs $200 "at the time of writing", takes about 4 to 5.5 hours, and bills fine-tuned models at the same rate as the base model. A few other billing details from the same console:

• Prepaid credits. You top up between $5 and $10,000, with an optional monthly spending limit. Only successful requests are billed.
• Free credit. Adding a card unlocks free credit to try Dream-1; the amount isn't published.
• No refunds on unused credit, and Dream Labs calls the service an "experimental beta research preview".

What I like in this pricing is that it's in the unit a robot builder thinks in. A per-token price, the way you'd pay for GPT-6 Astra or Claude Opus 5.5, forces you to guess how many tokens a grip costs. An hourly rate lets you to compare against the hourly cost of a person doing the same task, which is exactly the comparison that Dream Labs wants you to make: "you keep everything above the hourly cost."

How do you actually use Dream-1?

There are three doors, and just one of them needs a robot. Dream Labs' homepage lists the Dream API, fine-tuning, and a Robot Playground.

The playground is the fastest way for forming an opinion. You type a task, and a real robot in Dream Labs' San Francisco lab, or a simulated one, takes a turn. Early testers on Hacker News got mixed results: one reported that "put the crown on the cup" was "partially successful", and another found "throw the block off the table" wouldn't run at all.

The API is a Python client. The launch post shows the shape: create a DreamClient with your key, pick the checkpoint dreamlabs/dream-1, send an observation, and call get_action() in a loop. Behind that, the console docs describe the base64 camera frames plus arm state going in, and 48 rows of actions which are coming back per call. A follow-up from the team adds a tiny "System 0", a 100k-parameter network that runs on the robot's CPU to smooth those chunks, cutting lag to about 75 ms.

Fine-tuning is for robots that zero-shot doesn't cover. You upload demonstrations, then Dream Labs hands you a model ID. The examples are rather small: 5 minutes of data moved the needle on Maker Arm and reBot, while a Dexmate robot with dexterous hands needed 77 minutes. Across 12 partner robots, fine-tuning raised the instruction-following score on 10, with big jumps like AI Worker going from 44% to 84%. Two got worse: Bracket Bot (32% to 31%) and Unitree R1 (42% to 31%).

Dream Labs also ran a beta with 12 outside sites, including Hugging Face in Paris, Scale AI in San Francisco and AgiBot in Shanghai. The demo videos are sped up 4x to 8x, which is worth to remember when they look so smooth.

Who is behind Dream Labs?

Dream Labs is a small team in San Francisco with a big NVIDIA pedigree. Its four co-founders, per investor Kindred Ventures, are:

The company came out of stealth with a $90M seed round on launch day, led by B Capital with Kindred Ventures, plus Wing VC, Unusual Ventures, SV Angel and Hugging Face CTO Thomas Wolf, among others. Wing VC's investment note singles out the team adapting to new robots with "just five minutes" of data. The team page shows about a dozen people, with alumni of NVIDIA, Google DeepMind, Ai2, Toyota Research Institute, Stanford, Berkeley and Georgia Tech.

There's a nice irony in the benchmark table: GR00T N1.7, the NVIDIA model several founders worked on, scored 10. Different job, though. GR00T is open weights which you run by yourself; Dream-1 is a hosted API.

How does Dream-1 compare with other robot models?

Dream-1's real difference is not the score, it is the access model. Most of rival robot brains are either open weights you host yourself or the closed systems you can't buy.

One Hacker News commenter put the access difference neatly, comparing it with Physical Intelligence's offering:

"the Physical Intelligence API requires finetuning for the task/robot while the Dream-1 model offers an API that can do zero-shot (with great limitations of course but still cool)."

GaggiX, Hacker News

If you have GPUs and robotics engineers, open models like pi0 or GR00T give you bigger control. If you have a $2,000 arm kit and a weekend, Dream-1 is the shortest path from "unboxed" to "it moved a banana", which is the audience Dream Labs says it wants: "consumers, prosumers, and small teams, not enterprises."

What are people saying about Dream-1?

The reaction splits along a predictable line, builders are excited with the API while automation veterans are unmoved by the demos. CEO Joel Jang set expectations himself on launch day:

"Dream-1 is still a research beta, and it will make mistakes."

Joel Jang, X

The most pointed skepticism came from someone who said they had worked in manufacturing and warehouse automation:

"Everything about this page strikes me as having been optimized for investors, not customers. Why would they cite a literal toy as a leading example of automation work?"

Aurornis, Hacker News

And a more measured take from an OpenCV educator, which is close to my own view:

"I'd want to know where that transfer breaks: unfamiliar workspaces, poor IK, and new gripper designs. ... Selected, sped-up demos aren't a reliability test. I haven't run Dream-1 myself."

Satya Mallick, X

My take is that Dream Labs did the unglamorous things right. It published its failure rates and priced the thing per hour, also it let strangers drive a real robot over the internet. The open question is reliability on long, messy, real tasks, and nothing in the launch answers it yet. Better wait for independent results outside of the YAM family before building a product on it.

What Dream-1 means if you don't build robots

The most interesting line in the whole launch came from a Dream Labs researcher: "A model like Dream-1 will soon be a tool call for LLMs". That's Jeremy Collins on X, and it describes where AI is heading on both sides of the screen. A smart planner decides what to do, and a fast, specialized model does it.

Dream-1 is the infrastructure in that picture. Dream Labs says it plainly: "We're the brain, not the body." Someone still has to build the body and wire it up, then point it to a job. For software work, that "someone" doesn't have to be your engineering team. eesel is the employee rather than the engine: you hire a ready-to-work teammate for a defined job, today either the AI helpdesk teammate or the AI blog writer, and it arrives with the integrations and company context for that role. I go deeper on that split in this AI employee explainer.

It is also the most relevant use for people who are building robots. Hardware companies get the technical support questions about wiring and settings, and configurations too. An industrial automation company put its technical library behind an eesel chat, a form of AI documentation search that answers only from its documents and links the source. On every new support ticket, the eesel teammate leaves a drafted answer with a confidence level as an internal note, and an engineer edits and sends it. eesel never writes to a customer on its own there. Their documentation manager said eesel had "a proof of concept built using our own product materials" from the first call.

And if you like the "tool call" idea, eesel already works that way for software. The eesel CLI lets you run the same teammate from a terminal: check its recent runs with eesel activity, approve or deny pending actions with eesel approvals, or edit its standing rules with eesel instructions. Every command prints JSON, writes support a --dry-run, and coding agents like Claude Code can drive it directly, including through eesel's MCP server. It's the same "planner calls a doer" pattern, minus the robot arms.

Robots that clear dishes on the first try are coming, maybe sooner than the 40% figure suggests. An AI teammate that clears your support queue is already here, and my roundup of the best AI teammates shows how the options compare. Try eesel free, and see what a teammate does with your last week of tickets.