Black Forest Labs' flux-action is an open-weight 7B world action model that is trained and fine-tuned for action prediction on robots (DROID, SO-101), in simulators, and in games, and then executed. The 2026-11-02 commit 89ad4b6 (PR #9) added "committed prefix real-time chunking." Commands already sent to the robot are fixed as the prefix, and only the segment after them is newly predicted.
There are two new settings. rtc_max_prefix draws the prefix length P from [0, rtc_max_prefix] for each window during training, and places the ground-truth target values of timestep 0 into the first P action tokens without computing loss on them. The remaining tokens are reweighted so that their weights do not vary with P. At inference, when predict_action_chunk receives committed_actions, it pins those commands to the first P tokens across all denoising steps and returns them unchanged. select_action predicts the next chunk while rtc_overlap commands are still queued and commits it as the beginning of that chunk, so that consecutive chunks are stitched together without a break. docs/setup.md now contains a description of the control loop that starts the next prediction in a background thread when the remaining commands number P, and the tests were added as tests/test_rtc.py.
The limits are clear. This feature works only with the absolute and joint_relative action parameterizations, and joint_delta is rejected at configuration time. It cannot be used in the reference path that uses prepare_inference(). Since P has to cover latency × control frequency, at 30 Hz a 250 ms latency means 8 commands, i.e. roughly 10 are needed, and this has to be determined by directly measuring the slowest prediction on the robot computer. The documentation states that, with compilation and distillation applied, it measured about 140 ms on an RTX 5090, and it advises requesting an optimized deployment checkpoint. That said, this commit contains no performance comparison or statistics, and since the defaults of both settings are 0, the existing behavior is unchanged. How much the stalls caused by latency are reduced is too early to judge without separate measurement, so the actual control cycle and latency should be measured first.