~/satyajit

Praxis-1: a robot policy that acts on a video it never finishes imagining

mdjsonmcp

2026-11-12 · 31 min · robotics · world-models · flow-matching · diffusion · mixture-of-experts

A 4:58 narrated explainer, drawn in code. Every number and picture in it is this article's own; the sources are below.

› transcript

Here is a robot policy built on a video model. Does it watch the future play out before it moves the arm? Hi, I'm Wystan! Praxis-1 is Runway's open-weight robot policy. Here's how a video model ends up driving an arm. Chapter one. Three ways to drive an arm. A robot policy maps what it sees to a short chunk of motion. Three families compete. A vision-language-action model starts from a language model. It knows what a comb is, not how it moves when pushed. A world model predicts the scene given an action. It is a simulator. It does not act. A world action model predicts frames and actions together. The bet: weights that imagine the scene learn the motion. And video is cheap. Chapter two. Inside the fifty-four gigabytes. Runway's figure. A video backbone of fourteen encoder blocks, mostly mixture of experts: twenty-six point nine billion parameters, two point eight billion active. Below it, the action expert: sixteen layers, three hundred and fourteen million parameters. Every other layer is a cross-attention. Each reads one tapped encoder block, along these dotted lines. Each call takes an instruction, the latest frames from two cameras, and where the arm is right now. A mixture-of-experts video model starts denoising the next stretch of video. A small action expert taps eight of its layers, reading the future as the backbone imagines it. Nothing flows back. Out come twenty-four rows of motion: one point six seconds at fifteen hertz. Time is cut into chunks of one point six seconds. The exterior and wrist cameras sit side by side on one canvas. A frozen video autoencoder shrinks it sixteen times in each direction. Two by two patches make a hundred and eighty-two tokens per latent frame. Six latent frames: one thousand and ninety-two video tokens per chunk. The expert holds just fifteen tokens. The arm's motion is a rounding error in the sequence. Who reads what. Each row is one chunk's actions. They read the global tokens, and clean copies of the chunks before them. And the diagonal: the backbone's noised version of the very chunk being acted on. The actions read the future as the backbone imagines it. Chapter three. Two steps, and a video it never finishes. Here's the surprise in the code. The next one point six seconds of motion are read off the backbone while its picture of them is still almost pure noise. Sampling walks time from one, pure noise, to zero, clean. The served config takes two steps and shifts the grid by twelve point five, so the middle call lands at zero point nine two six. Both the video and the actions start as pure noise. Step one runs the guided encoder and decoder, and moves the video latent seven point four percent of the way. Step two runs the encoder alone. The expert jumps the actions to clean in one move, and the decoder is skipped. On the article's toy, with a fifty-fifty context, the reach lands between the mugs. With eight steps and no shift, the action chunk gets clean enough, around a quarter of the way from the end, to resolve the choice by itself. The reach commits to one mug. So where do errors come from? Sampling its own video, the arm misses by five point seven one centimetres on average. Hand it the true future, noised to the same level, and the error drops to one point one four. The mistakes live in which future it imagines. Chapter four. Does it hold up? On a hundred and twenty simulated tasks: forty-six point two percent. Fifth overall, first among world action models. From one run. The launch also set it against a frontier agent on a pen cap. Praxis-1 is done in seconds, the agent takes minutes. But that is a fine-tune on this robot against an agent running zero-shot. A gap in latency and cost, not capability. The article found three soft spots. Its most common failure is reaching for an object that resembles the target. Chunked execution means up to two point six nine seconds before a disturbance changes the motion. And every new robot is a full fine-tune of twenty-seven billion parameters. The robot moves on a future the model has barely started imagining. Better imagination is where the remaining errors live. A video model that imagines, an expert that reads it, two steps per chunk. Thanks for watching! Every source is in the full article. I'm Wystan. Bye!

Why read this

Notabletop 60%

Reads the served sampler from code (two steps, video never finished) and checks every launch claim against the RoboLab board.

  • Original analysis
  • Widely used
  • A new technique

Robotics & embodiedNeeds datacenter GPUsApache-2.0Practitioner model

How this was scored
Is it new?
2 of 3: A real new idea, method or capability
Can I trust it?
2 of 3: Measures key facts from files, code or configs
Can I run it?
2 of 3: Open code or weights with real limits
Will I understand it?
2 of 3: Mechanism from first principles with figures
Can I act on it?
2 of 3: A concrete recipe, numbers or comparison
Will it last?
1 of 3: Relevant for months
Does it affect many?
2 of 3: A widely used model, tool or lab release
Only here?
2 of 3: A teardown or measurement few others did

