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.
Alex: Welcome to another episode of ResearchPod. Today we're discussing Capek 0.5, a vision-language model designed to serve as the "brain" for robots that need to interact with the real world.
Sam: So the core problem this paper is tackling—why do robots struggle with long, complex tasks in the first place?
Alex: Think about what a robot actually has to do. It doesn't just perform one action and stop. It has to look at a situation, decide what to do, do it, and then check whether it actually worked—over and over again. The authors argue that current models fail at this loop because they try to learn all of those skills simultaneously, and those skills end up getting in each other's way.
Sam: Like trying to learn how to drive, cook, and play piano all at the same time. You'd spread yourself too thin.
Alex: Exactly. So instead of that, the authors propose what they call an "execution-centric" approach. The idea is to break robot work into four distinct roles: figuring out where things are in space, tracking how a task unfolds over time, deciding what action to take next, and checking whether the last action actually succeeded. They describe it as training a kitchen staff—a chef, a sous chef, a prep cook, a quality checker—rather than expecting one person to do everything at once.
Sam: That makes intuitive sense. But once you've trained four separate specialists, how do you combine them into a single robot brain without losing what each one learned?
Alex: That's the central engineering challenge. If you train all four roles together from the start, they interfere with each other—the learning signals conflict. So instead, the researchers train four completely separate models, each becoming genuinely good at its one job. Then they merge them using a technique called weight-space merging. The name sounds technical, but the idea is straightforward: an AI model is essentially a huge collection of numbers—called weights—that encode everything it knows. Merging in weight-space means mathematically combining those numbers from four models into one.
Sam: But surely you can't just average four sets of numbers together and hope for the best?
Alex: Right, and that's where a method called TIES comes in. Think of it like editing four different people's notes into one clean document. You first cut out the redundant or low-confidence parts from each set, and then where two models disagree on something, you resolve the conflict rather than just letting them cancel each other out. That gives you a merged model that retains the strongest knowledge from each specialist. Then a second refinement step—called routed MOPD—acts like a final polish, making sure the combined model behaves coherently as a single system.
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.