AllenAct: AI2's PyTorch Framework for Embodied AI Research
An open source framework for research in Embodied-AI from AI2.
At a glance
- What is it?
- AllenAct decouples tasks from environments and targets PyTorch, which is unusual among reinforcement learning frameworks. The trade-off is a research-first design, a 2022 stable release, and a licence file that GitHub reads as NOASSERTION even though the README says MIT.
- Who is it for?
- Adopt AllenAct if your research needs PyTorch and you are working in iTHOR, RoboTHOR, Habitat or MiniGrid, because task and environment decoupling is the design centre and the pre-trained models give you a starting point. Do not adopt it if your work is off-policy, continuous-control-heavy, or tied to a simulator outside that list.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 119 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 AllenAct was built to solve
Embodied AI research asks an agent to act inside a simulated 3D world: navigate a room, find an object, manipulate something. The engineering around that is repetitive. Every lab writes its own rollout loop, its own observation encoder, its own logging. When the experiment changes from PointNav to ObjectNav, or from iTHOR to Habitat, most of that code is rewritten.
AllenAct's answer is a task abstraction. The README states that tasks and environments are decoupled, which lets a researcher implement many tasks against the same environment. The intended audience is academic and industrial researchers, not application developers. The repository is maintained by the PRIOR group at the Allen Institute for AI, a non-profit, and the framework is published alongside a paper on arXiv (2008.12760).
There is a second, quieter audience: people who want to reproduce a published result. The project ships code and pre-trained models for a number of standard tasks, plus tutorials and start-up code. That matters because reproducing an embodied agent result usually means reconstructing someone else's training schedule from a methods section.
How the task and environment split actually works
The mechanism is a separation of concerns. An environment supplies observations and accepts actions. A task defines what counts as success, what reward signal the agent receives, and when an episode ends. Because those two live in different objects, the same iTHOR scene can host a PointNav task and an ObjectNav task without touching the simulator wrapper.
Training is expressed as a sequence of routines rather than a single loop. The README describes this as support for sequential algorithms and calls it trivial to experiment with different sequences of training routines, which it says are often the key to successful policies. The practical consequence is that an imitation phase can be followed by an on-policy phase in one configuration, instead of in two scripts that share a checkpoint by hand.
Losses compose the same way. The README gives the example of an external self-supervised loss combined with a PPO loss during the same optimisation step. That is a real constraint on the architecture: the training loop has to expose intermediate tensors rather than hiding them behind a single scalar return. The visualisation feature follows from the same design. First-person and third-person views, plus intermediate model tensors, are written to Tensorboard out of the box, which is only possible if the framework keeps those tensors reachable.
Action spaces are arbitrary, spanning discrete and continuous. Multi-agent tasks and algorithms are supported. The algorithm list is deliberately narrow and on-policy: A2C, PPO, DD-PPO, DAgger, and offline imitation learning. That list is a statement about what the framework is for.
What you can run: environments, tasks, algorithms
The README's support table is explicit. Environments: iTHOR, RoboTHOR, Habitat, MiniGrid, and OpenAI Gym. Tasks: PointNav, ObjectNav, MiniGrid tasks, and Gym Box2D tasks. Algorithms: A2C, PPO, DD-PPO, DAgger, and off-policy imitation.
Read that table as a boundary, not a sample. If your simulator is not on the environment list, you are writing an adapter before you write an experiment. If your algorithm is not on the algorithm list, you are implementing it inside someone else's training loop, which is a different and usually less pleasant task than implementing it in a blank file.
The presence of MiniGrid and Gym Box2D alongside three photorealistic 3D simulators is worth noting. It means a researcher can prototype a task abstraction on a cheap grid-world before paying the cost of rendering iTHOR scenes. That is a workflow choice the framework enables rather than one it forces.
Getting it running
Installation is documented at allenact.org/installation/installation-allenact/, and the README links there rather than inlining commands. The badge in the README claims Python 3.6+, while the badge alt text says Python 3.7, so the two disagree and the installation page is the authority. The framework targets PyTorch, which the README calls first-class support and describes as one of the few RL frameworks to target PyTorch.
There is no pip install line in the README, no config file schema, and no minimal training command. The tutorials page at allenact.org/tutorials/ is where start-up code lives, and the README points there twice. That is a deliberate documentation split: the repository front page sells the framework, the site teaches it. If you evaluate projects by whether the README contains a copy-pasteable quickstart, AllenAct will look thinner than it is.
Contributions go through an issue first, then a pull request from a fork. The README states that all code is subject to formatting, documentation, and type-annotation guidelines, with details in CONTRIBUTING.md, and the code style badge points at black. For a research framework that is a meaningful constraint: a patch that works but is untyped or unformatted will not merge as-is.
Where AllenAct is the wrong tool
The algorithm list is the clearest limitation. A2C, PPO, DD-PPO, DAgger and offline imitation are all on-policy or imitation-based. If your research question depends on off-policy value learning from a replay buffer, such as DQN, SAC or TD3, the framework does not list support for it. You would be adding it, and you would be adding it to a training loop designed around collecting fresh trajectories.
Environment coverage is the second boundary. iTHOR, RoboTHOR, Habitat, MiniGrid and Gym are supported. A lab working in a different simulator, or on real robot hardware, gets no benefit from the environment wrappers and inherits only the task and training abstractions.
The release timeline is the third thing to weigh. The most recent release listed is v0.5.2 from August 2022, preceded by v0.5.0 in March 2022 and v0.4.0 in June 2021. The repository is not archived and the last push is dated 2026-05-19, so development has not stopped. But the stable release you would pin is from 2022, and PyTorch and simulator versions have moved since. Treat the pinned version as the thing to test, not the main branch.
Finally, the licence. The README says AllenAct is MIT licensed as found in the LICENSE file, and the badge says MIT. The repository metadata reports NOASSERTION, which means GitHub's classifier could not confirm a recognised licence from the file itself. That is a discrepancy worth resolving before you depend on the code.
How it differs from habitat-lab
The README states that AllenAct uses some data structures from FAIR's habitat-lab, and that it builds on Ilya Kostrikov's pytorch-a2c-ppo-acktr library. Those acknowledgements frame the comparison.
Habitat is a simulator-first project. Its centre of gravity is fast rendering of 3D scenes, and Habitat is one of the environments AllenAct supports. AllenAct is a training-framework-first project. Its centre of gravity is the task abstraction and the sequence of training routines, and it treats simulators, Habitat included, as interchangeable backends alongside iTHOR, RoboTHOR, MiniGrid and Gym.
The difference shows up when you change something. In a simulator-first stack, swapping the simulator means rewriting the training code. In AllenAct, swapping the simulator is supposed to leave the task definition alone. The cost of that flexibility is an extra layer of abstraction between your code and the renderer, which is exactly the layer you have to debug when observations come back in the wrong shape.
The PyTorch choice is the other axis. The README claims AllenAct is one of the few RL frameworks to target PyTorch. If your lab is a PyTorch lab, that removes a translation step between the framework and your model code.
Maintenance, versions and the licence question
The upgrade cost is dominated by the gap between the last stable release and current dependencies. v0.5.2 shipped in August 2022. AllenAct depends on simulators, and iTHOR, RoboTHOR and Habitat all have their own release cadences. A framework pinned to 2022 that drives a simulator updated since then is a version-matching exercise, and the installation page is where the supported combinations are stated.
The repository is active in the sense that it is not archived and the last push is recent, but there is no release after v0.5.2 in the supplied material. Anyone planning to depend on AllenAct should decide in advance whether they are tracking main or pinning the release, because those are different maintenance commitments.
On licensing: the README and the licence badge both say MIT, and the repository metadata says NOASSERTION. This article is not legal advice. The concrete step is to open the LICENSE file in the repository and confirm its contents, and to check the licences of the simulators you intend to use, since iTHOR, RoboTHOR and Habitat are separate projects with their own terms. The citation block in the README asks that users cite the arXiv paper 2008.12760, which is a request rather than a licence condition.
Editorial conclusion
Adopt AllenAct if your research needs PyTorch and you are working in iTHOR, RoboTHOR, Habitat or MiniGrid, because task and environment decoupling is the design centre and the pre-trained models give you a starting point. Do not adopt it if your work is off-policy, continuous-control-heavy, or tied to a simulator outside that list. Before committing, verify three things: that the LICENSE file matches the MIT claim in the README, that your Python and PyTorch versions satisfy the installation page at allenact.org, and that the last stable release, v0.5.2 from August 2022, still builds against your simulator version.
Community notes