Score 66 of 100, ranked 254 of 740 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

On 2026-11-11 Runway released Praxis-1, which it calls a world action model, with open weights under Apache 2.0. There are three policies on Hugging Face, a base, a single-arm DROID policy and a bimanual YAM policy, plus NVFP4 and LeRobot variants. Inference and fine-tuning code is at runwayml/praxis-1-oss, and a long technical report stands in for a paper. The launch thread on X made four claims: first place on NVIDIA's RoboLab-120 leaderboard, ahead of every open VLA including π0.5 and GR00T N1.6; 15 of 15 simulated trials on a Noble Machines robot after under 30 minutes of teleoperated demonstrations; and a run 15.6x faster than GPT-6 Astra driving the same arm, at 51x lower cost per completed task.

For this piece I read every safetensors header of the DROID checkpoint by HTTP range request and summed the shapes. I read the sampler, the model and the server code at commit 68f4d7a (2026-11-11), the configs, and NVIDIA's NeMo fine-tuning tutorial. I also read the live RoboLab leaderboard, and I went back to the launch thread's videos. I ran no model. Nothing here was served on a GPU.

The finding that changed how I read the whole release is in the sampler, so the mechanism comes first.

Three ways to turn pixels into motor commands

A robot policy maps what the robot sees and feels to what it does next. Modern ones emit an action chunk, a short trajectory of future commands executed before the policy looks again. One expensive network call is then spread over many control ticks.

Three families compete for that job.

A VLA (vision-language-action model) starts from a vision-language model and adds a head that outputs actions. π0.5 and GR00T N1.6 are the open reference points. The language model brings semantics: it knows what "the purple comb" is. It brings nothing about how a comb moves when pushed, because no text corpus teaches contact dynamics.

A world model predicts the future of a scene given an action. It is a simulator you can roll policies through. Runway uses one that way for policy evaluation, and its September post claims a 0.95 correlation between success inside its world model and success on hardware. A world model does not pick actions.

A world action model (WAM) predicts the future frames and the actions together. The bet is that the same weights that must imagine what the scene looks like after the gripper closes will learn which motion gets it there. Video is cheap and abundant; teleoperation is neither. Runway's September post puts a number on the bet: fine-tuned placement error of 16.1 cm after pretraining on web video against 16.0 cm after pretraining on the same hours of teleoperated robot video, inside one standard error over 93 evaluation pairs. If that holds, the bottleneck on a policy becomes how much ordinary video a model can digest. This site has covered three other WAMs: FLUX 3 Action, NVIDIA's Cosmos 3 policy variants and Flex-π.

The cost of a WAM is tokens. Video is thousands of them per second, actions a few dozen. Every design in this family is an answer to the question of how much imagined video you pay for per action, and when.

What is in the 54.4 GB

Praxis-1 has three parts. A video backbone predicts the next stretch of video. A small action expert reads the backbone's hidden states and predicts the motion. Thin per-robot projections translate each robot's poses and actions into the shared format. Runway's architecture figure:

Block diagram on a dark background. An instruction encoded by a frozen Qwen3.5-2B and a camera canvas encoded by a frozen Wan2.2 VAE feed a video backbone of 14 encoder blocks, numbered 0 to 13, of which 0 and 1 are dense and the rest mixture-of-experts. Blocks 0, 2, 4, 6, 7, 9, 11 and 13 are outlined as tapped. The encoder feeds a backbone decoder of 6 blocks that outputs the next video chunk. Below, an action expert of 16 layers alternating cross-attention and self-attention takes noised actions plus the chunk-start pose; dotted lines connect each of its 8 cross-attention layers to one tapped encoder block. The expert outputs the next chunk of 24 action rows.
The 26.9B backbone (2.8B active per token) and the 314M action expert. Eight expert cross-attention layers each read one encoder block; nothing flows from the expert back into the backbone (Runway, Praxis-1 technical report, Figure 1).

The weights tell the same story in more detail. Summing all 567 tensor shapes in the 17 shards of praxis-1-droid gives 27,202,371,308 parameters. Hugging Face's API says 27,202,371,288. The gap of 20 is the twenty scalar tensors of shape [], one per backbone block (I counted them), which the API skips. The file total is 54,404,746,968 bytes, all BF16 except 2,176 FP32 values.

Component (DROID checkpoint)Parameters, summed from headers
Backbone encoder, 14 blocks18.905B
Backbone decoder, 6 blocks7.983B
Action expert, 16 layers plus heads314.4M
Total27.202B
of which routed MoE experts25.669B (94.4%)

The backbone is a diffusion transformer split into a condition encoder and a velocity decoder, the DDT layout of Wang et al.. It works on latents of a frozen Wan2.2 VAE and reads instructions through a frozen Qwen3.5-2B. Seventeen of its 20 feed-forward layers are mixture-of-experts. Each MoE layer has one shared expert and 128 routed experts, and every token takes the shared one plus eight routed ones, balanced the DeepSeek-V3 way.

The config shows why the report can say per-token compute "stays about the same as a dense block". Every expert has a hidden width of 1,280, and nine of them make 11,520, which is exactly dense_ffn_hidden, the width of the three dense layers. A token pays for one dense FFN's worth of matrix multiplies while the layer stores 129 experts. Applying 8 of 128 to my routed total gives 2.823B active parameters in the backbone, which matches the report's 2.8B.

Tokens per chunk

Time is cut into chunks of 1.6 s: six latent frames, 24 frames at 15 fps, 24 action rows at 15 Hz. The DROID config fixes the shapes, and multiplying them out shows where the compute goes. Two cameras, exterior and wrist, are resized to 224×416 tiles and placed side by side on a 224×832 canvas. The VAE compresses 16× in each spatial direction, giving a 14×52 latent with 48 channels, and the backbone patchifies 2×2. That is 7×26 = 182 tokens per latent frame and 1,092 video tokens per chunk. On the action side, the expert holds one pose token, eight learned "future" tokens and six action tokens per chunk. Each action token packs four rows of the 10-D action (action_patch_dim: 40). Fifteen expert tokens against 1,092 video tokens: the arm's motion is a rounding error in the sequence.

An action row for the Franka is 10 numbers: xyz, a 6-D rotation and the gripper. Position and rotation are relative to the pose at the start of the chunk. Position and gripper are rescaled to [-1, 1] by the 1st and 99th percentiles of DROID, and the exact bounds are written into config.json, so no dataset statistics are needed at inference.

Chunk-causal attention

The base video model generated whole clips with every frame seeing every other, including later ones. A robot cannot see its own future, so mid-training switches the attention to chunk-causal: chunk kk attends to itself and to clean copies of chunks before it. In training, those earlier chunks are real video (teacher forcing), which lets Runway train four chunks in one parallel pass over a 93-frame window. The action expert gets a mask of its own:

Grid with query rows A0 to A3 and key columns G, N0 to N3 and C0 to C2. Row A0 reads G and N0. Row A1 reads G, N1 and C0. Row A2 reads G, N2, C0 and C1. Row A3 reads G, N3, C0, C1 and C2. G is global tokens, N noised chunks, C clean copies of chunks, A the expert tokens of each chunk.
The expert's cross-attention: the actions for chunk k read the global tokens, the clean chunks before k, and the backbone's noised version of chunk k itself. They read the future as the backbone imagines it (Runway, Praxis-1 technical report, Figure 2).

That last column is the whole idea. The actions for the next 1.6 s are computed by reading eight layers of the backbone while it denoises its picture of the same 1.6 s.

Joint denoising, and what "jointly" means here

Both streams are trained with rectified flow. Take a clean sample x0x_0 (a chunk of video latents, or a chunk of action rows), Gaussian noise ε\varepsilon and a time t∈[0,1]t \in [0, 1], and mix them along a straight line:

xt=(1−t) x0+t ε,v=ε−x0.x_t = (1-t)\,x_0 + t\,\varepsilon, \qquad v = \varepsilon - x_0 .

The network vθ(xt,t,c)v_\theta(x_t, t, c) learns the velocity vv given conditioning cc: the instruction, the clean context frames, the pose. Runway's loss is an equal-weight sum of the video and action velocity losses. Each chunk draws its own video noise level, weighted toward high noise, and its own action noise level, uniform and independent. The independence matters: the expert learns to read the backbone when the imagined video is nearly clean, when it is nearly pure noise, and everywhere between, regardless of how noisy its own actions are.

At inference the sampler walks tt from 1 to 0 with Euler steps,

