Tensorforce's README declares it unmaintained, its dependency file pins one TensorFlow version, and its setup.py ends a check with a truncated exception name

The README announces it is finished, and the branch has commits from last month

Eight badge links, and then one bold sentence: this project is not maintained any longer.

That sentence sits above everything else in the file, above the introduction, above the design choices, above the installation section. It is not a status badge that might be stale. It is a declaration in the body of the document.

The dates around it are in tension with it. The newest release is 0.6.5, published 2021-08-30, with two earlier ones in the same year. The last push to the default branch master is dated 2026-09-02, about a month before this repository was inspected.

So the project has two timelines: a published history that stopped in 2021 and a branch that has received commits as recently as last month. Nothing in the repository explains what those commits are, and the file's own links include an update-notes document and a roadmap, neither of which is quoted.

For anyone deciding whether to use this, the honest reading is that the code is frozen in its published form and the branch is receiving something that is not a release.

One dependency is pinned to an exact version and another to a range that closes in the next minor

The dependency file has nine entries, and two of them are more constrained than the other seven.

The framework itself is pinned with an equality sign to a single TensorFlow version, 2.12.1. Not a floor, not a compatible-release range: one version. The numeric library is pinned with a compatible-release operator to 1.21.5, which admits patch updates inside that minor and refuses the next one.

The rest are floors with occasional ceilings: a graphics library at 3.6.0 or newer, a plotting library, two serialisation libraries, an imaging library, a progress bar. One carries both a floor and a ceiling, the gym environments package, at or above 0.21.0 and strictly below 0.23.

That last upper bound matters more than it looks. Environment packages rename and restructure their step functions between versions, so a ceiling is the kind of constraint you only set when an upgrade breaks you.

Together these pins mean the installable configuration is a single point in time. Changing any of them is a code change, not a dependency bump, which is a coherent position for a research library and an awkward one for anything that has to keep building.

The quickstart example ends at a comment that says Train

The quickstart is the section a new user reads first, and it stops one comment before doing anything.

from tensorforce import Agent, Environment

# Pre-defined or custom environment
environment = Environment.create(
    environment='gym', level='CartPole', max_episode_timesteps=500
)

What is present is well chosen: an environment created from a named family and a level with a timestep ceiling, and an agent created from a configuration dictionary rather than from constructor arguments, with memory size, an update unit and batch size, an optimizer type and learning rate, a policy whose network is chosen automatically, a training objective, and a reward estimator with a horizon.

What is missing is the training call. The last line of the block is a comment reading Train, and nothing follows it.

The line exists elsewhere. The example directory contains a quickstart file, and the release checklist inside setup.py runs that file as a smoke test after uploading. So the missing line is available, just not in the place a reader arrives first.

setup.py carries the release runbook as its docstring and ends a check with a truncated name

The packaging file is two things: a licence header, a Python-version guard, and a module docstring that is a release checklist.

The docstring is the project's entire release process, written as a numbered-by-comment sequence of shell commands: build the documentation, upgrade the full requirements file, update the requirements file and the packaging file, check the before-update notes, bump the version string in the package initializer and in the update notes, delete the build, distribution and generated documentation directories, upgrade the packaging tools, build a source distribution and a wheel, upload to a test package index, activate a fresh environment, install from the requirements file, install from the test index, import the package and print its version, run the quickstart file, deactivate, then commit, push, and finally upload for real.

And then the guard.

if sys.version_info.major != 3:
    raise NotImplementedE

The exception name is cut off. It is missing its final letters, and as written it names nothing that exists in the standard library.

That is the entire version check for a package whose whole design premise is that it requires Python 3, and the release section two screens above it is more precise about which Python is expected.

The release process uploads twice and waits for a retired CI service before the real upload

Two lines in that checklist are worth reading on their own.

The first is a comment placed between the test upload and the real upload, and it says to wait a while to check that the continuous integration service is not failing right away, with installation and the first tests named as the things to watch.

