ExplorRobo

The Robot Stack Is Going Modular, and the Guard Layer Has No Home

By ExplorRobo Editorial · · 12 min read

Figures attributed to companies, projects and papers are their published claims. The synthesis, comparisons and judgements below are this author’s analysis.

Three teams made the same structural move this fortnight. A Caltech and Stanford group published HomeBody, which removes the learned action model from the middle of the robot stack and lets a frontier vision-language model call a fixed library of skills instead. Black Forest Labs released FLUX 3 Action, an open weights 7B model that fine-tunes into a policy per task. General Instinct shipped InstinctFlash, a serving runtime putting eight robotics model families behind one API.

Different bets, one shared assumption: the trained policy is no longer the centre of the system but a component behind an interface, replaceable and, in HomeBody’s case, disposable.

That simplification is real, and the fortnight priced it. The component that gains authority here is the general frontier model, and the only published test of whether such a model refuses an unsafe instruction, RoboHarm, recorded refusals on between zero and 20 percent of trials. Modularity arrived at the edges, authority concentrated in the middle, and nothing in the new interfaces is responsible for saying no. For the background, see Why Vision-Language-Action Models Matter for Robotics.

What HomeBody actually removed

HomeBody’s page states the conventional arrangement plainly: a System 2 VLM reads observations and instructions, a learned System 1 VLA emits commands, and a System 0 controller executes motion. Its question is whether the learned VLA is still needed. Its answer is a plug-and-play VLM calling a composable skill library, demonstrated on a Unitree G1 in an unseen kitchen with no environment-specific training data and no additional policy learning.

Once the policy is gone, the work moves to exploration and grounding. The G1 explores first, collecting iPhone video, D435i camera observations, LiDAR scans with SLAM, joint poses and waypoints. A Real2Sim agent builds a digital twin in Isaac Sim from that data, and the robot localizes against it with Super Odometry and iterative closest point registration. The vocabulary is five skills: pick, place, open drawer, pick from drawer and navigate, sharing one interface for targets and execution results.

Targets are typed spatial selections rather than prose. A pick call carries an image point normalized to a range of 0 to 1000 and which hand to use; the point prompts segmentation, Fast-FoundationStereo estimates depth from the D435i stereo pair, and the masked geometry is projected into 3D to predict a grasp. SAM 2.1 tracking keeps the target as the view changes, and visual servoing corrects alignment without a new model decision. Motion runs on a pretrained AMO lower-body policy at 50 Hz with arms and hands at 250 Hz, on one Razer Blade laptop with an RTX 4090, with GPT Astra called remotely.

The authors list their own constraints: Real2Sim adds setup time and API cost, task length is bounded by reach and hardware endurance including finger-servo overheating, and GPT Astra’s reasoning latency adds pauses between skills. What matters is what is absent: the expensive object in the older stack was a trained policy, and here it is a scene reconstruction, a remote model call and a laptop GPU.

FLUX 3 Action bets the other way

Black Forest Labs did not shrink the policy. It made a better one and shipped it as a file. FLUX 3 Action is an open weights world action model: a 7B diffusion transformer predicting future frames and the actions that produce them jointly, with a frozen video VAE encoding frames and a frozen Qwen3-VL-4B encoding instructions. Action tokens form a second stream in the same sequence, one per future frame, with a projection and head per embodiment, and video and action tokens share one noise level so they denoise together.

A call takes camera frames, a state vector and a caption, and returns 32 actions plus optionally 32 decoded frames. At control time you skip the decode, execute the first few actions, observe again and replan. Fine-tuned on DROID, the company reports 42.92 percent success on RoboLab-120 against 36.8 percent for the 16B Cosmos3-Nano-Policy, 28.0 percent for pi0.5 and 7.2 percent for GR00T N1.6. Those are one publisher’s numbers on a single benchmark.

The integration details matter more than the leaderboard row. SO-101 checkpoints shipped inside LeRobot, adapted on about 200 teleoperated episodes, with transfer reported to objects never seen in training. Weights are under the FLUX Kommunity License v1.0, the company’s own licence rather than an OSI-approved one, so “open weights” should be read literally.

Same structural move, other direction: the deliverable is a checkpoint to swap, not a stack to adopt.

Serving became the interface

InstinctFlash makes the pattern explicit. One Python Runtime and one serve command cover eight model families, from LingBot-VA and LingBot-VLA through pi0.5 and GR00T N1.7-3B to the Cosmos3 edge policies, and robot side clients connect over the msgpack websocket protocol the existing openpi client already speaks. Client code does not change when the model underneath it does.

Its published p50 latency on Jetson Thor, measured on 15 September, runs from pi05 at 408.58 ms under PyTorch against 51.85 ms under FP8 (7.88x) to GR00T N1.7 at 139.50 against 117.30 ms (1.19x), with a headline of up to 33.78x on LingBot-VA. The README attaches two caveats worth borrowing: that headline includes a change from a 25V/50A schedule to 2V/4A, which changes what the model computes rather than only how fast, and the FP8 rows were measured with engines the project has since replaced and never re-measured. Precision is tiered for that reason: FP8 and numeric compilation are explicit opt-ins rather than defaults.

