Kairos: a 4B world model that predicts video and robot actions together

A world model that predicts pixels and actions from one head

The core claim in the README is that Kairos is not a video model. It is described as a 4B parameter native cross-embodiment world model for unified understanding, generation and action prediction, built on what the project calls a World-Action Model architecture. The distinction matters, because most video world models produce plausible future frames and stop there. Kairos is designed to produce future visual states and executable robot actions jointly, which is the difference between watching a robot do something and commanding one.

The mechanism is a Mixture-of-Transformers framework described as native and end to end rather than a stack of separate models. The README frames it as three jobs in one loop: understanding provides causal interpretation of what is happening, generation unfolds plausible futures, and prediction produces the actions. Perception, reasoning, planning and action are supposed to fall out of that single structure instead of being handed off between separate components.

There is also a claim about persistent world state. The README argues that treating world modelling as simple video continuation is the wrong framing, and that a model maintaining a persistent representation is what allows it to plan over horizons longer than a fixed clip. Whether that holds up is a question for the technical report rather than the README, but it is at least the right question to be asking.

The cross-embodiment data curriculum is the training story

The README spends a section on motivation before it describes any model, and the argument is that embodied AI has hit barriers that scaling alone does not fix. It names four of them: heterogeneous embodiment data, weak long-horizon reasoning, video and action modelling kept separate, and edge-side compute constraints. Kairos is positioned as the answer to all four at once.

The training mechanism is a Cross-Embodiment Data Curriculum, abbreviated CEDC in the README. Rather than post-training adaptation on top of a general video model, Kairos pretrains natively and moves through stages: general videos first, then human behaviour data, then real-robot interaction. The stated benefit is that world representations evolve from passive physical understanding through to active task intent and embodied control, instead of everything being flat and mixed from the start.

This is the piece of the design that would be hardest to replicate, and it is also the piece with the least documentation here. The repository has a `benchmarks/` directory and a training example script, but the README does not describe the data mixture, the stage boundaries, or how much of each stage was used. Anyone planning to retrain the model will be reading the arXiv technical report for that, and the repository for the code that consumes it.

Hybrid linear temporal memory targets the deployment constraint

Attention over long video horizons is expensive, and the README's third architectural section is about how Kairos avoids paying that cost. The approach is called hybrid linear temporal memory, and it combines three attention mechanisms: Sliding-Window Attention for local dynamics, Dilated Sliding-Window Attention for mid-range interactions, and Gated Linear Attention for global causal memory. The whole scheme is linear in sequence length.

Stacking those three is a reasonable engineering answer to a real problem. Quadratic attention over a long video token sequence is the thing that makes video world models hard to run outside a datacentre, and splitting the temporal range across three budget regimes is how you get global context without the quadratic bill.

The second half of the claim is about systems rather than architecture: deployment-aware co-design covering efficient kernels, quantization and token streaming, aimed at low-memory, high-throughput inference and eventual real-time closed-loop deployment on the edge. That is an aspiration more than a shipped feature as far as the repository shows, though the model weights published at 480P rather than the full resolution suggest the low-resolution variants are the ones intended for constrained hardware.

What is actually released, and when

The news section of the README is a dated timeline, and it is more informative than the marketing prose above it. The sequence runs from Kairos 3.0 on 18 December 2025, which introduced the model along with inference code and a pretrained 480P checkpoint, to video world model weights on 26 February 2026 in 480P, distilled 480P and 720P variants, to the technical report on arXiv on 16 June 2026, to the Kairos3.1 series on 2 July 2026.

The 3.1 release is the one to note. It includes World-Action Model inference code and three weights: Kairos3.1-4B-robot-480P, a RoboTwin2.0 variant, and a LIBERO-Plus variant. The README says those last two support executable action prediction, which means the benchmarks it advertises are ones where the model outputs actions a policy can run rather than just frames a human can watch.

Weights are distributed through Hugging Face and ModelScope, with the project also running a platform at kairos.acerobotics.com and an organisation account on GitHub. The repository itself is DAXIAORobotics/kairos with 2971 stars, 514 forks and only 7 open issues, Apache 2.0 licensed, on `main`, last pushed on 2026-09-15. The low issue count is partly a sign of a young project with a small user base rather than of perfect maintenance.

Getting it running is a small number of files

The repository root is unusually lean for a project of this size: `kairos/` for the package, `examples/` for scripts, `benchmarks/`, `docs/`, `docker/`, and two requirements files. There is no build system file beyond that, no test suite in the tree, and the top-level requirements file is a single include line:

pip install -r requirements.txt
pip install -r requirements-train.txt

The requirements files delegate rather than list, so the real dependency set lives under `docker/`. That is the file to read before you start, because the runtime and training dependency sets are separated and you probably only want one of them.

The examples directory is where the actual workflow is visible. It holds inference scripts in both Python and shell form, a training script in Python and a shell wrapper, an accelerate configuration named `accelerate_zero1.yaml` for distributed setup, and a `multi_gpu_inference.sh`. Alongside those are JSON request files covering text to video, image to video, and their 480P equivalents, plus two robot-specific variants. The presence of a distilled checkpoint alongside the full one, and of zero-stage-one accelerate config, suggests the authors expected people to fine-tune this rather than only run it.

A research release rather than a usable package

It is worth being blunt about the trade here. What you get is a well described architecture, a set of checkpoints, an inference script, and a training script whose data pipeline you will have to understand yourself. What you do not get is an install command in the README, a dependency list you can read at a glance, documentation of the training hyperparameters, or a benchmark table with numbers.

The demos in the README are all animated GIFs in a table, organised into four claims: physical and causal consistency, cross-embodiment generalisation, accurate action prediction, and high-efficiency inference. They illustrate the point and prove nothing measurable, which is normal for this genre of release and worth naming so you do not read a demo clip as a benchmark result.

For a reader deciding whether to invest time, the sequence is straightforward. Read the technical report for the evidence, download the 480P robot checkpoint that matches your benchmark, and run `examples/inference.py` against one of the JSON request files to see whether the outputs look like the demos. If the action prediction is what you care about, RoboTwin2.0 and LIBERO-Plus are the two variants the README ties explicitly to executable actions, so start there rather than with the general 3.1 checkpoint.

Editorial conclusion

Kairos is worth a look if you are working on embodied AI and want a single model that reasons about a scene and emits something a robot can execute, rather than bolting a video model onto a separate policy. The architecture claims that are concrete in the README are the cross-embodiment curriculum, the unified understanding and generation and prediction design, and the hybrid linear temporal memory that keeps the memory profile flat over long horizons. What the repository does not do is hand you training data, a paper trail on ablations in the README itself, or an installation recipe, so treat it as a research code release with weights rather than a product. Start with the inference examples and one of the released 480P checkpoints, and read the technical report on arXiv before deciding whether the training code is worth running.

Frequently asked questions

Official sources

1. DAXIAORobotics/kairos on GitHub
2. Issues
3. License: Apache-2.0
4. README