Habitat-Lab After Meta: What v0.3.4 Leaves You
A modular high-level library to train embodied AI agents across a variety of tasks and environments.
At a glance
- What is it?
- Habitat-Lab is a modular high-level library for training embodied AI agents in indoor environments, built on top of Habitat-Sim. The README now states that beyond v0.3.4 Meta internal teams no longer maintain it, so the decision is less about capability and more about who inherits the code.
- Who is it for?
- Adopt Habitat-Lab if you need a task abstraction layer over Habitat-Sim and can accept that the README declares no official active development past v0.3.4, which means you are forking rather than consuming. Do not adopt it if you need a maintained dependency with a support path, or if your work does not involve indoor embodied tasks.
- 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 131 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 gap Habitat-Lab fills between a simulator and a training loop
Habitat-Sim renders and steps a 3D indoor scene. It does not decide what counts as success, how an episode ends, what sensors an agent carries, or how a policy is trained and scored. Habitat-Lab is the layer that answers those questions. The README describes it as a modular high-level library for end-to-end development in embodied AI, designed to train agents on a variety of embodied AI tasks in indoor environments. The audience is research groups working on navigation, rearrangement, instruction following, question answering, human following, and similar tasks, plus anyone who needs to define a novel task rather than consume an existing one. The README lists flexible task definitions, diverse embodied agents including commercial robots and humanoids, single and multi-agent training via imitation or reinforcement learning, and human-in-the-loop interaction as the four supported feature areas. If your work is outdoor, driving-based, or does not involve an agent acting inside a scene, this is the wrong library and there is no partial fit.
Task definitions, agents and sensors as configuration, not code
The architecture visible in the repository is a layering. Habitat-Sim sits underneath as the core simulator, and Habitat-Lab wraps it. Agents are configured and instantiated rather than hand-written, with their sensors and capabilities specified as part of the configuration. Tasks are defined declaratively, which is what allows the same training machinery to cover navigation, rearrangement, instruction following, question answering and human following without a separate codebase per task. Training algorithms sit above that: the README names imitation learning, reinforcement learning, and SensePlanAct pipelines as the no-learning case. Evaluation runs against standard metrics defined per task. The package split mirrors this. Installing habitat-lab gives you the core, and habitat_baselines is a separate installable that carries the additional requirements for the training algorithms. That split is deliberate: if you only need to define and step through a task, you do not pull in the baseline training stack. The repository also documents a ROS-X-Habitat integration, though the README gives no detail beyond its presence in the table of contents.
Installation: conda for the simulator, pip for the library
The README gives a four-step install. First, a conda environment with Python 3.9 and cmake 3.14.0: conda create -n habitat python=3.9 cmake=3.14.0, then conda activate habitat. The README states the requirement as python>=3.9 and cmake>=3.14. Second, install the simulator through conda, not pip. For bullet physics the command is conda install habitat-sim withbullet -c conda-forge -c aihabitat. The README notes that for newer features added after the most recent release you may need aihabitat-nightly instead, and points to Habitat-Sim's own installation instructions for detail. Third, clone the stable branch and install the core in editable mode: git clone --branch stable https://github.com/facebookresearch/habitat-lab.git, cd habitat-lab, pip install -e habitat-lab. Fourth, add the baselines: pip install -e habitat-baselines. Note the branch name in that clone command. It is stable, not main, and the README presents it as the path to the stable version. The conda channel aihabitat is where the simulator binaries come from, which means your platform has to be one that channel builds for. The README does not enumerate supported platforms, so that is something to check before you start.
The maintenance warning is the headline, not a footnote
The first element in the README is a warning block. It states that beyond v0.3.4 the project is no longer receiving official active development or maintenance by Meta internal teams, and invites users to continue forking and developing the software independently. The release history is consistent with a project winding down: v0.3.2 in October 2024, v0.3.3 in January 2025, then v0.3.4 in May 2026. That is roughly sixteen months between the last two releases, and v0.3.4 is the terminal point named in the warning. The practical consequence is that bug reports and feature requests have no upstream owner. Security fixes, dependency bumps for Python or CUDA, and compatibility work for newer Habitat-Sim builds all become your problem. This is not a reason to avoid the library automatically. It is a reason to price the fork into your decision. A group that already has the simulator stack working and needs a task abstraction layer may find the frozen state acceptable. A group building a product on top of it, or a group with no capacity to maintain a fork, should look elsewhere.
Where the documentation leaves you guessing
The README is an entry point, not a reference. It links to aihabitat.org/docs/habitat-lab for documentation, and the repository has a table of contents entry for debugging an environment issue, but the README text supplied here does not expand on what that section contains. Datasets and baselines appear as sections without accompanying detail. The practical implications: you will need the external documentation site for anything beyond installation, and for the debugging path specifically, the README signals that environment issues are a known category of problem without describing the remedy. The citation block is unusually prominent, asking users to cite the Habitat 1.0, 2.0 and 3.0 papers, which tells you the intended use is academic research output rather than production deployment. That framing matters for the maintenance question. A research artifact that stops being maintained after its final paper is a normal lifecycle. A library positioned as infrastructure is not.
Forking versus switching: what the alternative actually changes
The realistic alternative for a team that needs maintained embodied AI infrastructure is to build directly on Habitat-Sim, or to move to a simulator stack that carries its own task layer and an active release cadence. The difference in approach is where the abstraction boundary sits. Habitat-Lab gives you task definitions, agent configuration, standard metrics and baseline training algorithms as a package you install. Building on Habitat-Sim alone means writing your own episode termination logic, your own success criteria, your own sensor configuration plumbing and your own evaluation harness. That is more work, but it is work you control and can keep current as the simulator evolves. The trade is between inheriting a frozen task layer and owning a thinner one. If your task is close to one Habitat-Lab already defines, the inherited layer saves substantial effort and the fork is a small tax. If your task is novel in its structure rather than its parameters, you were going to write most of that layer anyway, and the dependency buys you less than it appears to.
Licence and the cost of owning a fork
The repository is MIT licensed, per the badge and the LICENSE file referenced in the README. MIT permits modification and redistribution with the licence and copyright notice preserved. It does not oblige you to publish your changes, which is what makes the independent-fork path in the warning practical. This is not legal advice, and the terms that govern your use are the ones in the LICENSE file in the repository, which you should read rather than the badge. On maintenance cost: the material supports the conclusion that upstream maintenance has ended, but it does not tell you how much work a fork entails. The dependency surface is two packages plus the conda-installed simulator, and the README distinguishes a stable branch from main, which suggests the stable branch is the intended consumption point. The upgrade path that matters is Habitat-Sim, since Habitat-Lab is built on it and the README already flags aihabitat-nightly as the channel for features newer than the latest release. If Habitat-Sim continues to move, Habitat-Lab's compatibility with it becomes a recurring cost you own.
Editorial conclusion
Adopt Habitat-Lab if you need a task abstraction layer over Habitat-Sim and can accept that the README declares no official active development past v0.3.4, which means you are forking rather than consuming. Do not adopt it if you need a maintained dependency with a support path, or if your work does not involve indoor embodied tasks. Before committing, verify that the conda package for habitat-sim withbullet resolves on your platform, confirm whether you need aihabitat-nightly for the features you plan to use, and check that the MIT licence terms in the repository LICENSE file match how you intend to redistribute the code.
Community notes