The TensorFlow Model Garden is four directories with four different answers to who maintains them

Four directories, four ownership stories, and one of them holds no code

The repository is a container, and the README describes its four top-level directories as having four different relationships to you. `official` is a collection of example implementations for state of the art models written against the latest TensorFlow 2 high level APIs, officially maintained, supported and kept current with those APIs by TensorFlow itself, and described as reasonably optimized for fast performance while still being easy to read. Its capabilities are explained in a separate guide on tensorflow.org. `research` is a collection of research implementations in TensorFlow 1 or 2, written and supported by researchers rather than by the project. `community` is not code at all: it is a curated list of GitHub repositories that contain models powered by TensorFlow 2, so nothing in it is maintained here and none of it arrives as something you can import. `orbit` is a library rather than a model collection, and it is the one you are meant to fork. The tree also holds `docs/`, `tensorflow_models/`, `AUTHORS`, `CODEOWNERS`, `CONTRIBUTING.md`, `ISSUES.md`, `SECURITY.md` and `CODE_OF_CONDUCT.md`, two of which the directory table never mentions.

The pip package trails master, and the only way past that is a build made daily

Installing from pip gets you the stable package, and the README attaches a warning to it directly: tf-models-official may not include the latest changes on the master branch of this repository.

pip3 install tf-models-official

The way past that is a second package, tf-models-nightly, which the README says is created daily automatically.

pip3 install tf-models-nightly

So there are two tracks and they are not interchangeable in practice. The stable one is what the releases page covers, and the newest of those is v2.20.0, published on 2026-02-11. The nightly one is built from master every day, which means the code you get can change between two pip invocations on consecutive days, and it carries no version number you can quote in a bug report other than the date you installed it. The consequence for a team is that pinning is the whole game: an environment on the stable package is pinned to a state of the code from February 2026, while an environment on nightly has no pin at all and inherits whatever master looked like when the build ran.

PYTHONPATH takes the clone root, not the tensorflow_models folder

Cloning is the second installation method, and it is three steps with one sharp edge in the second of them.

git clone https://github.com/tensorflow/models.git

Step two puts a directory on the Python path:

export PYTHONPATH=$PYTHONPATH:/path/to/models

That path ends at `models`, which is the name of the clone directory, and the ending matters. The top-level tree puts the importable package one level further down, in `tensorflow_models/`, so pointing the variable at `/path/to/models/tensorflow_models` puts the package's own directory on the path instead of its parent, and the import will not resolve. Windows needs a different spelling of the same step under PowerShell:

$env:PYTHONPATH += ":\path\to\models"

A Colab notebook needs it done from inside Python, because there is no shell there to export into:

import os
os.environ['PYTHONPATH'] += ":/path/to/models"

Three spellings of one environment variable, and the repository supplies all three with no check that you used the right one for the situation you are in.

requirements.txt is hardcoded to official/, and nlp drags in a nightly text package

Step three of the clone method installs dependencies from a requirements file with a fixed path:

pip3 install --user -r models/official/requirements.txt

The path is not relative to what you came for. It points into `official/`, so a reader who only wants the `orbit` training loop library, or one implementation out of `research/`, still installs the official dependency set on top of their own. The `--user` flag then places those packages in your user site rather than the system environment, which adds a second place to look when an import resolves to something you did not expect. The nlp case adds another layer on top. The README says that if you are using nlp packages you should also install tensorflow-text-nightly:

pip3 install tensorflow-text-nightly

That is a nightly package being added to an environment you may have just pinned to the stable Model Garden, so the two methods do not compose into one clean setup. A stable-and-pinned environment and a current one are different environments with different failure modes, and nothing here helps you tell afterwards which of the two you built.

The newest tag is 2.20.0 from February while master moved in September

The release list is short and the gap inside it is wide. Three tags are visible: v2.20.0, named TensorFlow Official Models 2.20.0, published on 2026-02-11; v2.19.1, published on 2025-04-12; and v2.19.0_no_deps, named TensorFlow Models no-deps 2.19.0, published on 2025-03-14. Two things follow from that list. The newest tag is more than seven months older than the last push to master, which was on 2026-09-29, so the default branch and the newest release are describing different code and a `pip3 install tf-models-official` is not giving you master. And one of the three artifacts is not the same kind of thing as the others: the `_no_deps` suffix marks a build that does not pull its dependencies, which is what you want when you intend to pin TensorFlow yourself and a trap when you expected the ordinary package. The naming is not explained anywhere in the repository. The tree itself is not idle, with 77,653 stars, 44,811 forks and 1,272 open issues, but the tag cadence is what tells you which snapshot a dependency will resolve to.

TensorBoard.dev logs cover the models that happen to be suitable

Training logs are published, and the sentence that says so carries a caveat in the same clause. The README states that to improve transparency and reproducibility, training logs on TensorBoard.dev are provided for models to the extent possible, though not all models are suitable. That is the entire commitment, and it defines logs as a per-model bonus rather than a property of the repository. The consequence is that you cannot plan around them. Before you intend to compare two training runs, or hand a log link to somebody as evidence that a result is reproducible, you have to establish that the specific implementation you picked has one at all. The caveat also sits awkwardly beside the word reproducibility: a log that some models have and others lack describes a run somebody else did, not a run you can repeat on your own hardware, and nothing in the four directory descriptions says which implementations are covered. There is no per-model index of log links in the repository to check against.

The license metadata does not resolve, and the suggested citation still says 2020

Two small things about how the repository presents itself are worth knowing before you rely on either. The first is the license. The README points at an Apache License 2.0 file named LICENSE in the root of the tree, and that file is there, but the repository's own license metadata does not resolve to a named license identifier, so any tool that reads the metadata field rather than the file will come back with nothing. A compliance process that trusts metadata needs a human to open the LICENSE file. The second is the citation. The README asks you to cite the repository if you use it in research, and supplies a BibTeX entry with ten named authors and a year field of 2020. The year in that entry is several releases behind the tags listed above, so pasting it unchanged into a paper attributes the work to 2020 while the code you actually ran is 2.20.0. The author list is fixed in the same way, and the tree holds a separate AUTHORS file, which is the place to look for who has actually contributed. Contributors are pointed at a single label, help wanted:paper implementation, for turning a published paper into a runnable implementation here.

Editorial conclusion

Use the official directory when you want a state of the art implementation that someone at TensorFlow is keeping current with the TensorFlow 2 APIs, and accept that you are reading code from a tree whose newest tag is v2.20.0 while master has moved on since February 2026. Do not treat research, community or orbit as equivalents: research is maintained by its authors and may target TensorFlow 1, community holds no code at all, and orbit is a library to fork. Before you pin an environment, decide which of the two package tracks you are on, because the stable package and the daily nightly cannot be reasoned about as one thing, and check the LICENSE file yourself since the repository's license metadata does not resolve to a named license.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes