Talos: parameter sweeps that stay inside your own training loop

Two generations, one repository

The first line of the README is a migration notice, and it is unusually specific. Talos has moved to its next generation, Talos 2 is in active maintenance, and the established Talos 1.x series will remain supported at least until 2028. If you want the latest 1.x release, the notice gives you the exact command and tells you to use a separate Python 3.10 or 3.11 environment.

The same notice then discloses a defect that most projects would have quietly fixed and forgotten. It names the last confirmed report of mislabeled experiment results as issue 439, opened on 11 December 2019, affecting CSV parameter columns on Python 3.5. Putting a date on a known bug and explaining which generation is affected is the single most credible sentence in this README, because it tells you the maintainers track correctness claims rather than assume the fix landed.

Both lanes are installable:

python -m pip install 'talos[tensorflow]'
python -m pip install 'talos[keras,tensorflow]'
python -m pip install 'talos[torch]'

for the current generation, and

python -m pip install 'talos==1.4' 'ipython<9'

for the legacy one. The `ipython<9` constraint exists because of the plotting dependency, and the README states that the unchanged 1.4 wheel is verified against Python 3.11 and IPython 8.39.0. That is a specific, checkable claim rather than a support range.

The repository description is two frameworks out of date

The GitHub repository description reads Hyperparameter Experiments with TensorFlow and Keras. The README's own subtitle reads Hyperparameter experiments with Keras, TensorFlow and PyTorch, and the packaging metadata describes it as reproducible parameter sweeps for Keras, TensorFlow and PyTorch, with keywords covering all three.

Both statements are current in their own contexts. The description predates PyTorch support and was never updated, which is unremarkable for a repository field. The consequence is that anyone searching GitHub by the project name finds a description that undersells it by a third of its scope, and PyTorch users have no reason to look unless they read further.

The keyword list in `pyproject.toml` is the accurate one: hyperparameters, parameter-sweep, keras, tensorflow, pytorch, reproducibility. That last keyword is the interesting addition. It signals that the project's centre of gravity has moved from searching a space to being able to describe what you searched and recover it later.

The tree itself shows how much governance sits around the package. Alongside `talos/`, `docs/`, `examples/` and `tests/`, there is `AGENTS.md`, `CLAUDE.md`, `GOVERNANCE.md`, `governance.yml`, a `governance/` directory, `MAINTAINERS.md`, `TALOS_REPO_SPECIFICS.md`, `THIRD_PARTY.md`, `SECURITY.md`, `SUPPORT.md`, `CONTRIBUTING.md`, `CITATION.cff`, `CITATION.bib` and a `NOTICE`. Two agent instruction files and a governance directory in a Python package is not a layout you see in most research libraries, and it tells you the project is run with an unusual emphasis on process.

What Talos actually adds around your model

The framing is that you keep control of your model and its training code, and Talos records the experiment around that work. That constraint is the product. You are not asked to restructure a Keras model into a Talos wrapper; you write your existing `fit` call and let Talos supply the candidate parameters.

The interfaces named in the README are the familiar ones from Talos 1: `Scan` for the sweep, `Analyze` and `Reporting` to inspect results, and `Predict`, `Evaluate`, `Deploy` and `Restore` for using what the sweep produced. Grid and sampled searches are both supported, along with reducers, custom strategies and local control files.

Three of the listed features are about reproducibility rather than search. Content addressed manifests mean a trial's configuration is identified by its content, so a manifest cannot silently change under you. Trial histories record source and data identities alongside checkpoints and intervention records, which is the difference between knowing a run happened and knowing what was in it. And trained model recovery works through explicit factories or custom objects where the framework requires them, which is the honest way to handle the fact that a pickled Keras model often will not load without the class it was defined with.

Two execution shapes are offered. A notebook with `Scan` is the low friction path. A single Python file plus a manifest plus the CLI is the reproducible path, and the README points at `examples/sfd/` for one per framework and at `docs/SFD_and_CLI.md` for the walkthrough. The examples directory also keeps the original notebooks, including one on recovering best models from an experiment log.

Where the dependency floors split the two lanes

The packaging metadata declares `requires-python = ">=3.10,<3.14"` and lists classifiers for Python 3.10 through 3.13. The README then adds a qualification that matters: the core supports 3.10 to 3.13, but modern Keras and TensorFlow require Python 3.11 or newer. So the framework extras quietly raise the floor above what the top line advertises, and the two facts are reconciled only in prose.

The extras themselves are the clearest statement of the current generation's scope. Keras is `keras>=3.15,<4`, TensorFlow adds `tensorflow>=2.20,<3` plus `protobuf>=6.33.5,<8`, and PyTorch is `torch>=2.13,<3`. Framework imports are kept optional, so a core install does not drag in all three.

The legacy extra is where the fork in the road becomes real. `legacy-tensorflow` pins `tensorflow==2.14.1`, `keras==2.14.0+autonomio.1`, `protobuf==4.25.9+autonomio.1` and `numpy>=1.26,<2`. Two things follow. The `+autonomio.1` local version identifiers on the Keras and protobuf wheels mean you are not getting stock PyPI artifacts; they are builds from the maintainers, which the v2.0.7 release notes say are hash-pinned in the legacy extra and in CI. And the `numpy>=1.26,<2` ceiling places the legacy lane on NumPy 1, while the core dependency allows `numpy>=1.26,<3`, meaning Talos 2 works against NumPy 2. That is not a detail you discover gracefully halfway through an experiment.

One small oddity is worth noting if you plan to work on the project. `requirements.txt` contains a single editable line, `-e .[test,plots,samplers]`, and the `samplers` extra in the manifest is an empty list. Whatever sampler support exists in Talos 2, it is not coming from a declared dependency there.

Release engineering that publishes on merge

Three releases, v2.0.7, v2.0.8 and v2.0.9, were all published on 2026-10-05 within about three hours. The repository was pushed on 2026-10-06 and has 1634 stars, 264 forks and 14 open issues.

Reading the release notes explains the cadence. v2.0.8 changed the release process itself: each new reviewed Talos version is published automatically after successful protected-master CI, without a separate release approval, and the exact CI-tested distributions are reused for signing and publication rather than being rebuilt. It also requires dependency bot version and changelog bumps, so every merge has a unique release identity, and it rejects foreign or failed CI evidence and skips superseded master heads. v2.0.9 is documentation only, and its first line is a nice detail: it replaced a README stability attribution with the dated, linked CSV result labeling defect, which is the same disclosure that now leads the README.

v2.0.7 is the security-flavoured one, describing backported legacy framework and documentation dependency fixes that preserve original model predictions while keeping explicit trusted deserialization, rejection of vocabulary config reads when safe mode is unset, and a requirement for hash-pinned owned Keras and protobuf wheels. Requiring a fresh report for each executed upstream audit, and rejecting unproved advisory dispositions, is a level of supply chain hygiene that most research projects never reach.

The badge set matches. The README carries an OpenSSF Best Practices badge, which the v2.0.8 notes identify as Silver, alongside a statement coverage badge, an OpenSSF Scorecard badge and a CI badge. For a library whose output is a table of experiment results, having the provenance of the package itself be inspectable is not a small thing.

Reading the migration path instead of the feature list

If you are arriving from Talos 1, the documentation to read is `docs/Migration.md`, and the README links it from three separate places: the opening notice, the support table, and the key features section pointing at the workflow overview and interface reference.

That linking density is a signal in itself. The README also documents where to go for each kind of question in a table: docs and the migration guide for troubleshooting, the issue tracker for bugs and feature requests and usage questions, and a separate security policy for vulnerabilities. It then specifies what a useful issue contains, which is worth repeating because it is a higher bar than most projects set: your Talos and framework versions, the smallest reproducible callback or SFD, the exact command and traceback, and the expected result. A helper guide spells the format out.

There is history preserved rather than rewritten. The README links the original short example as a gist, the original workflow illustration wiki page, and a pinned commit of the historical README that preserves the original Field Report reference. It also states that research citations should name the software version used, that Talos has been cited in at least a thousand research papers, and that the citation files exist for that purpose in both BibTeX and CFF form.

For a new user the most efficient starting point is `examples/keras_to_talos.py`, which the README describes as showing ordinary Keras training next to a Talos parameter sweep. Seeing the minimal diff between the two is faster than reading the interface reference, and the first-sweep guide at `docs/Guides/Quickstart.md` is the documented next step.

Editorial conclusion

Talos 2 is a well-run project with the kind of metadata discipline most research software lacks: hash-pinned legacy wheels, a CI gate that refuses to release without dependency bot bumps, an OpenSSF badge, content addressed manifests and source and data identities recorded per trial. That is worth having if your parameter sweeps are the part of your work that has to be defensible. The choice in front of you is between the two generations, and they differ more than a version number suggests. Talos 2 wants Python 3.10 to 3.13, modern Keras 3, and NumPy 2, while the 1.4 lane pins Python 3.11 with IPython 8, TensorFlow 2.14.1, NumPy 1 and a custom built Keras wheel. Start from `examples/keras_to_talos.py` to see the minimal diff, and read `docs/Migration.md` before porting existing sweeps.

Frequently asked questions

Official sources

1. autonomio/talos on GitHub
2. License: MIT
3. Project website
4. README
5. Releases