Ying Chen, Weizhen Li, Zhe Hu, Zhenjiang Li, Rui Jiang, Zhifeng Gu, Lihuang Fang, Jiangping Liu, Lei Yi, Jie Chen
5 min
Abstract
Vision-language models are increasingly serving as the reasoning core of embodied agents. Robot execution is inherently iterative: each action reshapes the scene and physical state, continually renewing what must be perceived, reasoned about, and verified. Meeting these demands requires complementary capabilities that differ in supervision signals, prediction formats, and verification criteria. Existing approaches typically develop these capabilities against isolated, task-specific objectives, leaving open how they should be organized and integrated around execution as a whole. We present Capek 0.5, an embodied vision-language model built around an execution-centric capability taxonomy. Rather than organizing training by datasets or tasks, the taxonomy groups embodied capabilities according to their functional roles throughout execution and comprises four capability families: Spatial Reasoning, Temporal Understanding, Action Guidance, and State Verification. Each capability is first acquired by a dedicated specialist through reinforcement learning with verifiable rewards from a shared backbone, and the specialists are then consolidated into a single inference-time model through weight-space merging followed by routed policy-space distillation. We instantiate Capek 0.5 at the 2B and 35B-A3B scales and evaluate it from three complementary perspectives: comprehensive benchmark suites including Capek-StateBench, a new benchmark for state verification; a controlled study of capability retention from specialists to the unified model; and closed-loop evaluation in simulated embodied environments. Capek 0.5 improves the large majority of matched benchmark rows over its initialization, retains all four specialized capabilities in one checkpoint with quantified losses, and transfers to closed-loop embodied task execution.
Sam: So TIES is the careful stitching, and MOPD is the finishing pass. Did the final result actually perform better?
Alex: The paper suggests it did. Tested against standard comparison models, Capek 0.5 improved on the majority of their benchmarks. What the authors find meaningful about this isn't just the performance gain—it's what it demonstrates. Changing the structure of how a model learns, rather than simply feeding it more data, appears to be a genuinely effective strategy.
Sam: That's a notable shift in thinking. Most people's instinct would be "just give it more examples." Is there a cost to this more structured approach?
Alex: There is. The authors acknowledge that this pipeline is more complex to manage. Instead of one training run, you're coordinating four separate specialist training processes and then executing the merge carefully. It's more moving parts. Whether that overhead is justified depends on how much the reliability improvement matters for the application.
Sam: And how do they actually measure reliability? How do you test whether a robot truly knows if it succeeded at something?
Alex: They use a mix of existing benchmarks alongside a new one they created specifically for this work, called Capek-StateBench. It's designed to test something that standard benchmarks often skip: whether the model can accurately verify its own physical state. A simple example would be checking whether a cup is actually full after attempting to fill it. A robot that can't make that judgment reliably is essentially guessing whether to move on to the next step—which compounds errors over a long task.
Sam: That's a practical gap to close. If the robot can't self-check, every mistake it makes gets buried under the next action.
Alex: Precisely. The authors also flag an important limitation: the current results come largely from simulation rather than physical hardware. Bridging that gap is explicitly listed as future work. They also describe an ambition to extend Capek into what they call an "agentic" system—one that can decide when to use its own internal reasoning and when to call on an external tool, like a path-planning algorithm or a calculator, as a deliberate action in its own right.
Sam: So the robot would have a kind of metacognition—knowing the limits of its own thinking and reaching for the right tool when needed?
Alex: That's a reasonable way to put it. Rather than trying to bake every capability into the model itself, the system would treat external software tools as resources it can actively choose to use. It's a different philosophy about where intelligence should live in a robotic system.
Sam: What strikes me about all of this is that the key insight isn't about raw computing power or data volume. It's about how you organize the learning. Specialization first, integration second.
Alex: That's the thread running through the whole paper. And it points to a broader question in the field: for robots operating in the physical world, where the cost of a mistake is real and immediate, careful architectural choices may matter more than scale alone. Thanks for listening to ResearchPod.