Robot brains can (and should) live in the cloud 🐑 ⚡
OpenAI's Astra showed us truely competent spatial reasoning arises out of enormous scale and data.
Skyrocketing dram costs, onboard energy limits and most painfully the need for generality afforded only by scaling are forcing us off board onto datacenter grade compute.
So we're now announcing @DreamscaleLabs , an applied research company engineering this future into a possible reality, gutting the latency and amping up the reliability necessary for safe remote operation.
Onwards to Physical AGI 🚀
@pentestduck@KDog112358@eternaI_entropy
Today we're incredibly excited to announce @DreamscaleLabs (YC F26)! We're an applied research company putting robot brains in the cloud.
Robot AI models are growing larger and on-board compute is getting increasingly inaccessible due to cost. We're taking a contrarian bet that the future is moving inference off the robot and into the cloud, while still meeting real-time deadlines required by robot motion.
We're building the real-time inference infrastructure that enables frontier physical AI models to run smoothly on your robot. We optimize for low latency across the full stack: from the model, down to the GPU kernels, and over the network.
Our mission is to unlock a future of safe and intelligent robots doing meaningful work, and we think this is only possible by letting you deploy and run robot models in the cloud.
Reach out to us at [email protected] or visit our website at https://t.co/AFAJApNM2H to learn more.
@KDog112358@AntoineNeedGPUs@eternaI_entropy
@IanAndrewsDC Safety + reflexes on device (always). Motion planning + reasoning (spatial and language) from the cloud. Let's see where the split lands 😉
We put our thoughts out on the future of robot inference a bit over a month ago now. What's changed over that brief time has only sharpened the picture.
- DRAM supply crunch means low cost robotics are priced out of frontier intelligence. Onboard Jetson Thor pricing has gone from 3.5K -> 5.5K. The LPDDR it desperately depends on is being siphoned into Vera Rubin racks.
- Memory and token hungry in-context learning is here (@SkildAI and @GeneralistAI ), and will only get heavier at long horizons. Every added token hammers limited on board compute. ICL prefixes -> more KV cache movement.
- The economics at scale work. We've proven hosting 8x robots on a single datacenter GPU with latency lower than 1 policy on an optimised Thor stack.
https://t.co/CIXeLgD6zx
Can attest to how terribly difficult it is to get DROID set up and running the first time.
Below is unironically the start of a "quickstart" guide I wrote for setting up DROID.
"Physical prompting" is going to be the biggest keyword of robotics in 2026.
Both @GeneralistAI and @SkildAI have come out showing that you can give a robot a single demonstration of yoh performing a task, and then have it replicate what you did.
This is eerily reminiscient of the early days of LLMs: one-shot prompting, CoT, In Context Learning etc.
Robotics is ICL-pilled at the moment.
Two weeks, two hackathons. Saturday it's Open World by @vlgeai – world models, Gaussian splats, $10K in prizes, judges from DeepMind, Meta, NVIDIA, and NASA.
Already full, but waitlist is live if you want a shot at the floor where Physical AI is built: https://t.co/v5EPFiZPYU.
We’re excited to launch Instance – a success detector for robot rollouts!
Describe your task and drop in a dataset, and it judges success/fail on each rollout with detailed subtask captions– it’s more accurate than Claude Opus 4.8, at a fraction of the latency.
This is just the first step toward our larger goal: an autonomous evaluation rig for robot learning. Today, evaluating a robot policy means humans have to watch the robot roll out, mark success, and reset the scene– we're automating that, starting with the success judge.
We’re excited to launch Instance – a success detector for robot rollouts!
Describe your task and drop in a dataset, and it judges success/fail on each rollout with detailed subtask captions– it’s more accurate than Claude Opus 4.8, at a fraction of the latency.
This is just the first step toward our larger goal: an autonomous evaluation rig for robot learning. Today, evaluating a robot policy means humans have to watch the robot roll out, mark success, and reset the scene– we're automating that, starting with the success judge.
WAMs are popular because of their promise of better generalization. Is that true? We started playing with Video-Action-Model (VAMs) and realized a gap: video model backbones can compositionally generalize but VAMs often do not.
We coin this the Video-Action-Generalization (VAG) gap and present a study on how to explain and improve it. More details: https://t.co/kwoxy2SCVu
🧵 below
Insight from my robotics journey so far: kids love robots like so freaking much.
There’s a massive market for consumer products selling to kids. Whoever cracks this will create a lot of value.
Even teleoperated battle of the bots leaves them mesmerised.
This is as much a design problem as a technology problem.
As our hardware lab is set up in a hacker home in Drummoyne we host a lot of workshops. Every time a mother walks “past they stop and say wow my kid would love this.”
I'm giving a talk tomorrow at ICML on emergent physical generalization, including π0.7 🤖
3:15 pm @ SCALE workshop in Ballroom 201
https://t.co/xppCOkktOJ
New dataset: 20h, bigger and more diverse. First π0.5 finetune is running (bs 256, lr 5e-5), I'm eval'ing checkpoints to find ideal tuning length.
Per checkpoint observations:
> 10k: Very jittery - feels like too short an action chunk on ACT. Reaches for the wrong actuator most of the time.
> 20k: Much smoother. Failure modes differ sharply from my last policy (data, or something else?). Precise about which actuator it grabs; struggles with the handover, but when it lands, insertion often works perfectly.
> 30k: Jittery again, but micro-level now - Parkinson's-like tremor that faded over later rollouts. 6/40 insertions. Same pattern as my last model on different data: centre actuators succeed most, maybe because they're furthest from being edge cases.
> 40k: Picks up the right actuator very reliably. Handover slightly better, but insertion has gone rigid - same as longer runs on the previous dataset: less adaptation, more likely to jam the actuator where it doesn't belong (hole edges, neighbouring actuator). 0/40 inserted. Start of overfitting?
> 50k: Ok, not overfitting. Cleaner than any checkpoint. Still dropping actuators on handover, but very precise targeting. Fails on edge actuators - moves the gripper past the box edge and gets stuck. Best rollout yet: 7/40 clean. Movements very smooth overall.
Overall, I'm thinking the best way to collect data is not getting a big dataset straight away, but what @robertorobotics said on a call earlier: start with a small dataset (single-digit hours), train a first policy and collect intervention data from there on.
built an interactive actuator designer
made this so anyone into robotics can understand actuators by playing with one, not reading a datasheet
try it → https://t.co/hgx39DEnjQ