Programmable inference, one release from July 2025, and a citation from 2019

The newest release is 0.4.8 and the branch has moved on since

Three releases are on record: 0.4.8 from July 12, 2025, v0.4.7 from September 6, 2024 and v0.4.6 from September 20, 2023. Two things follow from that list. The version line moves about once a year, which is a slow cadence for a package people install from a registry, and the tagging is inconsistent: the newest release is tagged `0.4.8` with no letter in front, while the two before it are `v0.4.7` and `v0.4.6`. Anything automating a version string has to cope with both forms. More important for anyone pinning dependencies, the default branch's most recent commit is dated June 9, 2026, roughly eleven months after the last release, so the code you get from the branch is not the code in the newest published version. The version number itself lives in `Project.toml` at the top of the repository rather than in a release script, which is the usual Julia arrangement and also why the release tags are what a user actually reads.

Programmable inference is a list of five things you may write

The feature list states the central claim as a formatting quirk: inference algorithms are programmable. What follows names what that means in practice, and the list is short enough to be useful. You can write custom proposals, variational families, MCMC kernels and SMC updates, in a project described as a way to do it without worrying about the math. A second entry covers the other direction of the same idea: there are defined APIs for implementing custom generative models, custom distributions and custom gradients. Together those are the extension surface of the system, and they are documented as how-to pages rather than as a single guide, so the shape of each API has to be read before it can be extended. One link is worth noting because it names the mechanism behind the particle filter path: SMC updates are documented under trace translators, which is the machinery that lets a filter step be written rather than selected.

Four inference paradigms and two gradient-based training routes

The first feature entry bundles the inference algorithms under the heading of multi-paradigm Bayesian inference: Sequential Monte Carlo, variational inference, MCMC, and more, with a separate reference page for each. The second covers training rather than sampling, naming gradient-based training of generative models through parameter optimization and wake-sleep learning. That pairing is the difference between generating samples and learning parameters, and the page lists both without guidance on which to reach for. A third item covers a separate job entirely, Bayesian structure learning, and names two techniques for it: involutive MCMC and SMCP³, the latter documented under advanced particle filtering. So the shipped surface is not one algorithm family with a plugin point, it is four sampling paradigms, two gradient-based training routes and a structure-learning entry, each behind its own page. Whether an algorithm exists is a documentation lookup rather than something the feature list settles.

The speed claim is architectural, and carries no measurement

One entry is about performance and it is stated as a mechanism: specialized modeling constructs that speed up inference by supporting incremental computation, with a tutorial on scaling with them attached. Nothing on the page quantifies the gain. There is no speed-up factor, no before-and-after timing, no model the claim was measured on and no comparison against a plain implementation, so a reader has to take incremental computation as a property of the modeling language rather than as a benchmark result. That is not unusual for a project page, and incremental computation is a real technique for reusing work across a trace rather than recomputing it, but it is worth being clear about what has and has not been claimed. The same restraint runs through the rest of the list. It says what you can write and how the pieces are named, and it does not say how any of it performs.

Installing means choosing the registry version or the branch

Installation is four short steps, and the second one is a fork in the road. From the Julia REPL, type `]` to enter the package manager mode and add the registered package:

add Gen

If you want the latest development version instead, the page gives a different command, one that adds the repository URL directly:

add https://github.com/probcomp/Gen.jl.git

After that the package is used from the REPL or at the top of a script with `using Gen`, and the installation can be checked locally by running the test suite:

using Pkg; Pkg.test("Gen")

That last one matters more than it looks, because `test/` is a top-level directory in the repository rather than something hidden, so the suite is runnable by a user and not only by continuous integration. The branch install is the one to think about: it puts development code in your environment, and the documentation is published in two sets, a stable set and a dev set, so a feature you read about in the dev docs may not exist in what the registry hands you.

The docs live at gen.dev and at a second GitHub Pages domain

Three locations carry documentation and they are not the same content. The homepage is gen.dev, which is where the introduction, documentation and tutorials live. The badges at the top of the repository point at `probcomp.github.io/Gen.jl/docs/stable` and `probcomp.github.io/Gen.jl/docs/dev`, which is the same documentation reached through a GitHub Pages domain and split into the two version sets the install section implies. The source for all of it is in the repository, with a `docs/` directory at the top level and a `WEBSITE.md` file whose name suggests it governs the site rather than the code. Every feature link in the list resolves into the stable set, which is a small mismatch with the development install path: if you add the git URL you are running code that the stable pages do not describe, and the dev pages are the ones to read. The repository also carries a `.vscode/` directory, so the editor setup is versioned alongside the package.

Support is a discussion forum and the citation is five years old

The support routes are conventional and clearly separated: questions go to GitHub discussions, bugs to issues, and changes to pull requests, with the contribution guidelines in `CONTRIBUTING.md` on the master branch. For research use the page asks you to cite a 2019 PLDI paper, Gen: A General-Purpose Probabilistic Programming System with Programmable Inference, by Cusumano-Towner, Saad, Lew and Mansinghka, with links to the PDF and to a bibtex file. That paper is the canonical reference and it identifies no version. The project is described as part of ongoing research at the MIT Probabilistic Computing Project, with a contact address, [email protected]. So the citation trail and the release trail are separate: a reader who cites the paper is citing the system as it was described five years ago, and a reader who pins 0.4.8 is two years past that paper with no second citation offered.

Editorial conclusion

Adopt Gen.jl when the inference algorithm itself is the thing you need to change, since that is what the project is for and what the documented APIs are built around. Three things to check before you commit to it. The newest release is 0.4.8 from July 12, 2025 while the default branch's last commit is dated June 9, 2026, so pin your version deliberately rather than tracking the branch. Choose between `add Gen` and the git URL deliberately too, because the second gives you development code that the stable documentation does not describe. And treat the speed claim as architectural: the page attributes faster inference to modeling constructs that support incremental computation, with no measurement attached, so benchmark your own model before believing it. The reference to cite is the 2019 PLDI paper, which identifies none of this.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. probcomp/Gen.jl on GitHub
3. Project website
4. README
5. Releases