Axelrod: a Python library for reproducing iterated prisoner's dilemma work

A library built for reproducing other people's results

Axelrod is a Python research library for the iterated prisoner's dilemma, and its stated goals are unusually concrete. The README lists four: enabling the reproduction of previous iterated prisoner's dilemma research as easily as possible, creating the tool that future research in the area uses, providing as simple a means as possible for anyone to define and contribute new strategies, and emphasising readability alongside an open community that accommodates different skill levels.

That first goal sets the design centre. Reproduction means an old paper's result should be reachable from a known strategy set and a known tournament setup, not reconstructed from prose. The library answers that with what the README calls over 200 strategies, including originals and classics such as Tit For Tat and Win Stay Lose Shift, extendable through parametrisation and a collection of strategy transformers.

The audience is academic and applied game theory researchers, students learning the topic, and anyone who wants a strategy implemented once rather than twice. The README points to a peer reviewed paper introducing the library with 22 authors, published as an open reproducible framework for the study of the iterated prisoner's dilemma.

The library claims 100% test coverage, which for a project of this size is the difference between a research tool and a pile of scripts.

Matches, tournaments and population models are separate entry points

The API is organised around four things you can do with strategies, and the documentation links each to a tutorial.

A head to head match pits two strategies against each other. A tournament runs a number of strategies, and the README quick start builds one directly:

    >>> import axelrod as axl
    >>> players = [s() for s in axl.demo_strategies]  # Create players
    >>> tournament = axl.Tournament(players, seed=1)  # Create a tournament
    >>> results = tournament.play()  # Play the tournament
    >>> results.ranked_names
    ['Defector', 'Grudger', 'Tit For Tat', 'Cooperator', 'Random: 0.5']

The seed argument is the reproducibility hook. Setting it makes a stochastic tournament repeatable, which is the whole point for a library whose first goal is reproduction.

Beyond pairwise and round robin comparison, population dynamics are handled through Moran processes and an infinite population model, so the library covers evolutionary game theory as well as static rankings. Results of both matches and tournaments can be analysed and visualised, with matplotlib as the plotting dependency.

The demo_strategies list used above is a small curated subset. Running the full set is a different job, and the README links a separate repository, Axelrod-Python/tournament, that pits all strategies in the repository against each other.

Fingerprinting and morality metrics turn strategies into data

Beyond ranking, the library supports a different kind of analysis: strategy fingerprinting. The documentation describes it as a way to reproduce a number of contemporary research topics, and fingerprinting is where the strategy transformers start to matter. A fingerprint captures how a strategy responds across many opponents, so two strategies that rank similarly can still be distinguished.

The Axelrod-fingerprint repository holds fingerprints, both data and plots, of all strategies in the library, and the README shows a fingerprint visualisation for Tricky Defector. This gives you a reference corpus to compare a new strategy against before you even run a tournament, which is a real shortcut when you are deciding whether your contribution is genuinely new.

The second example is morality metrics, listed alongside fingerprinting as a reproducible contemporary research topic. A separate tutorial in the documentation covers calculating morality metrics.

Both of these are the kind of feature that determines whether a library is a simulator or a research instrument. The simulation part is table stakes; the analysis part is what makes a paper's claims checkable against the same implementation others use.

Install from PyPI or from source, and note the version gap

The README gives two installation paths. The simplest is a single command:

    $ pip install axelrod

From source, the documented route is a clone followed by a setup script:

    $ git clone https://github.com/Axelrod-Python/Axelrod.git
    $ cd Axelrod
    $ python setup.py install

That second path has an odd wrinkle. The pyproject.toml declares a hatchling build backend, while setup.py is still present and does its own dependency loading, reading requirement files from a requirements directory and globbing over them. The repository ships both, and the default branch is dev, so what you get from a clone depends on how you build it.

The Python version story is also inconsistent, and it is worth checking before you pin a version. The README says the library is tested on Python 3.8, 3.9 and 3.10. The pyproject requires-python field says >=3.6 and the classifiers list 3.11, 3.12, 3.13 and 3.14. setup.py says python_requires >=3.6 and lists 3.9 through 3.11 as classifiers. The stated test matrix and the declared support are not the same set.

The dependency list pulls in a heavy stack for what is conceptually a small numerical problem: torch, dask with dataframe support, scipy, pandas, numpy, matplotlib, cloudpickle, fsspec, pyyaml, toolz and tqdm. numpy>=2.1 and torch>=2.6.0 are the recent floors.

Where the library does not fit

The first mismatch is weight. Because torch and dask are core dependencies rather than extras, installing Axelrod to run a single match pulls in a deep learning stack and a parallel dataframe framework. For a research group already inside that world this is nothing. For a course, a small script, or a serverless function it is a poor trade for a simulation that is fundamentally loop and arithmetic.

The second is scope. Axelrod covers the iterated prisoner's dilemma and the strategies built around it. If your question is about mechanism design, evolutionary dynamics in larger populations, or learning rather than hand-coded strategies, the library is a component at best.

The third is the contribution model. The README states that all contributions are welcome and points to contributing documentation, including a separate page on the use of AI tools, which tells you the project has an explicit position on generated code. Strategy contributions are also expected to come with a paper-style description, and new features are expected to be covered by tests, which is reasonable for a library whose premise is reproducibility but adds friction for casual contributors.

Finally, the version cadence is slow and the release history shows gaps: v4.13.0 in 2023, v4.13.1 in October 2024, v4.14.0 in June 2025.

Licence, documentation and where to look next

The licence situation needs a direct look. The licence field for the project on GitHub is filed as a custom licence that GitHub cannot classify, while setup.py declares The MIT License (MIT) and the pyproject classifiers list the MIT License. The authoritative text is the LICENSE.txt file at the repository root. If your use needs a clean grant of rights, read that file rather than relying on either the badge or the classifier, and note that the data directory under axelrod/data is packaged as package data, so third-party data may carry separate terms.

Documentation lives at axelrod.readthedocs.org and is the primary source for tutorials and reference material, including the strategy index page that lists the full catalogue. Example notebooks live in the Axelrod-Python/Axelrod-notebooks repository, and a citations page lists publications that use or cite the library.

Maintenance is active at the repository level: the last push was on 2026-10-16, four days before this review, and the repository is not archived. The release tags, though, lag the commits, with the most recent being v4.14.0 from 2025-06-13. If you cite the software in a paper, cite the version you actually ran, since the tagged releases and the default branch have diverged.

Editorial conclusion

Axelrod suits researchers who need to reproduce published iterated prisoner's dilemma results or contribute a new strategy to a shared implementation, and it is the wrong tool for a quick standalone simulation or for anyone who needs a single consistent packaging path today. Before depending on it, confirm that pip install axelrod resolves the package your study expects, read LICENSE.txt for the licence terms rather than relying on the licence field on the project page, and check the version you pin against the v4.14.0 release dated 2025-06-13, since the repository moved on with a last push on 2026-10-16.

Frequently asked questions

Official sources

1. Axelrod-Python/Axelrod on GitHub
2. Issues
3. Project website
4. README
5. Releases