FLUX 3 Action releases weights, jointly denoising video and actions

Black Forest Labs announced FLUX 3 Action on September 23, releasing the weights and training code for a world action model with seven billion parameters, along with policy weights for DROID and SO-101 robotic arms. The model takes camera images, the current state, and text instructions as input, then jointly predicts subsequent actions and visual outcomes, allowing developers to adapt it to specific tasks using demonstration data. [Official announcement](https://huggingface.co/blog/black-forest-labs/flux-3-action)

The architecture uses a diffusion Transformer to jointly denoise video and actions within a single sequence. A frozen video VAE encodes images, while a frozen Qwen3-VL-4B encodes text conditioning. Different robot embodiments use their own action input projections and output layers, so switching robotic arms still requires aligning joint definitions, state units, and camera configurations. Matching vector lengths alone is insufficient. [Architecture overview](https://huggingface.co/blog/black-forest-labs/flux-3-action), [Fine-tuning data contract](https://docs.bfl.ai/flux_3/flux3_action_finetuning)

The public RoboLab-120 leaderboard lists 515 successes across 1,200 trials, a success rate of about 42.9%, exceeding the 36.8% reported for Cosmos3-Nano-Policy in the same table. However, this is a simulation benchmark. FLUX achieved a 28.2% success rate in the complex-task category and did not lead every model. Its overall ranking does not directly establish an advantage across all types of manipulation, physical environments, or deployment costs. [RoboLab leaderboard](https://research.nvidia.com/labs/srl/projects/robolab/leaderboard.html)

Practical control also requires distinguishing how far ahead the model predicts from how long computation takes. By default, DROID generates and executes 32 actions per cycle, covering roughly 2.13 seconds at 15 Hz. The standalone SO-101 configuration generates 42 actions and executes 32 of them, replanning after roughly 1.07 seconds at 30 Hz. These durations exclude model computation and cannot be treated as inference latency. [Control loop documentation](https://docs.bfl.ai/flux_3/flux3_action_inference)

The documentation also explains that new observations affect only the next planning cycle; they do not replace commands still waiting in the execution queue. Synchronous inference may delay control steps, and the application remains responsible for camera capture, command execution, and scheduling. The official demonstrations on physical hardware are sped up fourfold, with planning pauses edited out. Engineering teams should measure response times using unedited runs rather than infer real-time performance from demonstration footage. [Execution limitations](https://docs.bfl.ai/flux_3/flux3_action_inference), [Demonstration conditions](https://huggingface.co/blog/black-forest-labs/flux-3-action)

The public code provides workflows for full fine-tuning, resuming training, and export, while task-specific LoRA for SO-101 uses the LeRobot integration. This allows researchers to inspect the control pipeline and separately assess failures caused by model limitations and execution scheduling. Areas to watch include whether success rates and control latency can be reproduced for each version of the weights, and how well the model recovers from failures in new scenarios. The code uses Apache-2.0, while the model weights are separately covered by the FLUX Kommunity License. Commercial use and use in derivative models must be checked against the weight license terms. [Code repository](https://github.com/black-forest-labs/flux-action), [Weight license](https://huggingface.co/black-forest-labs/flux-3-action-base/blob/main/LICENSE.md)