The layer that inherited the authority is the least measured

RoboHarm is a 300-trial evaluation of five harmful instructions on bimanual I2RT YAM arms under the Inspect Robots harness. Anthropic’s Claude Fable 5.1 and OpenAI’s GPT-6 Astra ran as agent policies, reading the scene and choosing actions and tool calls under a 40 LLM call budget and a 900 step cap. Ai2’s MolmoAct2, a vision-language-action model, ran as a policy with no language output. Each ran each instruction 20 times, with human reviewers labelling every trial.

Pooled, as the site states it: Fable refused 20 of 100 trials, Astra 2 and MolmoAct2 none. All 20 of Fable’s refusals were the stabbing instruction, where it completed 0 of 20 and Astra completed 17 of 20. The burner and toaster instructions drew one refusal between them across 120 trials. The configuration that completed more also refused less, with Fisher exact tests putting both differences below p of 0.001.

Two limitations matter as much as the numbers. The eval uses one wording per instruction, so it measures refusal of one sentence rather than of the act. And it cannot measure refusal for the VLA at all: MolmoAct2 has no language output and no way to stop on its own, so its low completion rate reflects capability rather than safety.

My reading is that this is an architecture question, not a model question. The agent-policy configuration RoboHarm tested is the configuration HomeBody promotes: a general model reads the scene, selects among skills or tools, observes the result and continues until the task ends or the call budget runs out. The decision to decline an unsafe task is made by that same model, in the same loop, at the level of the sentence. Putting the VLA back does not fix it either: it makes the safety question unanswerable, because that component has no channel for an answer.

The eval is self-published by Robocurve, which builds the arms and harness involved, and 20 trials per cell cannot rank close policies, as its authors say. The argument does not rest on decimals. It rests on the fact that in the only public bench test of this arrangement, frontier models drove the arm and carried out the destructive instructions, and nothing below them was asked.

The guard has to sit below the planner

Two artefacts from the same week point at where the answer belongs. The first is Realizability Is Not Enough, posted on 24 September, which builds an open source pipeline for ROS 2 FlexBE supervisors: it generates capability-based Generalized Reactivity (1) specifications, audits the strategies, reduces states with a behavior-preservation proof and emits executable state machines, validated across four case studies including hardware on two quadcopter platforms. Its auditor is sound and complete for four structural defect classes: protocol violations, deadlocks, bounded-failure violations and goal-unreachable traps. Its recommendation is enumerated encoding, System-Goal liveness and auditing every realized strategy, because proposition count and realizability do not measure deployability.

The second is a community post on the ROS Discourse, a Webots demo of a deterministic safety reflex on a TIAGo. The reflex is pure Python on CPU with no ML in the loop, reported as clamping wheel velocity with sub-millisecond delay, plus a rule that a job flagged non-interruptible cannot resume without human confirmation. It is a single-author simulation demo that notes it was prepared with AI assistance, so it illustrates a shape rather than a result.

Both point the same way: refusal belongs at the level of the executable action, as a precondition on a state machine rather than a property of a language model’s willingness to chat. HomeBody makes that cheap: its skills already share an interface carrying a target and an execution result, so adding a precondition is an interface change inside the same architecture, needs no retraining, and can be tested with RoboHarm’s methodology. It composes as well: Mission Canvas, a ROBOTIS project posted on 27 September with open source code and docs, composes skills and VLA-based behaviours into waypoint missions, which is the layer a supervisor would live in.

What this means if you are building robots

  • Write the skill contract before the planner. Typed target, preconditions, expected result and a failure reason the planner can act on.
  • Budget the planner like a network dependency. RoboHarm capped its agent policies at 40 LLM calls and 900 steps. HomeBody names remote latency as pauses between skills and Real2Sim as setup time plus API cost.
  • Put refusal in the skill, not the prompt. The evidence so far says the prompt level is the unreliable one.
  • Give a refusing policy somewhere safe to go. Every RoboHarm scene held a benign object (bread, kettle, tool basket, vegetables, a second cup) so a declining policy had a safe alternative to suggest. For the data side of these pipelines, see The Robot Data Bottleneck Has Two Halves, and Only One Scales.

What to watch next

Whether anyone outside Black Forest Labs reproduces the RoboLab-120 result, and whether the FLUX Kommunity License permits the deployments people will want. Whether HomeBody’s skill interface is adopted beyond its authors while serving runtimes quietly become the integration point. Whether a guard ships as a first-class component in a mainstream stack rather than staying a paper and a simulation demo. And whether vendor write-ups start reporting refusal rates the way they report success rates, because after this fortnight the absence of that number is a choice.

Sources

Frequently asked questions

Does HomeBody still use a vision-language-action model?
No. The HomeBody authors replace the System 2 VLM to System 1 VLA to System 0 controller chain with a frontier VLM that calls a library of composable skills directly, reporting long-horizon kitchen tasks on a Unitree G1 without environment-specific training data or additional policy learning.
What is a world action model?
It is a model that predicts future video frames and the actions that produce them within one sequence. Black Forest Labs describes FLUX 3 Action as a 7B world action model, with action tokens carried as a second token stream alongside frame tokens inside a single diffusion transformer.

Related reading