Gambit computes Nash equilibria from a game you build in Python

What the package covers

Gambit is the package for doing computation in (non-cooperative) game theory, and the README lists what it provides in five items.

Structures to represent games in extensive and strategic form. Methods for building and modifying games. Representations of mixed strategy and mixed behavior profiles. Many algorithms for computing one or more Nash equilibria of games. And facilities for computing quantal response equilibria and fitting QREs to data.

That list is the package's real scope, and two of the entries are the ones that distinguish it from a textbook exercise. Mixed behaviour profiles are the extensive form analogue of mixed strategy, and a game with sequential moves has behaviours rather than strategies, so an implementation that only handles strategic form cannot even represent the problem. And the QRE side, which is the behavioural model where players are noise in their responses rather than pure rational maximisers, comes with a fitting procedure so that a QRE can be estimated from observed choice frequencies rather than assumed.

The distinction between the two representations is the reason the package has a src/core/ and a src/games/ split in its build, with the games side further divided into agg/ for the aggregation classes.

The primary language of the repository is C++, the licence is GPL-2.0-or-later, and the homepage is gambit-project.org with the documentation on Read the Docs at gambitproject.readthedocs.io. The last push was on 2026-10-21 and the repository is not archived.

The pygambit package and its solver commands

The Python distribution is called pygambit, and it is the reason a Python user is likely to reach for this project at all.

pip install pygambit

Pre-release versions are also published to PyPI, with the note that alpha, beta and release candidate builds can be installed with pip install --pre pygambit.

The interesting part of the package is that it does not only expose a library. The project.scripts section registers eleven command line entry points, one per solver, and they are named after the algorithms they implement.

[project.scripts]
gambit-enumpure = "pygambit.cli.enumpure:main"
gambit-logit = "pygambit.cli.logit:main"
gambit-enummixed = "pygambit.cli.enummixed:main"
gambit-lcp = "pygambit.cli.lcp:main"
gambit-lp = "pygambit.cli.lp:main"
gambit-liap = "pygambit.cli.liap:main"
gambit-simpdiv = "pygambit.cli.simpdiv:main"
gambit-gnm = "pygambit.cli.gnm:main"
gambit-ipa = "pygambit.cli.ipa:main"
gambit-enumpoly = "pygambit.cli.enumpoly:main"
gambit-hp = "pygambit.cli.hp:main"

So a user can go through the Python API and build a game, or drop to the command line and run a specific algorithm on a game file. The names carry the literature: enumpure and enummixed are the support enumeration methods for pure and mixed equilibria, lcp is a linear complementarity approach, and logit is the logit QRE. liap is a Lyapunov-based method.

The dependencies are modest: numpy, scipy, pandas and click. Click is what gives the eleven commands their command line parsing, and the scientific stack is there for the numerical work. The Python version floor is 3.11, with classifiers up to 3.15, and the development status is listed as Production/Stable.

How the C++ core is built into the Python package

The build is where the project's two languages meet, and the setup.py explains the arrangement in detail.

The build system requires setuptools, wheel and Cython, with the setuptools.build_meta backend, and the setup.py is the file that assembles the C++ extension. It globs the sources rather than listing them, which is why you see glob.glob("src/core/*.cc") and glob.glob("src/games/*.cc") plus glob.glob("src/games/agg/*.cc"), with the object dependencies gathered from the matching .h and .imp headers.

The compiler standard is set per platform, with the flags chosen as ["/std:c++20"] if platform.system() == "Windows" else ["-std=c++20"]. That conditional is the kind of detail that only shows up when building on Windows, and it means the extension needs a compiler that understands C++20.

The extension modules are named cppgambit_core and cppgambit_games, and the include directories are simply ["src"]. The two module names mirror the two source trees, so the Python package is a thin binding over a C++ core that is organised the same way as the library itself.

