A shared action vocabulary, not a specialized model, is what makes one VLM run four robots

The central claim here is blunt: a vision-language model, given the right interface, is sufficient to operate a physical robot — no separate policy network, no specialized action model, no robotics-specific architecture. Show-Harness is that interface, and the design choice it bets on is a shared discrete action vocabulary that every supported embodiment speaks. Franka arms, AgileX Piper (single and dual), ManiSkill, and Isaac Lab all receive the same tokens; only the interpreter layer beneath changes. The VLM never touches raw joint angles or motor commands — it emits action units, and deterministic interpreters ground those units into motion. That separation is the whole argument: keep the model responsible for decisions, keep the physics out of the model's head.

Two operating modes share this interface without modification. In zero-shot mode, a frontier closed-source VLM runs the full plugin harness with no robot-specific training at all. In fine-tuned mode, a small open model — the default config points to a Qwen3.5 2B backbone — emits one action token per step after training on GUMI demonstrations, planner-free. The fine-tuning cost is described as less than a few H200 GPU-hours, which is a meaningful claim: it puts capable robot policies within reach of labs that cannot afford large compute runs.

GUMI, the demonstration collector, deserves attention on its own. It maps every action unit to a keyboard key or browser button, so a human demonstrates a task by literally playing the robot in a browser tab. No teleoperation hardware, no post-processing pipeline — every step is recorded as a ready observation-action pair. A --sim flag lets you try the interface against a synthetic tabletop world before any real hardware is connected. The same key bindings also power live human takeover during autonomous rollouts, which is a sensible safety affordance.

The plugin system is where the research surface lives. Nine plugins cover perception (multi-view guidance, proprioception), reasoning (subtask planning, situated planning, action chunking, adaptive step, visual prompting), and action (action history, failure recovery). Each mounts on one stage of the interaction loop, is toggled by a single boolean, and leaves the loop byte-identical when disabled. That last property matters for ablation: you can isolate the contribution of any single plugin without touching anything else in the stack.

Released alongside the harness are six LoRA adapters — five trained on real Franka and Piper rollouts across Qwen3.5 and Gemma 4 backbones, one simulation policy covering both simulators — plus the full demonstration corpus. The training pipeline is self-contained under its own directory and builds against LLaMA-Factory. One documented hazard: the chat template used at serve time must exactly reproduce what LLaMA-Factory rendered during training, and a mismatch fails silently. The README flags this explicitly and points to a dedicated models document, which is the kind of operational honesty that saves hours of debugging.

The embodiment-agnostic vocabulary is the load-bearing idea. If it holds across more hardware platforms than the four currently supported, the approach generalizes in a way that matters practically.