skrl: A Modular RL Library That Runs the Same Agent Code on PyTorch, JAX and Warp
Modular Reinforcement Learning (RL) library (implemented in PyTorch, JAX, and NVIDIA Warp) with support for Gymnasium/Gym, NVIDIA Isaac Lab, MuJoCo Playground and other environments
At a glance
- What is it?
- skrl is an MIT-licensed reinforcement learning library built around modularity and readable algorithm code, with three interchangeable backends and loaders for Isaac Lab and MuJoCo Playground. Its scope is broad and its release cadence is fast, which is exactly where the adoption questions start.
- Who is it for?
- Adopt skrl if you are training RL agents against Isaac Lab, MuJoCo Playground, Gymnasium or PettingZoo and you want to switch between PyTorch, JAX and Warp backends without rewriting the training loop, or if you need several agent scopes running in one process.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem skrl addresses: one training loop, three numerical backends
Most RL codebases are welded to a single tensor framework. A PPO implementation written against PyTorch uses torch optimizers, torch distributions and torch checkpointing throughout, and porting it to JAX means rewriting the update step, the parameter handling and the random number generation. skrl's stated design goal is modularity, readability, simplicity and transparency of algorithm implementation, and its headline structural claim is that it is implemented in PyTorch, JAX and NVIDIA Warp. That is the specific problem it solves: the algorithm and the training loop stay put while the backend underneath them changes. The intended audience is engineers working on robot learning and control, which the topic list confirms: isaaclab, isaacsim, brax, flax, mujoco-adjacent tooling, multi-agent. This is not a library aimed at tabular RL tutorials or at people who want a single import that trains an agent on CartPole. It assumes you already have an environment and a reason to run many parallel copies of it.
Scoped multi-agent training is the feature that separates skrl from a plain algorithm collection
The README describes a capability that is easy to skim past: agents can be trained simultaneously by scopes, defined as subsets of environments among all available environments, and those scopes may or may not share resources, all within the same run. Concretely, that means one process can hold several agents, each bound to a different slice of the vectorized environment pool, instead of forcing you to launch separate processes and reconcile checkpoints afterwards. Resource sharing between scopes is described as optional, which implies you can also keep them isolated. The trade-off is conceptual overhead: you now have to reason about which scope owns which environments and which resources are shared, and that mapping is a design decision the library does not make for you. For single-agent work this machinery is dead weight, and the documentation's own framing (refer to the docs for details and examples) suggests the scoping model is where most of the reading effort goes. The README does not quantify the cost of scope coordination, and I cannot state one.
Environment interfaces: Gym, Gymnasium, PettingZoo, ManiSkill, Isaac Lab, MuJoCo Playground
skrl's environment coverage is the second half of its pitch. The README lists support for OpenAI Gym, Farama Gymnasium and PettingZoo, ManiSkill, and says it can load and configure NVIDIA Isaac Lab and MuJoCo Playground environments. The distinction between supporting an interface and loading and configuring an environment matters. Gymnasium and PettingZoo are interfaces you implement against; Isaac Lab and MuJoCo Playground are concrete simulation stacks with their own configuration formats, and skrl ships loaders for them. If you are already inside Isaac Lab, that loader is likely the reason you are reading about skrl at all. If you are on a custom simulator that exposes a Gymnasium-compatible API, skrl will work, but you get none of the loader convenience and you carry the full dependency surface for no benefit. Note also that the README's coverage list is not a compatibility matrix: it does not state which Isaac Lab or MuJoCo Playground versions are supported, so version alignment is something you must confirm in the documentation rather than infer from the repository description.
Getting it running: pip install, then the documentation's example scripts
The README is deliberately thin on setup. It gives one installation path, the PyPI package, referenced by the pypi badge pointing at pypi.org/project/skrl, and then repeats a single instruction: refer to the documentation for details and examples, at skrl.readthedocs.io. The practical sequence is a pip install of skrl followed by working from the example scripts in the documentation, since the README provides no runnable training snippet, no config keys and no CLI invocation of its own. That is a real friction point for evaluation: you cannot judge the API surface from the repository front page. It also means the backend choice is not visible from the README, even though the CI workflows are named tests-torch, tests-jax and tests-warp, which tells you the three backends are tested separately rather than through one shared suite. What you should verify first in the docs is how the backend is selected for a given example and what extra dependencies each backend pulls in, because a Warp install and a JAX install will not have the same requirements. The README does not enumerate those extras.
Where skrl is the wrong tool, and what the release history implies
Two limitations are visible without running anything. First, the algorithm catalogue is not stated anywhere in the README. The description promises transparency of algorithm implementation, which is a claim about how the code reads, not about how many algorithms exist. If your requirement is a long list of off-the-shelf algorithms, you cannot confirm from this material that skrl has them, and you should check the documentation's algorithm index before adopting. Second, the project moves quickly and says so: the README carries an explicit note that it is under active continuous development and directs readers to the develop branch or its documentation for the latest updates to be released. The release timestamps back that up. 2.1.0 is dated 2026-05-11 and 2.0.0 is dated 2026-04-08, roughly a month apart, following 1.4.3 in March 2025. A major version bump followed within weeks by a minor release means the 2.x API was still settling. For a research group that pins versions and reads changelogs, that is fine. For a team that wants to install once and forget, it is a maintenance commitment, not a one-off setup.
Alternatives: Stable-Baselines3 versus skrl's backend-agnostic design
The obvious comparison is Stable-Baselines3, the standard starting point for Gymnasium-based RL in Python. The difference in approach is structural rather than a matter of quality. Stable-Baselines3 is PyTorch-only and organized around a curated set of implemented algorithms with a stable, heavily documented API; you pick an algorithm, point it at a Gymnasium environment, and it runs. skrl is organized around the separation between algorithm, backend and environment, which is what lets the same agent code target PyTorch, JAX or Warp, and what makes the scoped multi-agent training model possible. If your work is single-backend and single-agent, Stable-Baselines3 asks less of you and its API stability is a genuine advantage. skrl earns its extra structure when the backend is a variable (for example, moving a policy to Warp for simulation-heavy workloads) or when the environment stack is Isaac Lab or MuJoCo Playground. Choose on that axis, not on algorithm counts, which this README does not let you compare.
Licence, maintenance and what a version bump costs you
skrl is MIT-licensed, per the repository metadata and the license badge. MIT is permissive: it allows commercial use, modification and redistribution with the licence and copyright notice retained. That is a low-friction position for industrial robotics work, and it is a meaningful contrast with RL stacks that ship under copyleft terms. This is a description of the licence, not legal advice; confirm obligations with your own counsel. On maintenance, the material supports a few concrete statements and no more. The repository is not archived, the default branch is develop rather than main, and the last push recorded is 2026-09-10. The README asks users to always run the latest version, which is unusual guidance for production users and consistent with a project that expects its consumers to track changes closely. The upgrade cost is therefore not zero: with 2.0.0 and 2.1.0 a month apart, plan on reading release notes between minor versions and pinning an exact version in your environment file rather than floating. The material does not state a deprecation policy or a support window, so treat API stability as unverified.
Editorial conclusion
Adopt skrl if you are training RL agents against Isaac Lab, MuJoCo Playground, Gymnasium or PettingZoo and you want to switch between PyTorch, JAX and Warp backends without rewriting the training loop, or if you need several agent scopes running in one process. Do not adopt it if you want a large third-party algorithm catalogue or a library whose API has stopped moving; the README states the project is under active continuous development and points users at the develop branch, and the 2.0.0 release landed roughly a month before 2.1.0. Before committing, verify three things against the documentation for your target version: which algorithms are implemented in the backend you intend to use, whether your environment's interface is covered by a loader, and whether your Isaac Lab or MuJoCo Playground version matches the one the docs were written against.
Community notes