The repository layout shows the rest of the build story. There is configure.ac, acinclude.m4 and Makefile.am, which is the autotools path for building the C++ library and its command line tools directly, alongside a build_support/ directory, a catalog/ directory, contrib/ and doc/. There is also a Doxyfile for the C++ API documentation and a CITATION.cff for the project citation, plus a .clang-format, a .clang-tidy, a .pre-commit-config.yaml and a .devcontainer/ directory.

So there are three ways in: the C++ library with its autotools build, the Python package built with Cython from the same sources, and the pre-built Python wheel from PyPI. The sources are shared, which is the point.

The release line and what the pre-release means

The release history is the part to read carefully, because the project is mid-version and the naming carries information.

The recent tags are v17.0.0-beta.1 from 2026-09-08, v17.0.0-alpha.3 from 2026-08-31 and v17.0.0-alpha.2 from 2026-08-21. The README badges distinguish them, with one badge filtered on filter=!*-* labelled Latest stable version and another on filter=*-* labelled Latest development version, so the repository publishes both a stable line and a development line side by side.

The consequence for a user is a choice about which line to pin. The 17.0 line is in alpha and beta, which means the API is still settling, and the pre-release wheels are published to PyPI but require pip install --pre to reach. The stable line is the one without a pre-release suffix.

Two other details about the packaging are worth knowing. The pyproject.toml declares the version as dynamic, so it comes from the source tree rather than being written by hand, and the release instructions in the repository root are documented in the changelog and the AUTHORS and NEWS files rather than in the README.

The GPL-2.0-or-later licence covers both the C++ package and the Python distribution, since the pyproject repeats it as the license field. The C++ setup.py header shows the full notice, and the file it is taken from is src/python/setup.py, which tells you the Python bindings are a subdirectory of the library source rather than a separate project.

Where Gambit fits, and where it stops

The comparison worth making is with writing the solver yourself, and with the many smaller equilibrium solvers that exist for one specific case.

Against writing it yourself, the difference is breadth and correctness. Computing a Nash equilibrium of a general bimatrix game by support enumeration is a well defined algorithm and not a large amount of code, but getting the degenerate cases right, handling the extensive form, and producing a solution set rather than a single equilibrium is where the effort goes. Gambit has been doing this since the 1990s, judging by the copyright range on the setup.py, which runs from 1994 to 2026.

Against a single-purpose solver, the difference is that Gambit covers the whole family rather than one algorithm. The eleven commands in the Python package are the visible tip of that, and the README's phrase of many algorithms for computing one or more Nash equilibria is the point. For a paper that needs to compare methods, or for a game where the equilibrium set is large and the question is which of them are stable, that breadth is the reason to use the package.

The limits are equally clear. The package is for non-cooperative games, so cooperative game theory, mechanism design and anything in the experimental or behavioural branch beyond QRE is out of scope. The Python binding requires a C++20 compiler to build from source, though the PyPI wheel removes that for most users. And a 17.0 line in beta means the Python API may still change under you.

There is also a documentation split to plan for. The README is short and points to the documentation at gambitproject.readthedocs.io and the project site at gambit-project.org, and the contributors are asked to read the code of conduct and contribution guidelines before posting on GitHub. The doc/ directory in the repository and a Doxyfile for the C++ API are there, but the reference documentation you will actually work from is hosted.

For a student or researcher with a small game, Gambit may be more than the job needs. For someone publishing a paper on equilibrium computation, or running a large computational study across many game instances, it is the reference implementation to reach for.

Editorial conclusion

Gambit suits an economist or a researcher who needs equilibria computed properly rather than approximated, since the package covers extensive form, strategic form, mixed strategy and mixed behaviour profiles, and it offers many algorithms for computing one or more Nash equilibria. It is the wrong tool if you only need a quick equilibrium for a small matrix, because setting up the C++ build or the Python package is more work than writing the solver. Before adopting it, read the Gambit project site rather than the repository README, because the README is a signpost, and note that the 17.0 line is still in alpha and beta while the stable releases are the ones without the pre-release suffix.

Frequently asked questions

Official sources

1. gambitproject/gambit on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases