Cosmos-Predict2.5: one flow model for text, image and video world prediction

Read the banner: this line has been superseded

The first thing in this README is an important callout, not a description of the model. It announces that Cosmos 3 has arrived as NVIDIA's next-generation foundation model platform for Physical AI, and states that this repository is no longer under active development and will receive only limited maintenance updates. Future model work, features, documentation and community support are focused on Cosmos 3, and users are encouraged to migrate.

The claimed improvements are worth reading for what they imply about this line. Cosmos 3 is described as delivering stronger world prediction, more accurate and physically grounded future-state predictions across environments and embodiments, and as unifying capabilities that previously required multiple specialized models: one model that can reason, predict, transfer across domains and modalities, and generate actions and policies for embodied agents.

That last sentence is the substantive difference. In this repository, those capabilities are spread across three model types and several checkpoints. In the successor, they are described as one architecture.

The timeline supports the story. The last push to this repository was on 2026-06-08, and the most recent news entry is from February 23, 2026, while the newest tag v1.5.2 dates from 2026-05-04. So this is a line that was shipping regularly until recently and is now explicitly on hold, not one that has been stale for years.

If you are evaluating Cosmos-Predict2.5, the first question is not whether the model is good. It is whether you need this generation of it.

Three model types in the family, all post-trainable

Cosmos World Foundation Models come in three types, and the README states that all of them can be customized in post-training. This repository is cosmos-predict2, with cosmos-transfer2.5 and cosmos-reason1 as the siblings.

The split is by job rather than by version. The predict family produces video of what happens next, the transfer family moves content between domains, and the reason family is the vision language model. Cosmos-Predict2.5 uses Cosmos-Reason1 as its text encoder, which is a nice piece of design: the same model that reasons about scenes also conditions the prediction, so text conditioning inherits the reasoning stack rather than a separate text tower.

The post-training point matters more than it sounds. These are foundation models, and the repository's value for most users is the recipe layer above the checkpoint: action-conditioned post-training, LoRA for Video2World and Text2World, distillation guides, multiview post-training, and a policy path for robotics.

The audience is named in the README as developers advancing physical AI applications such as autonomous vehicles, robots and video analytics agents. Combined with the classifier in pyproject.toml, which says the intended audience is Science/Research, that tells you what kind of user the packaging is written for.

The platform claim is narrower still: the classifier lists NVIDIA CUDA as the environment and Linux as the only operating system.

What the unification changes for you

The technical claim is that Cosmos-Predict2.5 is a flow based model that unifies Text2World, Image2World and Video2World into a single model. In the previous generation those were separate entry points with separate checkpoints; here one model takes all three conditioning modes.

The stated result is a significant improvement over Cosmos-Predict1 in both quality and prompt alignment, and the README's Image2World example is a text prompt describing a scene over time, a nighttime city bus terminal shifting from stillness to subtle movement with double-decker buses under overhanging lights, which is the kind of description a text-to-video prompt already is. So the unification is visible in the interface, not only in the architecture.

Two supporting pieces of the stack explain why this model behaves differently from an ordinary text-to-video system. A pedagogical README in the docs directory covers the Rectified Flow formulation and its integration with the UniPC solver, which is the sampling machinery behind flow models and the first place to look if you want to understand why the sampling setup is the way it is. And a multiview cross-attention module was added in the November 7, 2025 update, which is how the model conditions on several camera views at once, the case that matters for robot manipulation.

Autoregressive sliding window generation mode arrived in the same update, for generating longer videos than a fixed window allows.

Fourteen months of shipped features, in order

The news section is dense enough to be a roadmap, and reading it in order explains the shape of the repository.

The line opened on October 6, 2025 with Cosmos-Predict2.5 and Cosmos-Transfer2.5 described as the next generation of the world simulation models. Robot and action-conditioned inference followed on October 14, with both an inference guide and a post-training guide, plus auto multiview post-training. LoRA post-training for Video2World and Text2World arrived on October 21 along with a gr00t-dreams dataset.

October 28 added the Cosmos Cookbook, a collection of step-by-step recipes and post-training scripts for robotics and autonomous systems, and in a separate entry the same day the cosmos-oss package was introduced alongside tokenization speedups using CP plus torch.compile for Transfer2, guardrail updates, multi-storage support and an action-conditioned inference bug fix.

November 7 brought DMD2 distillation for model compression, the autoregressive sliding window and the multiview cross-attention module. November 11 refactored the Auto/Multiview code and added inference example notebooks. November 25 is the hardware entry, adding Blackwell plus ARM inference support, guardrail offloading improvements, and Git LFS enablement for large assets.

December 5 released the 14B base models with inference and DreamGen post-training, plus a robot multiview agibot model. December 19 added Diffusers support for the 2B model and a Text2World distilled checkpoint. The last entry, February 23, 2026, released Action-Cond Distillation and Policy models evaluated on RoboCasa and Libero.

The pattern is a research line that kept adding capability faster than it stabilised its interface, which is exactly what the migration notice reflects.

Packaging: cosmos-predict2 on top of a pinned cosmos-oss

The Python packaging is small and worth reading closely. The distribution name is cosmos-predict2, the build backend is hatchling, and the version is dynamic rather than hardcoded. It requires Python 3.10 or newer, and it declares exactly one runtime dependency, cosmos-oss pinned at version 0.1.0.

Everything else arrives through extras. gradio pulls the Gradio interface, cu128 pulls one torch generation and cu130 a newer one, and the dev group is cosmos-oss with dev and gradio. There are also robocasa and libero dependency groups, and those two are where the robotics evaluation stack lives, pulling robosuite, mujoco, h5py, gym, libero and friends.

That single pinned dependency is the structural fact. The repository is a thin, well-organised layer over cosmos-oss, so the version of the underlying package is what determines what you actually get, and pinning it at 0.1.0 means you are pinned to one point in that package's history.

The container side is more opinionated. The Dockerfile builds from nvidia/cuda:12.8.1-cudnn-devel-ubuntu24.04, installs ffmpeg, git-lfs and standard tools, copies uv from a pinned image at version 0.8.12, sets UV_LINK_MODE=copy because the cache is a mounted volume, and installs just at tag 1.42.4 for task running.

The task runner in the justfile is where the developer ergonomics live, with recipes that sync the environment and then run a command inside it:

FROM ${BASE_IMAGE}
RUN curl --proto '=https' --tlsv1.2 -sSf https://just.systems/install.sh | bash -s -- --to /usr/local/bin --tag 1.42.4

plus a pre-commit recipe that installs pre-commit at 4.3.0 or newer and runs it across the repository, retrying once. The container therefore needs no manual environment setup before those recipes do anything.

Architecture decides your CUDA extra and your GPU budget

The justfile encodes two defaults that vary by CPU architecture, and they are the kind of detail that saves an afternoon on the wrong machine.

The first is the CUDA name. default_cuda_name is cu130 when arch() returns aarch64 and cu128 otherwise, so on an ARM host you get the newer CUDA line with its matching torch generation, and on x86 you get cu128. The install recipe writes the chosen name into a .cuda-name file and passes it as the uv extra, and a companion recipe reads that file back, defaulting to the same architecture-dependent value if it is missing.

The second is the GPU count. default_max_gpus is 4 on aarch64 and 8 elsewhere, so the framework budgets for half as many devices on an ARM system.

Neither setting is documented in the README prose, and both are the kind of thing that only shows up if you read the task file. Together they say the project supports two quite different deployment shapes, with the ARM path being the more constrained one.

The November 25, 2025 entry is the context for this: Blackwell and ARM inference support arrived at the same time as guardrail offloading improvements and Git LFS enablement for large assets, which is what you would expect from work aimed at making the big checkpoints usable on more than one kind of machine.

Where Cosmos-Predict2.5 is the wrong tool

The first boundary is succession, and it is not a footnote. If you are starting now, the README tells you to migrate, and it describes Cosmos 3 as the home for future models, documentation and community support. Building a new research pipeline on a line that receives only limited maintenance means you own the maintenance yourself when a driver or torch generation moves.

The second is hardware and platform. The classifiers say Linux with NVIDIA CUDA, so there is no macOS path and no CPU path, and the practical requirement is a CUDA card capable of the checkpoint you pick. With 2B and 14B variants in the same family, the model choice is a VRAM choice before it is a quality choice.

The third is what the output is. These models produce video of a predicted future state, which is a research artefact and a data generator, not a component you put in a request path. Nothing here offers an online endpoint or a hosted inference service. If you need a robot to act, this line's answer is a policy model plus post-training recipes, and the successor's claim is that one architecture covers reasoning, transfer and action generation together.

The fourth is documentation shape. Much of the practical guidance lives in the Cosmos Cookbook repository and in the docs directory, with a link-check configuration and a pre-commit gate, so a lot of what you need is spread across at least three places.

And the fifth is the ecosystem question. Guardrails are described as a platform feature alongside the models and the data processing and curation pipeline, which tells you this was built as an end-to-end system for physical AI rather than as a drop-in model library.

Editorial conclusion

Adopt Cosmos-Predict2.5 if you are doing world model research on NVIDIA hardware and want the 2B and 14B checkpoints, the distillation and LoRA post-training recipes, and the documented inference path in one place. Do not start new work on it: the README states this repository is no longer under active development and will receive only limited maintenance, with future models, features, documentation and community support focused on Cosmos 3. Verify four things before you invest. Read the banner first and decide whether Cosmos 3 covers your case, since it is described as unifying reasoning, prediction, domain transfer and action generation in one architecture where this line needs several. Check the platform, because the package classifiers say Linux with NVIDIA CUDA and requires Python 3.10 or newer, so macOS and CPU-only machines are out. Then check the CUDA extra you select, since cu128 pairs with one torch generation and cu130 with another, and the choice defaults by architecture. And confirm the checkpoint size against your VRAM, because a 2B and a 14B model are not interchangeable for the same experiment. Start with the packaged dependency cosmos-oss pinned at 0.1.0 and a single uv sync before touching the examples.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. nvidia-cosmos/cosmos-predict2.5 on GitHub
3. Project website
4. README
5. Releases