The second is that the real upload is followed by a comment whose entire content is to fix the GitHub release afterwards.

So the documented process is: build, upload to the test index, create a fresh environment, install from the test index, confirm the version string, run the example, commit and push, wait for the CI service to settle, upload the real files, and then fix the release page by hand.

Two observations. The wait is a manual pause rather than a pipeline gate, so it depends on a person noticing. And the continuous integration service being waited on is the one named in the badge links, which is not the service a repository with a workflows directory would use today.

The last item on the list, fixing the release by hand, is the most honest line in the file: the artefacts are automated and the announcement is not.

Eight badge links, two of which are the same package index, and one sponsorship link to a person

The header block is a list of links rather than a set of badges, and reading it tells you what the project considers its audience.

There is the documentation site, a chat channel, a continuous integration service, and the package index, which appears twice in the same row. Then the licence, then two funding links.

The duplicate is harmless but odd, since a header where one target occupies two slots is usually the residue of two badges that used to differ.

The funding links are the more interesting pair. One goes to a GitHub sponsors page belonging to an individual, not to the project organisation, and the other to a collective donation page belonging to a team account. So there is one person collecting money for this and one team account, and the README does not say which is current.

Everything else in the header points outward to infrastructure rather than to the project itself: no website, no blog, no announcement channel. For a framework, the package index and the documentation site are the whole presence.

Three design choices, and one of them admits it diverges from the papers

The introduction lists three high-level design choices, and the third and fourth sentences of the file are where the project's real position is.

The first is a modular, component-based design in which feature implementations strive to be as generally applicable and configurable as possible, potentially at some cost of faithfully resembling details of the introducing paper.

That parenthetical is the whole sentence. The framework is built so components are reusable and configurable, and it says outright that this is traded against reproducing a published method's details exactly. For a research library that is the central decision, stated by the authors rather than discovered by a user.

The second is the separation of the algorithm from the application: algorithms are agnostic to the shape of inputs and outputs and to how the application is interacted with. The third is that the entire reinforcement learning logic, control flow included, is implemented inside the framework itself, to make computation graphs portable independently of the application language and to ease deployment.

Two consequences follow. The component layer is meant to be recombined, so the examples directory shows three different environment interfaces. And because the graph is written in the framework rather than around it, the execution modes section lists parallelised execution as a first-class feature.

The documentation tells you when not to use a GPU

Two notes in the installation section are about judgement rather than steps, and both are unusual in a README.

The first is about hardware. It says that unlike supervised deep learning, reinforcement learning does not always benefit from running on a GPU, depending on the environment and the agent configuration, and that for environments with low-dimensional state spaces, meaning no images, it is worth trying to run on the CPU alone.

The second is about installation. It says that at the time of writing, the deep learning framework itself, a core dependency, could not be installed directly on M1 Macs, and points at a section of the documentation for a workaround.

Both notes tell you the project has been run on real hardware and real environments by the people writing it. The M1 note is the more dated of the two: it describes a moment when a dependency had no wheel for a processor architecture, which is exactly the kind of sentence that becomes quietly wrong and then quietly obsolete.

Neither note is a step you follow. Both are judgements you are being handed, which is the most useful thing a short README can do.

Editorial conclusion

Read Tensorforce as a reference implementation rather than as a dependency. Its value is that the whole reinforcement learning logic, control flow included, lives in TensorFlow, which makes the computation graph portable across languages and inspectable in a way a Python-side loop never is. That is a real design, and the three choices behind it are stated plainly. Three things to know before you build on it. The maintenance position, which the project states itself: the README says in bold that it is not maintained any longer, the newest release is from 2021, and the branch has seen commits in the last month, so decide which of those three signals governs you. The dependency ceiling, because TensorFlow is pinned to one exact version and a numeric library is pinned to a compatible-release range that closes before the next minor. And the shape of a run, because the environment interface has three variants in the example directory and the quickstart in the README stops one comment before the interesting line.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. tensorforce/tensorforce on GitHub