CellRank 2: Fate Mapping from Multi-View Single-Cell Data

The problem CellRank addresses: direction, not just structure

Most single-cell analysis pipelines produce a manifold. They tell you which cells are transcriptionally similar, and they may order cells along a pseudotime. What they do not tell you is which end of that ordering is the beginning and which is the end. A pseudotime is a coordinate, not a clock. CellRank's stated purpose is to resolve that ambiguity by estimating differentiation direction from biological priors, and then to answer the follow-on questions: which states are initial, terminal or intermediate, what is the probability that a given cell ends up in a given terminal state, and which genes drive those transitions. The intended user is a computational biologist working in Python with single-cell RNA-seq data, who already has an AnnData object and wants fate probabilities rather than a single trajectory line. The README lists the accepted priors explicitly: RNA velocity, any pseudotime or developmental potential, experimental time points, and metabolic labels. That list is the design centre of the package. CellRank does not assume one source of directionality is correct; it assumes you have a view of the data that carries direction, and it turns that view into a Markov chain.

What the Markov state model actually does with your prior

The mechanism named in the README is Markov state modeling of multi-view single-cell data, with pyGPCCA (Reuter et al. 2018) in the backend. Read that as a two-stage design. First, a prior is converted into a transition matrix over cells, so that each cell has probabilities of moving to other cells rather than a single assigned successor. Second, that matrix is analysed as a Markov chain: the long-run behaviour of the chain identifies which sets of cells act as attractors, and those sets are reported as macrostates. Because the object is a chain and not a tree, fate probabilities come out as continuous quantities, which is where the package differs from methods that commit each cell to one branch. The pyGPCCA dependency is the piece that finds the macrostates; the README attributes the backend to it directly. The multiview framing is the part worth pausing on. CellRank is not restricted to velocity. If you have time-point labels, or a metabolic labelling signal, or a pseudotime you trust, that becomes the view that shapes the chain. The practical consequence is that two labs analysing the same count matrix with different priors can get different fate maps, and both can be defensible within their own assumptions. CellRank does not adjudicate between priors; it propagates whichever one you supply.

Installation and the scverse compatibility claim

Installation is a single command, per the README: pip install cellrank. The installation guide linked from the README covers additional options, which matters because the default pip route may not be the right one for every environment; the README does not enumerate those options, so check the guide before pinning a version. The package declares full compatibility with the scverse ecosystem, and the practical meaning of that claim is AnnData: if your data is already in an AnnData object, CellRank operates on it rather than asking you to convert. The README does not list the specific AnnData keys, layers or obs columns that each kernel expects, so the exact interface is something you read off the documentation rather than the landing page. Versioning is active: v2.3.0, v2.3.1 and v2.3.2 were released within roughly three weeks of each other in mid-2026, which is a normal patch cadence after a minor release, and it also means you should pin a version rather than tracking main if you need reproducible figures. The README also carries an explicit instruction to consult the citation guide before citing the software, which is unusual enough to be worth noting: the citation rules differ depending on which components you use.

Where CellRank is the wrong tool

The failure mode is structural, not incidental. Every result CellRank produces is downstream of the prior you hand it. If your prior is wrong, the chain is wrong, the macrostates are wrong, and the fate probabilities are confidently wrong, because a Markov chain always has a stationary distribution whether or not that distribution means anything biologically. RNA velocity is the most common prior and also the most contested one; a dataset where velocity estimates are noisy, or where the spliced and unspliced layers are too sparse to estimate rates, will produce a transition matrix that encodes noise. CellRank has no mechanism described in the README for detecting that. A second boundary: if your question is a single, well-defined lineage with a clean marker progression, a Markov state model is more machinery than the question needs, and you will spend more time choosing between estimators for initial and terminal states than you would spend plotting the markers. Third, the README states the package scales to large cell numbers but gives no figure, no cell count and no memory profile, so treat scalability as a claim to verify on your own hardware rather than a specification. Finally, all of the above assumes Python and AnnData; there is no indication in the supplied material of a non-Python interface.

How it differs from optimal transport approaches from the same authors

The README's related-packages table is the most useful comparison available, because the alternatives come from overlapping author groups and therefore represent deliberate design choices rather than accidents. moscot performs optimal transport for temporal, spatial and spatio-temporal single-cell mapping (Klein et al. 2025). The difference in approach is the mathematical object. Optimal transport couples two distributions of cells by finding a transport plan that minimises a cost, which makes it the natural choice when you have two or more measured time points and you want to know how mass moves between them. CellRank builds a Markov chain on a single snapshot and asks about its long-run behaviour, which makes it the natural choice when you have one snapshot plus a directional signal inside it. moslin extends the optimal transport line to lineage barcodes (Lange et al. 2024), which is a different kind of directional evidence than velocity. VeloVI, part of scvi-tools, estimates RNA velocity with variational inference and uncertainty quantification (Gayoso et al. 2024); that is a prior generator, not a competitor, and pairing it with CellRank is a coherent pipeline because uncertainty-aware velocity addresses exactly the noisy-prior weakness described above. RegVelo jointly learns gene regulation and velocity (Wang et al. 2026), which is another upstream option.

Maintenance, licensing and the cost of staying current

CellRank is BSD-3-Clause, a permissive licence that allows modification and redistribution provided the copyright notice and disclaimer are retained. That is a low-friction choice for both academic and commercial users, and it is consistent with the rest of scverse. This is not legal advice; read the licence text and your institution's policy if you plan to redistribute a modified version. Maintenance signals in the supplied material are positive but should be read carefully. The repository is not archived, the last push is dated 2026-09-07, and three releases landed in June 2026, which indicates an actively maintained project rather than one in wind-down. The CI, documentation and coverage badges in the README point to test and docs infrastructure, though the README does not state what the coverage threshold is. The upgrade cost is the part to plan for. CellRank 2 is not a continuation of CellRank 1 in the sense of a drop-in patch; the README refers to two separate manuscripts and a citation guide with different entries, which tells you the API and the underlying model changed between major versions. If you have analysis code written against CellRank 1, budget for a port rather than a version bump. The transitive dependency on pyGPCCA is the other thing to watch: it is a separate repository, so a break there propagates into CellRank.

What to check before you build a pipeline on it

The README does not document the kernel API, the estimator choices, or the AnnData keys each method reads, so the documentation is the actual entry point, not the landing page. Three checks are worth doing before you commit. First, confirm which prior your dataset can support. If you have spliced and unspliced counts, velocity is available. If you have sampled time points, those are a listed prior. If you have neither and no labelling experiment, you are outside the intended input space. Second, decide which estimator you will use for initial and terminal states before running anything, because that choice determines which cells get reported as the endpoints, and the README does not tell you how to pick. Third, install in a clean environment and confirm pyGPCCA resolves on your platform, since the README names it as the backend. The honest summary is that CellRank is a well-maintained, permissively licensed implementation of a method whose output quality is bounded by an input you supply. The package is not the hard part. Choosing and validating the prior is.

Editorial conclusion

Adopt CellRank if you already work in scanpy and AnnData and you have at least one usable directional prior, such as RNA velocity, a pseudotime, experimental time points or metabolic labels. Do not adopt it if your data has no such prior and no way to build one, because the kernel step is the whole method. Before committing, verify three things on your own dataset: that your AnnData object carries the layers or obs columns the chosen kernel reads, which estimator you intend to use for the initial and terminal states, and whether the GPCCA backend installs cleanly on your platform.

Official sources

1. License: BSD-3-Clause
2. Project website
3. README
4. Releases
5. scverse/cellrank on GitHub