xt′=xt+(t′−t) vθ(xt,t,c),x_{t'} = x_t + (t' - t)\,v_\theta(x_t, t, c),

and the clean-sample prediction the network implies at any point is x^0=xt−t vθ\hat{x}_0 = x_t - t\,v_\theta.

In the released code, "jointly" runs in one direction only. The docstring of plan_window_joint says it outright: "No trunk pass reads the actions or the proprio: the video Euler state moves with the video velocity only." The video stream is denoised as if no actions existed. The action stream is denoised by the expert, which reads the backbone's taps at each step. Video shapes actions, and never the reverse. During training, the action loss does push gradients into the backbone through those cross-attention reads, so the backbone learns features the expert finds useful. At inference the backbone never sees the expert's output.

Two steps, and a video that never finishes

The shipped settings are in configs/serve_droid.yaml and configs/sim_droid.yaml: num_steps: 2, t_shift: 12.5, cfg_video_scale: 4.0, cfg_scale: 1.0. The time grid comes from window_time_grid in praxis/sampler.py:

uj=1−jN,tj=s uj1+(s−1) uj.u_j = 1 - \frac{j}{N}, \qquad t_j = \frac{s\,u_j}{1 + (s-1)\,u_j}.

With N=2N = 2 and s=12.5s = 12.5, u=(1,0.5,0)u = (1, 0.5, 0) becomes t=(1,0.926,0)t = (1, 0.926, 0). So the model is evaluated twice: once on pure noise, once at t=0.926t = 0.926, where the latent is 92.6% noise by mixing weight. The first Euler step moves the state 7.4% of the way. The second covers the remaining 92.6% in one jump.

That jump has a useful property. The last Euler step goes from tt to 0, so

x0=xt−t vθ(xt,t,c)=x^0(xt,t,c).x_0 = x_t - t\,v_\theta(x_t, t, c) = \hat{x}_0(x_t, t, c).

The output of the sampler is exactly the network's clean prediction made at its last evaluation. For Praxis-1 that means the 24 action rows the robot executes are the action expert's one-shot guess, made while it reads a backbone whose video latent is still 92.6% noise. Runway's report describes the knob in softer words: "A larger shift leaves more of the denoising to the second step."

Then there is skip_video_decoder: on, set in both serve configs. The server code explains it: the last step "moves only the actions, which read only the encoder taps", so the video decoder is skipped and "the plan has no video (None)". Counting the passes in plan_window_joint for one served DROID call:

  1. Step 1 at t=1t = 1: encoder and decoder with the instruction, encoder and decoder with a blank caption (video guidance 4 needs both), one Euler step on the video latent.
  2. Step 2 at t=0.926t = 0.926: the encoder only, with the instruction. No decoder, no unguided pass.
  3. Two passes of the action expert, one on each step's taps.

Three encoder passes, two decoder passes, two expert passes. The robot moves on actions read from a future that the model starts imagining and abandons 7.4% of the way in. The "predicted chunk of future video" in the report's prose exists on the server only when you turn the flag off; it is not in the default response. The README is plain about this, so it is not a hidden trick. It does mean the "world" half of this world action model is, at serving time, a set of hidden states.

The video guidance still matters, through a narrow channel. At step 1 the backbone sees only noise plus context, so its taps depend on the context and the instruction. Guidance acts on the video velocity of step 1, and that guided velocity moves the latent the 7.4% that the step-2 encoder pass then reads. Runway's guidance search (section 9 of the report) found that adding video guidance and raising the shift together ended 4.0 points above its start of no guidance at shift 8. Pushing either further scored lower. The report says the search ran on "a fixed set of simulated environments" and does not say which; I could not tell from the repository whether those were RoboLab tasks.

Here is the sampler on a toy problem. The time grid is Praxis-1's. The action distribution is mine: a 24-row reach that should go to one of two mugs, with an exact denoiser for that two-way choice and a slider for how strongly the context favours the left one.

With 8 steps and no shift, the sampler resolves the choice by itself: by t≈0.25t \approx 0.25 the noise is small enough that the partial chunk already looks like one reach or the other, and the posterior collapses. With Praxis-1's 2 steps at shift 12.5, the last read is at 0.926, the partial chunk is almost all noise, the posterior still equals the context prior, and the output is the prior-weighted average of the two reaches. At 50/50 that is a reach for the empty space between the mugs. The toy can't speak for the learned model, whose conditioning makes most scenes unambiguous. What it shows is where the choice has to come from at these settings: the context frames, the instruction and the barely started imagination, not the iteration.

Runway's own error analysis points the same way. On 32 held-out DROID windows, the mean end-effector error is 5.71 cm when the model samples its own video and actions, and 1.14 cm when it is handed the true future video, noised to the sampler's level, and samples only the actions.

Bar chart of action error in centimetres. Oracle, given the true future video, has a short pink bar at 1.14 cm. Deployment, sampling its own video, has a tall dark bar at 5.71 cm. Error bars are plus or minus one standard error.
Most of the action error comes from which future the backbone imagines, not from reading motion off it (Runway, Praxis-1 technical report, Figure 15).

And the limitations section names the most common real-robot failure as "reaching for an object that resembles the target, and the wrong choice is usually already visible in the imagined video". A look-alike mug is exactly the case where the context doesn't settle the choice.

The control loop, 1.6 seconds at a time

Each call returns 24 rows (21 on the first call of a context window, whose first latent frame covers one frame instead of four). In the default chunked schedule the robot executes all of them, sends back the frames it saw over one WebSocket, and calls again. The report gives p50 server times on one H100 of 522 ms for the DROID policy and 545 ms for the bimanual one, and about 0.55 to 0.6 s round trip.

Waiting is the price. If a call takes LL seconds and a chunk lasts H=1.6H = 1.6 s, a synchronous loop holds still for L/(L+H)L / (L + H) of the time. The report measured that on its bimanual station: 32% holding still when calls took 0.8 to 0.9 s, and 16% at about 0.3 s. The formula gives 33.3 to 36.0% and 15.8%. Close enough that the loop is doing what it says.

Real-time chunking (RTC), opt-in in the repo, asks for the next chunk before the current one ends. The hard part is the junction. Runway's blended plans made the arm oscillate, so the new plan starts from where the arm will be. On the bimanual station RTC cut holding still to 5% and 3%. On a five-object pick-and-place into a bag it finished faster (median 9.1 s against 15.2 s) at 24 of 30 successes against 28 of 30 chunked. With streaming optimizations the p50 call drops to 124 ms (DROID) and 128 ms (YAM).

The slider exposes the other cost of chunking: reaction time. A cube that slips just after a call took its frames is first seen by the next call, a full chunk plus one call later, and acted on one call after that. At 545 ms that is 2.69 s in the worst case. RTC shortens it by one call, not by a chunk; the chunk length itself is what bounds how fast this policy can notice anything.

Four stages of training

Runway trains the world before the actions. Each stage starts from the one before, and the video loss stays on throughout.

Stage one is Runway's video foundation model, trained on twelve generation tasks with full-sequence attention. Stage two switches to chunk-causal attention on embodied video at 15 fps: 58% egocentric human video, 20% general video, 18% real-robot video and under 1% gameplay, by tokens. Stage three attaches the expert with fresh weights and adds action targets for single arms, arm pairs, handheld grippers and human hands, ramping the action gradient into the backbone from zero over 1,500 updates and keeping about 30% of tasks video-only. Stage four fine-tunes for one robot; for DROID that is about 277 hours of successful episodes, 128 H100s and 50k steps.

The fine-tune is a full fine-tune of 27.2B parameters. The per-robot projections are the only new weights, but every backbone matrix moves. NVIDIA's NeMo tutorial does the same on one 8-GPU node, with the 128 routed experts split 16 per GPU so the FP32 optimizer state fits.

Runway's compute-scaling test is the strongest evidence that mid-training matters. Five DROID fine-tunes from successive mid-training checkpoints scored 25.5%, 35.2%, 39.2%, 41.2% and 41.2% on RoboLab-120. On RT-1, a robot absent from all mid-training, five fine-tunes rose from 56.3% to 80.0% on SimplerEnv, though not monotonically (65.6%, 66.9%, 64.1% between). Runway calls its fitted line "a guide rather than a law", which is the right amount of confidence for five points. The released DROID policy scores 46.2%, not 41.2%; the guidance and shift search accounts for some of the gap, and the report does not reconcile the rest.

The launch claims, one by one

"#1 on NVIDIA's RoboLab-120 leaderboard"

RoboLab-120 is NVIDIA's Isaac Sim benchmark of 120 tabletop tasks for a DROID-style Franka, 10 trials per task. Here are selected rows of the unfiltered board as I read it on 2026-11-12 (Cosmic, tied sixth at 42.3%, and HiDream-O1-Embodied at 39.9% are among those left out), with exact 95% Clopper–Pearson intervals I computed from the success counts:

#PolicyTypeSuccessesRate95% interval
1AMP1agentic LM2,579 / 3,00086.0%
2SenseNova-RoboRSIagentic LM685 / 1,20057.1%
3LakesideLWM1,531 / 3,00051.0%
4BiMind v0.5VLA590 / 1,20049.2%
5Praxis-1WAM555 / 1,20046.2%43.4–49.1%
6FLUX 3 ActionWAM515 / 1,20042.9%40.1–45.8%
7Atomic-WAMVLM+WAM475 / 1,20039.6%
8Cosmos3-Nano-PolicyWAM441 / 1,20036.8%
11π0.5VLA336 / 1,20028.0%
15GR00T N1.6VLA87 / 1,2007.2%

Praxis-1 is fifth. The report says so itself, in a paragraph the tweet left out: the top two are frontier models driven as agents, and Lakeside and BiMind v0.5 are closed models trained partly on simulation data, BiMind v0.5 fine-tuned on RoboLab data. The link in Runway's post opens the board pre-filtered to robot foundation models with open weights. Under that filter, or among WAMs, Praxis-1 is first. The precise claim is the report's: "#1 world action model" and "#1 open source robot foundation model". "#1 on the leaderboard" is the tweet's compression.

Within the claim that does hold:

Bar chart of RoboLab-120 success. Praxis-1 in pink at 46.2 percent, then FLUX 3 Action 42.9, Atomic-WAM 39.6, OASIS WAM 39.0, Cosmos 3 Nano 36.8, π0.5 (VLA) 28.0 in grey, DreamZero 25.7, and GR00T N1.6 (VLA) 7.3 in grey.
Runway's comparison: world action models in dark, open VLAs in grey. The four entries above Praxis-1 on the unfiltered board are not in this chart (Runway, Praxis-1 technical report, Figure 8).

On real hardware, Positronic ran Praxis-1 on FLUX 3 Action's own ten published Franka tasks, 10 episodes each, in two sessions of five on one rig on November 2. Praxis-1 succeeded 88 of 100 times, FLUX 3 Action 80. The two tie on five of ten tasks; the largest gap is "cup in bowl", 100% against 70%. A two-proportion test on 88 against 80 gives p = 0.12. The report does not say whether the operator was blind to which model ran, which BFL's own Positronic comparison in September did state.

80.0% on RT-1, a robot it never saw

Fine-tuned for 30k steps (about 28 hours on 32 H100s) on the full RT-1 training split, 78k episodes from the head camera, Praxis-1 scores 80.0% on SimplerEnv's visual-matching grid of 864 episodes over four tasks. The original RT-1 policy scores 52.4%.

Grouped bar chart for SimplerEnv Google robot visual matching. Pick coke can: Praxis-1 98.3, RT-1 85.7, FLUX 3 Action 70.0. Move near: 81.7, 44.2, 44.2. Open or close drawer: 56.5, 73.1, 38.9. Put apple in drawer: 83.3, 6.5, 5.6. Mean of four tasks: 80.0, 52.4, 39.7.
Per-task success on SimplerEnv's Google robot grid: Praxis-1 fine-tuned on RT-1, the published RT-1 policy, and FLUX 3 Action fine-tuned by Runway with BFL's DROID recipe (Runway, Praxis-1 technical report, Figure 13).

Two cautions. RT-1 is a 2022 policy, and much of the 27.6-point gap is one task: "put apple in drawer", 83.3% against 6.5%. On "open / close drawer" Praxis-1 is worse than RT-1, 56.5% against 73.1%. And the 39.7% for FLUX 3 Action is a competitor fine-tuned by Runway with a recipe written for a different robot. That is a reasonable effort, not a tuned baseline.

Fifteen of fifteen on a Noble Machines robot

I could not find this anywhere but the tweet. The technical report does not mention it. The launch post lists Noble Machines only as a launch partner, in a sentence about "a legged humanoid, a six-axis industrial arm and a dual-arm warehouse robot". The September post shows a Noble Machines clip of bimanual manipulation at 2x speed. The tweet's own 21-second video is a grid of simulated runs, each tile badged "Simulation", of a humanoid moving wooden blocks into a bin.

Two of the simulated runs from the launch thread's video, cropped from a screen recording of Runway's page. No task definition or baseline comes with them (video from @runwayml's thread on X).

There is no task definition, no baseline, no statement of what "under 30 minutes" included, and no checkpoint. For what the number can mean: 15 successes in 15 trials puts the exact 95% interval for the true success rate at 78.2% to 100%. It is a demo, consistent with a policy that adapts quickly. It is not a measurement I can hold anything to.

"15.6x faster than GPT-6 Astra, at 51x lower cost per completed task"

Section 7.3 of the report gives the setup: Praxis-1 and GPT-6 Astra on the same YAM teleoperation station, the same console, the same three tasks, data collected on November 9.

TaskPraxis-1 timeAstra timePraxis-1 costAstra cost
Pen cap0:157:48$0.08$3.47
Sponge in bag0:222:46$0.03$1.20
Die in bag0:112:04$0.01$0.93
All three0:164:13$0.04$1.87

Time is averaged over successful episodes only. Cost per completed task counts every episode, failures included, at $3.95 per H100-hour for Praxis-1 and the API bill for Astra. The report gives no episode counts and no success rates for either side.

One pen-cap episode each: Praxis-1 done in 0:13, GPT-6 Astra in 7:54. Runway plays both at 8x, and this cut is sped up about four times more to fit. A single picked episode; the table above averages successful runs (video from @runwayml's thread on X).

The ratios from the rounded table come out at 15.8x and 46.75x, not 15.6x and 51x. That fits rounding: $0.04 could be anything from $0.035 to $0.045. At $3.95 an hour, $0.04 buys about 36 seconds of H100 per completed task, and $0.08 on the pen cap about 73 seconds, against a 15-second average success. So either Praxis-1 failed a fair share of pen-cap attempts or the GPU was billed for time outside the episode. The report doesn't say which.

The bigger issue is what is being compared. The YAM fine-tunes learn from roughly 1,400 to 2,600 hours of bimanual YAM recordings, per the report. Astra ran zero-shot through a tool interface, and the fine-tuning bill is not in Praxis-1's $0.04. The report is fair about this in prose: it calls the two approaches complementary and notes that frontier-model agents currently hold the top two places on RoboLab. The speed gap is real and large. The tweet's "dramatically outperforms frontier LLMs" is a statement about latency and cost per task on trained tasks, not about capability.

Open, and how open

The Apache 2.0 claim checks out. All eight repositories carry license: apache-2.0, none is gated, and the frozen dependencies, Qwen3.5-2B (also Apache 2.0) and the Wan2.2 VAE, download from their own repos. That makes Praxis-1 the most permissively licensed WAM this site has looked at; FLUX 3 Action's weights carry a non-commercial licence with a revenue cap.

The launch post's hardware list, "from data center GPUs like H100 and B200, to workstation GPUs like RTX 5090", needs a footnote. The BF16 checkpoint is 54.4 GB, plus 4.55 GB of text encoder and a 2.82 GB VAE file, and the README asks for one 80 GB GPU. A 32 GB card needs the NVFP4 path. Its repos are bf16 QAT master weights, 54.4 GB to download either way; the routed experts are packed to NVFP4 at load time, shrinking the policy in memory to 17.5 GB. My own arithmetic agrees: 25.669B routed weights at 4.5 bits each (4-bit values plus one 8-bit scale per 16) is 14.4 GB, the size the card gives for the packed experts, and the other 1.53B parameters in BF16 add 3.1 GB. The NVFP4 card says the native path runs on SM120 GPUs only, while the code README lists SM100, SM110 and SM120. Runway's quantization test found NVFP4 at 279 of 600 RoboLab episodes against 287 for BF16, and 26 of 30 against 28 of 30 on the YAM bag task, neither difference significant.

NVIDIA's NeMo tutorial is the most useful independent number in the release. On LIBERO-Spatial, the DROID checkpoint zero-shot fails all 500 episodes; it "moves smoothly and purposefully, but towards the wrong things". A full fine-tune of 600 steps on 8 H100s (1 h 52 min) reaches 451 of 500, and a LoRA run of the same length 457 of 500. Two caveats on the tutorial. Those are NVIDIA's numbers, which I did not reproduce. And it says the evaluation used text guidance 3.0, while sim_droid.yaml at the commit I read says 4.0.

Where it breaks

What I think of it

Praxis-1 is the best open-weight world action model I have read, and the licence is the most important part of the release. Apache 2.0 weights, code, a MuJoCo sim, LoRA recipes and an NVIDIA fine-tuning tutorial mean a lab can actually build on it, which was not true of FLUX 3 Action.

The benchmark story is good and overstated in the usual ways. Fifth overall, first in its class, from one verified run; a real lead on complex tasks that the launch didn't mention; a Noble Machines number with nothing behind it; and an Astra comparison that measures the price of zero-shot generality, not a capability gap.

What I will take away is the sampler. The marketing image of a WAM is a model that watches a movie of the future and then acts it out. The shipped Praxis-1 starts the movie, runs it 7.4% of the way, and reads the motion off the backbone's hidden states while the frames are still almost pure noise. Finishing the movie would not help: the decoder is skipped because the actions never read it, and they come out identical with it on. How noisy the last read is does not look like the bottleneck either. Runway's guidance search ran at two steps and moved toward a higher shift, 12.5 from a start of 8, which makes the last read noisier, not cleaner. And the oracle test reads a true future noised to the same level and gets 1.14 cm instead of 5.71. What matters is which future the backbone starts imagining.

The knob nobody has turned in public is the step count. Every number in the report is at two steps. If I had an 80 GB card for an afternoon, I would run the simulated hard suite with num_steps at 4 and 8. More evaluations give the backbone more chances to commit to one future before the expert reads it, which is the look-alike failure Runway names first. If that buys nothing, the 5.71 cm is a pretraining problem, and the answer is more video, which is Runway's bet anyway.

What would change my mind

4 claims above, and what would falsify each

  1. The served default returns no predicted video and computes the actions from taps of a latent at t = 0.926.

    Read from praxis/model.py (plan_window_joint, finish_window_joint), praxis/sampler.py and configs/serve_droid.yaml at commit 68f4d7a. If a later commit changes skip_video_decoder or the sampler defaults, or if the server path bypasses plan_window_joint, this is history. Running the server once and inspecting the response settles it.

  2. Praxis-1's RoboLab lead over FLUX 3 Action is inside run-to-run noise overall, and outside it on complex tasks.

    Based on one Praxis-1 run (555 of 1,200), FLUX 3 Action's six published seeds, and simple two-proportion tests that ignore clustering by task. A Praxis-1 seed table with a mean near 46% would make the overall lead firmer; a mean near 42% would erase it.

  3. The 15 of 15 Noble Machines result has no published protocol.

    Searched the technical report, the launch post and the September announcement, including their page data, on 2026-11-12. A partner write-up or a later Runway post with the task, the demo budget and a baseline would replace this with something checkable.

  4. The routed experts are 25.669B of 27.202B parameters, and 2.823B are active per token in the backbone.

    Summed from all 567 tensor shapes in the praxis-1-droid safetensors headers and the MoE settings in its config.json (8 routed of 128 plus one shared expert). If the loader adds parameters not in the files, sum(p.numel()) after loading would differ.

Sources and method. From files: parameter counts, dtypes and byte totals from the safetensors headers of runwayml/praxis-1-droid read by HTTP range request; repository sizes, licences and gating from the Hugging Face API; the architecture, tokenization, normalization and sampler settings from config.json; sampler, pass structure and skip_video_decoder behaviour from praxis-1-oss at 68f4d7a. No code from either repository was run. My arithmetic: active parameters, tokens per chunk, the time grid, the hold-still and reaction-time formulas, NVFP4 sizes, intervals and significance tests. From Runway: everything in the technical report, the launch post and the September announcement, including all success rates, latencies and the Astra table, and the X thread. From NVIDIA: the RoboLab leaderboard as read on 2026-11-12 and the LIBERO tutorial at Automodel commit 6f44dbf. The five figures are Runway's: three captured from the report's page, and Figures 8 and 13 from the images in Runway's X thread. The two widgets are mine; the sampler widget's two-mug action distribution is a toy, not Praxis-1. Previously on this site: FLUX 3 Action, Cosmos 3 and Flex-π.

Cite this article

For attribution, please use the following reference or BibTeX:

Satyajit Ghana, "Praxis-1: a robot policy that acts on a video it never finishes imagining", ai.satyajit.si, November 2026.

bibtex
@misc{ghana2026praxis1,
  author = {Satyajit Ghana},
  title  = {Praxis-1: a robot policy that acts on a video it never finishes imagining},
  url    = {https://ai.satyajit.si/articles/praxis-1},
  year   = {2026}
}
share